BGP MED routing decision - Always-compare-med

MED (Multi-Exit Discriminator) is used to influence routing decision. By default, a router which receives MED attribute from neighbors, only compares it if they are coming from the same AS. As you can see in the diagram below:

• R3 send to R4 a MED of 50 for subnet 172.16.1.0/24
• R2 send to R5 a MED of 100 for subnet 172.16.1.0/24
• The lowest MED is the preferred path

In a first step, the configuration below has been applied:

R1:

interface Loopback1

ip address 172.16.1.1 255.255.255.0

router bgp 50

bgp log-neighbor-changes

network 172.16.1.0 mask 255.255.255.0

neighbor 10.1.1.2 remote-as 100

neighbor 10.1.3.3 remote-as 200

R2:

router bgp 100

bgp log-neighbor-changes

neighbor 10.1.1.1 remote-as 50

neighbor 10.1.2.3 remote-as 200

neighbor 10.1.4.4 remote-as 300

neighbor 10.1.4.4 route-map MED out

!

access-list 1 permit 172.16.1.0 0.0.0.255

!

route-map MED permit 10

match ip address 1

set metric 100

!

route-map MED permit 20

R3:

router bgp 200

bgp log-neighbor-changes

neighbor 10.1.2.2 remote-as 100

neighbor 10.1.3.1 remote-as 50

neighbor 10.1.5.4 remote-as 300

neighbor 10.1.5.4 route-map MED out

!

access-list 1 permit 172.16.1.0 0.0.0.255

!

route-map MED permit 10

match ip address 1

set metric 50

!

route-map MED permit 20

R4:

router bgp 300

bgp log-neighbor-changes

neighbor 10.1.4.2 remote-as 100

neighbor 10.1.5.3 remote-as 200

MED is seen in R4 but R4 set R2 has next-hop. R4 doesn't compare MED because information is coming from 2 different ASs. R2 is used due to the fact that he has the lowest Router-id 10.1.4.2.

R4#sho ip bgp 172.16.1.0

BGP routing table entry for 172.16.1.0/24, version 2

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     3

  Refresh Epoch 1

  100 50

    10.1.4.2 from 10.1.4.2 (10.1.4.2)

      Origin IGP, metric 100, localpref 100, valid, external, best

  Refresh Epoch 1

  200 50

    10.1.5.3 from 10.1.5.3 (10.1.5.3)

      Origin IGP, metric 50, localpref 100, valid, external

Now, we add the command 'bgp always-compare-med' on R4:

R4:

router bgp 300

bgp always-compare-med

As you can, R4 has now choosen R3 for the next-hop. MED is used:

R4#sho ip bgp 172.16.1.0

BGP routing table entry for 172.16.1.0/24, version 2

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     4

  Refresh Epoch 1

  200 50

    10.1.5.3 from 10.1.5.3 (10.1.5.3)

      Origin IGP, metric 50, localpref 100, valid, external, best

  Refresh Epoch 1

  100 50

    10.1.4.2 from 10.1.4.2 (10.1.4.2)

      Origin IGP, metric 100, localpref 100, valid, external

Influence routing decision with BGP Community

You can use community as a flag in order to mark a route. Upstream routers will use these flags to define routing policy. In the schema below, you can image that AS 100 is a customer site and AS 200 is a service provider. We have negotiated with the provider that:

• Traffic destined to routes with a community 100 have to pass by R3
• Traffic destined to routes with a community 200 have to pass by R2

In order to realize this, R1 marks routes with a community field, R2 and R3 modify the local_pref to follow the rules aboves.

In our case:

•  Lo1 will be 'marked' with a community 200:100 by R1
•  Lo2 will be 'marked' with a community 200:200 by R1
• Route with a community 200:100 will have a local_pref of 1000 (R3). 
• Route with a community 200:200 will have a local_pref of 500 (R2).

Configuration

R1:

interface Loopback1

 ip address 172.16.1.1 255.255.255.0

!

interface Loopback2

 ip address 172.16.2.1 255.255.255.0

!

router bgp 100

 bgp log-neighbor-changes

 network 172.16.1.0 mask 255.255.255.0

 network 172.16.2.0 mask 255.255.255.0

 neighbor 10.1.1.2 remote-as 200

 neighbor 10.1.1.2 send-community

 neighbor 10.1.1.2 route-map Peer-R2 out

 neighbor 10.1.2.3 remote-as 200

 neighbor 10.1.2.3 send-community

 neighbor 10.1.2.3 route-map Peer-R3 out

!

ip access-list standard LO1

 permit 172.16.1.0 0.0.0.255

ip access-list standard LO2

 permit 172.16.2.0 0.0.0.255

!

route-map Peer-R3 permit 10

 match ip address LO2

 set community 200:200

route-map Peer-R3 permit 15

 match ip address LO1

 set community 200:100

!

route-map Peer-R3 permit 20

!

route-map Peer-R2 permit 10

 match ip address LO1

 set community 200:100

!

route-map Peer-R2 permit 15

 match ip address LO2

 set community 200:200

!

route-map Peer-R2 permit 20

R2:

router bgp 200

 bgp log-neighbor-changes

 neighbor 10.1.1.1 remote-as 100

 neighbor 10.1.1.1 next-hop-self

 neighbor 10.1.1.1 route-map Peer-R1 in

 neighbor 20.1.1.3 remote-as 200

 neighbor 20.1.1.3 next-hop-self

 neighbor 20.1.2.4 remote-as 200

 neighbor 20.1.2.4 next-hop-self

!

ip bgp-community new-format

ip community-list 1 permit 200:200

!

route-map Peer-R1 permit 10

 match community 1

 set local-preference 500

!

route-map Peer-R1 permit 20

R3:

router bgp 200

 bgp log-neighbor-changes

 neighbor 10.1.2.1 remote-as 100

 neighbor 10.1.2.1 route-map Peer-R1 in

 neighbor 20.1.1.2 remote-as 200

 neighbor 20.1.1.2 next-hop-self

 neighbor 20.1.3.4 remote-as 200

 neighbor 20.1.3.4 next-hop-self

!

ip forward-protocol nd

!

ip bgp-community new-format

ip community-list 1 permit 200:100

!

route-map Peer-R1 permit 10

 match community 1

 set local-preference 1000

!

route-map Peer-R1 permit 20

Validation

Check that routes are flags on R2:

R2#sho ip bgp 172.16.1.0

BGP routing table entry for 172.16.1.0/24, version 6

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     2

  Refresh Epoch 1

  100

    20.1.1.3 from 20.1.1.3 (20.1.3.3)

      Origin IGP, metric 0, localpref 1000, valid, internal, best

  Refresh Epoch 1

  100

    10.1.1.1 from 10.1.1.1 (172.16.2.1)

      Origin IGP, metric 0, localpref 100, valid, external

      Community: 200:100

R2#sho ip bgp 172.16.2.0

BGP routing table entry for 172.16.2.0/24, version 3

Paths: (1 available, best #1, table default)

  Advertised to update-groups:

     3

  Refresh Epoch 1

  100

    10.1.1.1 from 10.1.1.1 (172.16.2.1)

      Origin IGP, metric 0, localpref 500, valid, external, best

      Community: 200:200

Check policies applied by R2 and R3 on R4:

R4#sho ip bgp

BGP table version is 9, local router ID is 20.1.3.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

              x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>i 172.16.1.0/24    20.1.3.3                 0   1000      0 100 i

 *>i 172.16.2.0/24    20.1.2.2                 0    500      0 100 i

Command to see all floatings routes

With the classic 'show ip route static', the backup floating route is not seen in the display:

Router#show  ip route static
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 10.10.2.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.10.2.1

In order to see both routes, active and non-active route, we have to use the command 'show ip static route'. With this command, both routes and metrics are seen:

Router#show ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
       G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface proces
       B - BootP, S - Service selection gateway
       DN - Default Network, T - Tracking object
       L - TL1, E - OER, I - iEdge
       D1 - Dot1x Vlan Network, K - MWAM Route
       PP - PPP default route, MR - MRIPv6, SS - SSLVPN
       H - IPe Host, ID - IPe Domain Broadcast
       U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
       IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Track

Static local RIB for default

M  0.0.0.0/0 [1/0] via 10.10.2.1 [A]
M            [5/0] via 10.10.25.1 [N]

OSPF - Filter redistribution in a Totally NSSA area

In some cases, we can have the ABR which can also be an ASBR. If we are working with a Totally NSSA area we have unnecessary routes. ABR announces a default route and his redistributed routes which are not necessary. In order to solve this case and only announce a default route, we can use the commande below on the ABR:

 area X nssa no-redistribution no-summary

The schema below is anexample of this implementation:

BGP Route Reflector - Routing advertisements rules

In order to avoid a looping route, the route reflector follows the 3 rules below:

1/ routes learned from an eBGP peers can be announced to eBGP peers, clients and non-clients.

2/ routes learned from a client can be announced to eBGP peers, others clients and non-clients.

3/ routes learned from a non-client can be announced to eBGP peers, clients and they cannot be sent to a non-clients.

Windows Automatic Metric for IP routes

I was wondering why sometimes my traffic was going on wireless interface and sometimes on copper interface.
This behavior is due to the automatic Metric feature on windows.
As you can see on the table below if I am connected on a 100Mb, my metric on the copper is 20.


On our site, we have 802.11a/g and 802.11a/g/n access points.

• When I'm on an a/g antenna (max 54Mbps) and a 100Mb copper inteface, I have the following routing table:

C:\Users\ABCD>netstat -rn

IPv4 Route Table
========================================================================
Active Routes:
Network      Destination        Netmask          Gateway       Interface  Metric
0.0.0.0          0.0.0.0        10.1.1.254       10.1.1.32     20
0.0.0.0          0.0.0.0        10.1.2.254       10.1.2.68     25

• When I'm on a a/g/n antenna (and my bandwith is more than 200Mb) and a 100Mb copper inteface, I have the following routing table:

C:\Users\ABCD>netstat -rn
IPv4 Route Table
========================================================================
Active Routes:
Network      Destination        Netmask          Gateway       Interface  Metric
0.0.0.0          0.0.0.0        10.1.2.254       10.1.2.68     10
0.0.0.0          0.0.0.0        10.1.1.254       10.1.1.32     20
As you can see the wireless is preferred with a metric of 10. I have chosen the solution to fix by myself the metric on networks interfaces (copper 1 and wireless 20).

start>control Panel>Network and Sharing Center>Change adpater settings
Right click on the Copper card>Properties>Internet Protocol Version 4>Properties>Advanced
Uncheck 'Automatic metric' and fix the metric

For my case, I'm only using the interface metric. But the result in metric seen with the command 'netstat -rn' is the result of an addition (Gateway metric + InterfaceMetric).
In order to find the gateway metric, you can use the command 'netsh int ip show config':
C:\Users\ABCD>netsh int ip show config

Configuration for interface "Local Area Connection"
    DHCP enabled:                         Yes
    IP Address:                           10.1.1.32
    Subnet Prefix:                        10.1.1.0/24 (mask 255.255.255.0)
    Default Gateway:                      10.1.1.254
    Gateway Metric:                       0
    InterfaceMetric:                      20
    DNS servers configured through DHCP:  10.1.2.5
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None

Configuration for interface "Wireless Network Connection"
    DHCP enabled:                         Yes
    IP Address:                           10.1.2.68
    Subnet Prefix:                        10.1.2.0/25 (mask 255.255.255.0)
    Default Gateway:                      10.1.2.254
    Gateway Metric:                       0
    InterfaceMetric:                      25
    DNS servers configured through DHCP:  10.1.2.5
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None

Troubleshoot OSPF neighbors (Hellos check)

In order to become neighbors, routers perform several checks. If this check fails, we have to troubleshoot and find the cause of this issue. You will find below several examples of neighbor failed. I have added logs messages and debug messages in order to easily find the cause.

• Area mismatch:

• Authentication key mismatch:

• Duplicate Router-id:

• Subnet/mask Mismatch:

• Area Type Mismatch:

ICMP Fragmentation and Firewall

Following an installation of new firewalls, I was facing an issue of communication between a CMC (Central Management Console) and a Riverbed Steelhead.
In a normal way, the CMC open a SSH session to push rules to the Riverbed. But after the installation, it was not working anymore. I have investigated and found the root cause of this issue.

Packets between the CMC and the Riverbed are fragmented. Without firewalls, CMC and Riverbed use PMTU in order to discover the MTU small enough to traverse the entire path without fragmentation.
In a first step, Path MTU uses the option Don't Fragment (DF). When a packet is sent with this option, it cannot been fragmented. If a router with a smaller MTU receives this packet, it will drop it and send to the sender an ICMP Fragmentation Needed. This step is repeated until the source has reached the destination without fragmentation.

As you can see below, our problem come from this ICMP Fragmentation Needed packet.
When the steelhead sends a packet (with option Don't fragment) to the CMC, a router on the path sends a ICMP fragmentation Needed. However, the new firewall filters this packet and now the handshake failed.

Workaround:

• Allow ICMP option on the firewall.
• Reduce MTU on primary interface of the Riverbed.

BGP Decision Process

Nothing new in this post! It's just a reminder regarding the BGP process decision:

1. Weight (Bigger win, Cisco proprietary)
2. LOCAL_PREF (Bigger Win)
3. Locally injected routes (Locally injected win overiBGP/eBGP learned)
4. AS_PATH length (Smaller Win)
5. ORIGIN (code I win over E, E win over ? )
6. MED (Smaller Win)
7. Neighbor Type (eBGP win over iBGP)
8. IGP metric to NEXT_HOP (Smaller win)

OSPF Database Reminder in the same area

This is a reminder in order to interpret an ospf database on a Cisco router. I have created the following lab to test the 'show ip ospf datase':

In red, the router ID:

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

The list of all routers in the area:

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         129         0x80000002 0x0057AC 1
2.2.2.2         2.2.2.2         25          0x80000003 0x00536B 2
3.3.3.3         3.3.3.3         24          0x80000002 0x0016B6 2

All the network segments in the area and the DR for each segment. Here, 10.1.2.2 is the IP address of the DR on the segment and 2.2.2.2 is the router id:

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.2.2        2.2.2.2         103         0x80000001 0x0021F5
10.1.4.2        2.2.2.2         25          0x80000001 0x006F9D

Each subnet, even if there is no OSPF neighbor:

R1#show ip ospf database internal

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Stub Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Mask
10.1.2.255      1.1.1.1         355         0x0        0x006D69 /24
10.1.3.255      2.2.2.2         98          0x0        0x00448D /24
10.1.4.255      2.2.2.2         315         0x0        0x003997 /24
10.1.5.255      3.3.3.3         230         0x0        0x0010BB /24

Find the plain text authentication of a peer RIP router

Followings commands can be useful if you need to use authenticated 'RIP updates' between 2 routers and whether you don't have access to the peer (you don't know the authentication message used by the peer). If it's a clear text, you can use the following debug:

access-list 100 permit udp any any eq rip
debug ip packet 100 dump

Normally, the password will appear in a clear text as below:

*Sep  4 17:27:54.815: IP: s=10.10.10.2 (FastEthernet/1), d=224.0.0.9, len 72, input feature
AC43C9C0:        0100 5E000009 AABBCC00 07030800    ..^...*;L.....
AC43C9D0:  45C00048 00000000 0111C4D0 0A0A0A02  E@.H......DP....
AC43C9E0:  E0000009 02080208 003453BE 02020000  `........4S>....
AC43C9F0:  FFFF0002 54455354 00000000 00000000  ....TEST........
AC43CA00:  00000000 00020000 0A010100 FFFFFF00  ................
AC43CA10:  00000000 00000001                    ........
Router#, MCI Check(68), rtype 0, forus FALSE, sendself FALSE, mtu 0