BGP Conditional Advertisement

This BGP feature is able to filter a subnet advertisement based on a certain match (AS-PATH, subnet in the routing table...). In our example below, we can image that AS100 is an ISP1 and AS200 is an ISP2. In most of the case, we monitor only the status of the interface which is directly connected. But in our case, we will monitor the presence of the subnet 20.20.20.0/24 which is advertised by the ISP1.
By default, we only advertise the subnet 50.50.50.0/24 to ISP1 and if the subnet 20.20.20.0/24 disappears, we announce it also to ISP2. We can typically use this feature when ISP2 is more expensive than ISP1.

• Configuration:

R1:
interface Loopback50
 ip address 50.50.50.50 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.50.1 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.150.1 255.255.255.0
!
router bgp 50
 network 50.50.50.0 mask 255.255.255.0
 neighbor 192.168.50.2 remote-as 100
 neighbor 192.168.150.3 remote-as 200
 neighbor 192.168.150.3 advertise-map NOT_ANNOUNCE_R3 non-exist-map ADVERTISE
!
ip prefix-list LO20 seq 5 permit 20.20.20.0/24
!
ip prefix-list LO50 seq 5 permit 50.50.50.0/24
!
route-map NOT_ANNOUNCE_R3 permit 10
 match ip address prefix-list LO50
!
route-map ADVERTISE permit 10
 match ip address prefix-list LO20
R2:
interface Loopback20
 ip address 20.20.20.20 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.50.2 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.100.2 255.255.255.0
!
router bgp 100
 network 20.20.20.0 mask 255.255.255.0
 neighbor 192.168.50.1 remote-as 50
 neighbor 192.168.100.3 remote-as 200
R3:
interface Ethernet0/0
 ip address 192.168.100.3 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.200.3 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.150.3 255.255.255.0
!
router bgp 200
 neighbor 192.168.100.2 remote-as 100
 neighbor 192.168.150.1 remote-as 50

• Initial behavior:

R3 sees subnet 50.50.50.0/24 only from R3
R3#sho ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *   20.20.20.0/24    192.168.150.1                          0 50 100 i
 *>                   192.168.100.2            0             0 100 i
 *>  50.50.50.0/24    192.168.100.2                          0 100 50 i
We can check that R1 is not advertising the subnet to R3:
R1#sho ip bgp neighbors 192.168.150.3 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  20.20.20.0/24    192.168.50.2             0             0 100 i
R1#sho ip bgp neighbors 192.168.50.2 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  50.50.50.0/24    0.0.0.0                  0         32768 i
R1#sho ip bgp neighbors 192.168.150.3 | in Conditio
  Condition-map ADVERTISE, Advertise-map NOT_ANNOUNCE_R3, status: Withdraw

• Now the subnet 20.20.20.0/24 is removed from the routing table:

R2#int lo20
shut

We can check that R1 is now advertising the subnet to R3:
R1#sho ip bgp neighbors 192.168.150.3 | in Conditio
  Condition-map ADVERTISE, Advertise-map NOT_ANNOUNCE_R3, status: Advertise
R1#sho ip bgp neighbors 192.168.150.3 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  50.50.50.0/24    0.0.0.0                  0         32768 i

R3#sho ip bgp
BGP table version is 18, local router ID is 192.168.200.3
 *>  50.50.50.0/24    192.168.150.1            0             0 50 i
 *                    192.168.100.2                          0 100 50 i

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

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.

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)