IP next-hop peer address (BGP)

In BGP routing protocol, the update from the external AS will contains the next hop address of the external hop itself. Therefore, when the router receives the update from the external AS and advertises the update to the other routers via iBGP, the other routers will see the next hop of the advertised networks via the external router IP address.  However, we can use the next-hop-self command in the BGP process at the Border router to fix the problem. But what if we cannot use the next-hop-self command? Do we have any other option?

Yes. We can use the route-map and set ip next-hop peer-address command to tell the iBGP learn router to forward the packet to its peer address instead of the external router IP address. Check the example below for more detailed explanation.

In this example, R1 advertise 10.10.10.0/24 network to R2. R2 advertises this network to R3 via BGP. However, R2 does not have the next-hop-self command configured which makes the R3 consider the R1 as the next hop address. The problem is R3 does not know how to get to R1. Therefore, R3 does not have reachability through the 10.10.10.0/24 network.


R2
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.2 remote-as 200

R3

R3#sh ip bgp
BGP table version is 2, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i10.10.10.0/24    192.168.1.1              0    100      0 100 i
R3#

We use the next-hop peer address command in the R2 which makes R3 forward the packet destined to 10.10.10.0/24 network via its peer address which in this case is R2 address.

R2

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.2 remote-as 200
 neighbor 192.168.2.2 route-map PEER-ADDRESS out

route-map PEER-ADDRESS permit 10
 set ip next-hop peer-address
!

R3

R3#sh ip bgp

BGP table version is 2, local router ID is 192.168.2.2

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*>i10.10.10.0/24    192.168.2.1              0    100      0 100 i

R3#

Now R3 see the next hop address via R2. We can test the connectivity through this network now.

R3#ping 10.10.10.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/34/108 ms

R3#

BGP Cluster ID Loop Prevention

A router reflector cluster normally has a single route reflector. To avoid a single point of failure, you can configure a cluster with more than one route reflector. In case we have more than one RR in the group, we will establish the cluster of RRs. All RRs in the cluster are in the same cluster -ID.

Route-Reflector (RR) has an algorithm to prevent the update from the other RRs. It will not accept the update that has the same Cluster-ID as itself in order to prevent the loop in BGP. Below is the example of how the loop prevention works.

Example 

We have 2 scenarios as followings

• R1 and R2 are in the same cluster and have the same Cluster ID which is 111.111.111.111
• R1 and R2 are in the different cluster. R1 has cluster ID of 111.111.111.111 and R2 has a cluster ID of 222.222.222.222

Here is the example of the 1st scenario. ( same cluster ID)

R1
router bgp 100
 no synchronization
 bgp cluster-id 111.111.111.111
 bgp log-neighbor-changes
 neighbor 192.168.1.2 remote-as 100
 neighbor 192.168.1.2 next-hop-self
 neighbor 192.168.2.2 remote-as 100
 neighbor 192.168.2.2 route-reflector-client
 neighbor 192.168.2.2 next-hop-self
 neighbor 192.168.4.2 remote-as 100
 neighbor 192.168.4.2 route-reflector-client
 neighbor 192.168.4.2 next-hop-self
 no auto-summary
R1#

R2

R2#sh run | sec bgp

router bgp 100

 no synchronization

 bgp cluster-id 111.111.111.111

 bgp log-neighbor-changes

 network 20.20.20.20 mask 255.255.255.255

 neighbor 192.168.1.1 remote-as 100

 neighbor 192.168.1.1 next-hop-self

 neighbor 192.168.3.2 remote-as 100

 neighbor 192.168.3.2 route-reflector-client

 neighbor 192.168.3.2 next-hop-self

 no auto-summary

R2(config-router)#do sh ip bgp

BGP table version is 11, local router ID is 20.20.20.20

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*>i3.3.3.3/32       192.168.3.2              0    100      0 i

*> 20.20.20.20/32   0.0.0.0                  0         32768 i

R2(config-router)#

From the bgp table shown, R2 do not have the 50.50.50.50/32 and 40.40.40.40/32 in its BGP table, the reason is these networks have the same cluster-id with the R2. Due to the loop prevention mechanism, R2 will not accept these networks.

********************

R2

router bgp 100

 no synchronization

 bgp cluster-id 222.222.222.222

 bgp log-neighbor-changes

 network 20.20.20.20 mask 255.255.255.255

 neighbor 192.168.1.1 remote-as 100

 neighbor 192.168.1.1 next-hop-self

 neighbor 192.168.3.2 remote-as 100

 neighbor 192.168.3.2 route-reflector-client

 neighbor 192.168.3.2 next-hop-self

 no auto-summary

R2(config-router)#do sh ip bgp

BGP table version is 13, local router ID is 20.20.20.20

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

* i3.3.3.3/32       192.168.2.2              0    100      0 i

*>i                 192.168.3.2              0    100      0 i

*> 20.20.20.20/32   0.0.0.0                  0         32768 i

*>i40.40.40.40/32   192.168.4.2              0    100      0 i

*>i50.50.50.50/32   192.168.4.2              0    100      0 i

R2(config-router)#

Now, we have changed the cluster ID of R2 to 222.222.222.222. At this time R1 and R2 have a different Cluster-ID. Therefore, R2 will accept the bgp update from R1 and it has the 40.40.40.40/32 and 50.50.50.50/32 networks in its bgp table.

Verification

R3#sh ip bgp 40.40.40.40

BGP routing table entry for 40.40.40.40/32, version 11

Paths: (2 available, best #2, table Default-IP-Routing-Table)

  Not advertised to any peer

  Local

    192.168.4.2 (metric 74) from 192.168.3.1 (20.20.20.20)

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

      Originator: 4.4.4.4, Cluster list: 222.222.222.222, 111.111.111.111

  Local

    192.168.4.2 (metric 74) from 192.168.2.1 (1.1.1.1)

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

      Originator: 4.4.4.4, Cluster list: 111.111.111.111

R3#

R2#

R2#sh ip bgp 40.40.40.40

BGP routing table entry for 40.40.40.40/32, version 13

Paths: (1 available, best #1, table Default-IP-Routing-Table)

  Advertised to update-groups:

        2

  Local

    192.168.4.2 (metric 74) from 192.168.1.1 (1.1.1.1)

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

      Originator: 4.4.4.4, Cluster list: 111.111.111.111

R2#

BGP Local-AS command

Local-as is useful when we have a change in the AS number of the BGP domain. However, we do not have a change to change the AS number in the bgp process yet. This command will help the neighbor think that it connects to the old AS number.

Followings are the example of the local-as and its option in BGP.
R1 = AS 100
R2 = AS 200
R3 = AS 300
Configure the network to have R1 thinks that R2 is in AS 65001 (Use local-AS)

R1

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 network 2.2.2.0 mask 255.255.255.0
 network 3.3.3.0 mask 255.255.255.0
 neighbor 192.168.1.2 remote-as 65001
 no auto-summary

Local AS

R2
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.1.1 local-as 65001
 neighbor 192.168.2.2 remote-as 300
 no auto-summary


R3#sh ip bgp
BGP table version is 46, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.2.1                            0 200 65001 100 i
*> 2.2.2.0/24       192.168.2.1                            0 200 65001 100 i
*> 3.3.3.0/24       192.168.2.1                            0 200 65001 100 i

When having a "no prepend", R2 will not prepend local-as to the update forwarding to R3. Therefore, the R3 will see only the real AS from R2 (without the 65001)


Local AS with no prepend
R2

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.1.1 local-as 65001 no-prepend
 neighbor 192.168.2.2 remote-as 300
 no auto-summary

R3#sh ip bgp
BGP table version is 40, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.2.1                            0 200 100 i
*> 2.2.2.0/24       192.168.2.1                            0 200 100 i
*> 3.3.3.0/24       192.168.2.1                            0 200 100 i

With the no prepend and replace-as, (neighbor to R3) R2 will not prepend the local as but instead replace the real AS with the local as value and send an update to R3. Therefore, R3 will see 65001 (local-as value) and 100 (AS at R1)


Local AS with no prepend & replace as


R2
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.1.1 local-as 65001 no-prepend replace-as
 neighbor 192.168.2.2 remote-as 300
 neighbor 192.168.2.2 local-as 65001 no-prepend replace-as
 no auto-summary

R3#sh ip bgp

BGP table version is 28, local router ID is 192.168.2.2

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*> 1.1.1.0/24       192.168.2.1                            0 65001 100 i

*> 2.2.2.0/24       192.168.2.1                            0 65001 100 i

*> 3.3.3.0/24       192.168.2.1                            0 65001 100 i

The summarization in BGP can be done with the aggregate command. However, this aggregate command when enabled the router will automatically send this aggregated updated to all of its neighbor by default. Sometimes, we do not want to advertise the aggregated route to all of the neighbor. We use the unsuppressed-map command to help us accomplish this.

The example below show the command and how to configure aggregate update and unsuppressed-map.

Example

We have R1 trying to advertise the summary route of 172.16.0.0/16 network to R2 and advertise the full updates with the subnets to R3. With the aggregate command alone R3 will only receive an aggregated update. Therefore, we will add the unsuppressed-map command as an option in the neighbor statement to R3. In this example, R3 wants to receive all subnets from R1, so the route-map UNSUPPRESS will not contain any match statement. We can modify the unsuppressed subnet in the router-map command to match the specify subnets we want to see in R3.

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 network 172.16.2.0 mask 255.255.255.0
 network 172.16.3.0 mask 255.255.255.0
 network 172.16.4.0 mask 255.255.255.0
 aggregate-address 172.16.0.0 255.255.0.0 summary-only
 neighbor 192.168.1.2 remote-as 100
 neighbor 192.168.1.2 unsuppress-map UNSUPPRESS
 neighbor 192.168.2.2 remote-as 100
 no auto-summary

Verify the configuration 

R2>sh ip bgp

BGP table version is 10, local router ID is 192.168.2.2

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*>i172.16.0.0       192.168.2.1              0    100      0 i

R2>

R3#sh ip bgp

BGP table version is 14, local router ID is 192.168.1.2

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*>i172.16.0.0       192.168.1.1              0    100      0 i

*>i172.16.1.0/24    192.168.1.1              0    100      0 i

*>i172.16.2.0/24    192.168.1.1              0    100      0 i

*>i172.16.3.0/24    192.168.1.1              0    100      0 i

*>i172.16.4.0/24    192.168.1.1              0    100      0 i

R3#

Now, we can see that R3 has bgp updates for all subnets from R1 as opposed to R2 has only summary routers advertised from R1.

BGP Outbound Route Filtering (BGP ORF)

ORF is the feature to allow the receiver router to tell sender what routes it wants. In fact, it works in the same manner of the filter list on the sender to allow advertising specific routes to receiver. However, the ORF is useful in the sense that we do not have to modify the configuration in the sender. This will very helpful when talking about PE and CE. 

In this scenario, R1 has 192.168.x.0/24 network in its routing table. Without route filtering, R1 will advertise all of its routes to R2. However, in this case, R2 only want 192.168.4.0/24, 192.168.5.0/24 and 192.168.6.0/24 from R1.  We will use ORF to accomplish this task.

When No Filter prefix, R1 advertised all of 192.168.x.0/24 network to R2 as shown in the show ip bgp command.

R1

R1#sh ip bgp

BGP table version is 7, local router ID is 192.168.6.1

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*> 192.168.1.0      0.0.0.0                  0         32768 i

*> 192.168.2.0      0.0.0.0                  0         32768 i

*> 192.168.3.0      0.0.0.0                  0         32768 i

*> 192.168.4.0      0.0.0.0                  0         32768 i

*> 192.168.5.0      0.0.0.0                  0         32768 i

*> 192.168.6.0      0.0.0.0                  0         32768 i

Configuration

R1

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 network 192.168.1.0

 network 192.168.2.0

 network 192.168.3.0

 network 192.168.4.0

 network 192.168.5.0

 network 192.168.6.0

 neighbor 10.10.1.2 remote-as 200
// receive ORF capability from R2

 neighbor 10.10.1.2 capability orf prefix-list receive

R2

ip prefix-list Block-1-3 seq 5 deny 192.168.0.0/22 ge 24 le 24

ip prefix-list Block-1-3 seq 10 permit 0.0.0.0/0 le 32

router bgp 200

 no synchronization

 bgp log-neighbor-changes

 neighbor 10.10.1.1 remote-as 100
// Send ORF capability to R1

 neighbor 10.10.1.1 capability orf prefix-list send

 neighbor 10.10.1.1 prefix-list Block-1-3 in

 no auto-summary

Verify configuration

R1#sh ip bgp neighbors 10.10.1.2 advertised-routes

BGP table version is 7, local router ID is 192.168.6.1

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*> 192.168.4.0      0.0.0.0                  0         32768 i

*> 192.168.5.0      0.0.0.0                  0         32768 i

*> 192.168.6.0      0.0.0.0                  0         32768 i

Total number of prefixes 3

R1#

Now, R1 only advertise 192.168.4.0/24, 192.168.5.0/24 and 192.168.6.0/24 to R2

R2#sh ip bgp

BGP table version is 34, local router ID is 10.10.1.2

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*> 192.168.4.0      10.10.1.1                0             0 100 i

*> 192.168.5.0      10.10.1.1                0             0 100 i

*> 192.168.6.0      10.10.1.1                0             0 100 i

BGP unequal BW Load sharing

To enable bgp multipath, we use the command under router bgp : maximum-path x. However, the way router sends the traffic is 1:1 load sharing and it does not depend on the link bandwidth. If we need the router to do an unequal load sharing according to the bandwidth between the multipath, bgp dmzlink-bw command is required.

In this example, we have 2 links between R1 and R2. The MED of 192.168.x.x prefixes has equal MED. However, the bandwidth of each link is not equal. 1000kbps and 100kbps as shown in the figure.

Here is the routing table of R2.

R2# sh ip route

Codes: 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

Gateway of last resort is not set

B    192.168.4.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.5.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

     10.0.0.0/24 is subnetted, 2 subnets

C       10.10.1.0 is directly connected, FastEthernet0/0

C       10.10.2.0 is directly connected, FastEthernet0/1

B    192.168.6.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.1.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.2.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

B    192.168.3.0/24 [20/0] via 10.10.2.1, 01:27:13

                    [20/0] via 10.10.1.1, 01:27:13

R2#

We can see from the routing table of R2 that R2 has 2 routes to reach 192.168.x.0/24. But the way R2 sends out packets is 1:1 load sharing although the bandwidth of each link is not equal. The requirement is to do a unequal cost load sharing between R1 and R2. Therefore, we need to enable dmzlink-bw feature on router R2.

Configuration

R2

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 bgp dmzlink-bw
 neighbor 10.10.1.1 remote-as 100
 neighbor 10.10.1.1 dmzlink-bw
 neighbor 10.10.2.1 remote-as 100
 neighbor 10.10.2.1 dmzlink-bw
 maximum-paths 3
 no auto-summary
 !
 address-family nsap
  maximum-paths 3
  no synchronization
 exit-address-family

R2#ping 192.168.6.0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.6.0, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/175/256 ms

Verify Configuration

R2#sh ip bgp 192.168.6.0

BGP routing table entry for 192.168.6.0/24, version 23

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Multipath: eBGP

  Advertised to update-groups:

        1

  100

    10.10.2.1 from 10.10.2.1 (192.168.6.1)

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

      DMZ-Link Bw 1 kbytes

  100

    10.10.1.1 from 10.10.1.1 (192.168.6.1)

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

      DMZ-Link Bw 1250 kbytes

R2#

R2#sh ip route 192.168.6.0

Routing entry for 192.168.6.0/24

  Known via "bgp 200", distance 20, metric 0

  Tag 100, type external

  Last update from 10.10.1.1 00:02:31 ago

  Routing Descriptor Blocks:

  * 10.10.2.1, from 10.10.2.1, 00:02:31 ago

      Route metric is 0, traffic share count is 10

      AS Hops 1

      Route tag 100

    10.10.1.1, from 10.10.1.1, 00:02:31 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 100

We can see in the result of show ip route 192.168.6.0 that traffic share of 2 links is not equal and the proportion of the traffic is according to the link bandwidth which is 1:10. So, the dmzlink-bw was successfully configured.!

BGP dampening

Instability in the BGP domain causes BGP router send the routing updates to its BGP peers. Every time BGP router receives an update it re-calculate its best path. Due to BGP router contains a large number of routes in its routing table, the router need to use a lot of CPU resource and memory to calculate it. If there is a route flap in the network, it will make it worse since router needs to do a recalculation for many times.


Dampening is the feature in Cisco IOS preventing BGP router calculates a large number of routes updates when the route flap. BGP process assigns a penalty to the route each time it flaps. When the penalty exceeds the limit, the route is dampened. It will not accept or announce any routing update from other peer. The penalty decays at the half life rate.


BGP dampening command.


bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]

Example

router bgp 10

bgp dampening 30 1500 10000 120

BGP conditional injection

.

Aggregation of the BGP route is useful to minimize the number of routers in the routing table. However, in some cases we want to have a control over specific route before aggregation. We can use BGP conditional injection to do this. 

This command allows us to inject more specific route and advertise to its BGP neighbors when it receives the aggregate route from the upstream router. The command is "bgp inject-map  exist-map".

Here is the example. 

- R2 advertise aggregate route of 10.0.0.0/8  to R1.

- R1 needs to advertise more specific route to R3 if it receives 10.0.0.0/8 from R2. 

- When R1 has 10.0.0.0/8 in its routing table, it will inject 10.1.1.0/24 in the BGP network and advertise to R3.

Configuration

R1

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 bgp inject-map INJECT exist-map EXIST
 neighbor 192.168.1.2 remote-as 200
 neighbor 192.168.2.2 remote-as 100
 no auto-summary
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
ip prefix-list EXIST seq 5 permit 10.0.0.0/8
ip prefix-list INJECT seq 5 permit 10.1.1.0/24
ip prefix-list SOURCE seq 5 permit 192.168.1.2/32
!
!
!
route-map INJECT permit 10
 set ip address prefix-list INJECT
!
route-map EXIST permit 10
 match ip address prefix-list EXIST
 match ip route-source prefix-list SOURCE
!
!

Verify the configuration

When  R1 does not have 10.0.0.0/8 in its BGP table.

R1#sh ip bgp

R1#

----------------------------------

When  R1 has 10.0.0.0/8 in its BGP table, it will inject and advertise 10.1.1.0/24 to R3

We can see R1 originated the 10.1.1.0/24 network to the BGP process since it has "?" in the path.

R1#sh ip bgp

BGP table version is 9, local router ID is 192.168.2.1

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

              r RIB-failure, S Stale

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

   Network          Next Hop            Metric LocPrf Weight Path

*> 10.0.0.0         192.168.1.2              0             0 200 i

*> 10.1.1.0/24      192.168.1.2                            0 ?

R1#

BGP conditional advertisement

BGP conditional advertisement

BGP conditional advertisement is another feature of  Cisco IOS. It controls the way it advertises the BGP network by considering whether it has or has not a BGP network in its table.

There are 2 command about conditional advertisement.
- neighbor advertise-map <advertise route> exist-map <exist-route>
     =  BGP will advertise <advertise-route> if the router has an <existing route> in its BGP table
- neighbor advertise-map <advertise route> non-exist-map <non-exist-route>
     =  BGP will advertise <advertise-route> if the router do not have an <non-existing route> in its BGP table

--------------------------

Here is the sample configuration of BGP conditional advertisement.


R1 <----->  R2 


R1
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 10.10.18.0 mask 255.255.255.0
 network 10.10.19.0 mask 255.255.255.0
 neighbor 192.168.1.2 remote-as 100
 neighbor 192.168.1.2 advertise-map Conditional-bgp exist-map test

access-list 1 permit 10.10.19.0 0.0.0.255
access-list 2 permit 10.10.18.0 0.0.0.255
!

route-map Conditional-bgp permit 10
 match ip address 1
!
route-map test permit 10
 match ip address 2

----------------------------------

When R1 has network 10.10.18.0/24 in its BGP table. It will advertise network 10.10.19.0/24 out to its neighbor.

R1#sh ip bgp
BGP table version is 8, local router ID is 10.10.19.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.18.0/24    0.0.0.0                  0         32768 i
*> 10.10.19.0/24    0.0.0.0                  0         32768 i   ( advertise out to R2)

Check R2 Routing table 

R2

R2#sh ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 6 subnets

O       10.10.10.0 [110/11] via 192.168.1.1, 01:39:45, FastEthernet0/0

O       10.10.12.0 [110/11] via 192.168.1.1, 01:39:45, FastEthernet0/0

O       10.10.14.0 [110/11] via 192.168.1.1, 01:39:45, FastEthernet0/0

O       10.10.16.0 [110/11] via 192.168.1.1, 01:39:45, FastEthernet0/0

O       10.10.18.0 [110/11] via 192.168.1.1, 00:00:26, FastEthernet0/0

B       10.10.19.0 [200/0] via 192.168.1.1, 00:00:08

------------------------------------

When network 10.10.18.0/24 is deleted from R1 BGP table, R1 stops advertising 10.10.19.0/24

debug ip bgp updates

*Mar  1 01:55:12.003: BPG(0): Condition test changes to Withdraw

*Mar  1 01:55:12.007: BPG(0): Condition test changes to Withdraw

*Mar  1 01:55:12.007: BGP(0): net 10.10.19.0/24 matches ADV MAP Conditional-bgp: bump version to 11

*Mar  1 01:55:12.219: BGP(0): nettable_walker 10.10.19.0/24 route sourced locally

*Mar  1 01:55:12.223: BGP(0): 192.168.1.2 10.10.19.0/24 matches advertise map Conditional-bgp, state: Withdraw

*Mar  1 01:55:12.223: BGP(0): 192.168.1.2 send unreachable 10.10.19.0/24

*Mar  1 01:55:12.223: BGP(0): 192.168.1.2 send UPDATE 10.10.19.0/24 -- unreachable

R2 routing table  ( no network 10.10.19.0/24 )
R2#sh ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
O       10.10.10.0 [110/11] via 192.168.1.1, 01:41:26, FastEthernet0/0
O       10.10.12.0 [110/11] via 192.168.1.1, 01:41:26, FastEthernet0/0
O       10.10.14.0 [110/11] via 192.168.1.1, 01:41:26, FastEthernet0/0
O       10.10.16.0 [110/11] via 192.168.1.1, 01:41:26, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
R2#

Refer from document in cisco website

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094309.shtml

Configure BGP confederation & RR

BGP confederation and Router Reflector

BGP requires full mesh neighbor relationship in order to advertise routes to its peers since BGP does not advertise IBGP to its neighbor. In a large environment which contains a lot of BGP routers in the AS, configuring BGP neighbor is a lot of work to do. For example, if in the AS, there are 10 BGP routers, we need to form (10 x 9)/2 = 45 BGP neighbor relationships. That is a painful in the implementation. Here below are functions to help establish the full mesh in the AS.

BGP confederation

The concept of BGP confederation is to have sub-AS inside an original AS. In the sub-AS we form a full mesh networks. Then, join each sub-AS together. In this case, we will have small sub full mesh network and form a entire AS mesh. Configuring BGP confederation requires only few command. Instead of using a real AS number in the router bgp command, we use sub AS number. However, the real AS is configured by bgp confederation-identifier  under router bgp command. 

Connecting different BGP confederation is a same way as eBGP.  

(See example for the configuration )

Route-Reflector

RR achieve the same result as confederation that is iBGP mesh. There are 2 modes in RR: server and client. All clients will establish the neighbor relationship with the server. Server will reflect routes received from one client to others without having client formed neighbor with each other. 

The command we use for RR is neighbor x.x.x.x route-reflector client.

Configuration Example

-  Configure R1 as AS 100

-  Configure R2 - R5  as AS 200

-  Configure BGP confederation  65001 and 65002 according to the diagram below

-  Configure RR inside AS 65002 

-  Verify full mesh inside each confederation and AS 200

Configuration 

R1

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 neighbor 10.10.10.2 remote-as 200

 no auto-summary

!

R2

router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 65002
 neighbor 3.3.3.3 remote-as 65002
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 10.10.10.1 remote-as 100
 no auto-summary

R3

router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 65001
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 4.4.4.4 remote-as 65002
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 route-reflector-client
 neighbor 5.5.5.5 remote-as 65002
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 route-reflector-client
 no auto-summary
!

R4

router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 neighbor 3.3.3.3 remote-as 65002
 no auto-summary
!

R5

router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 network 100.100.100.0 mask 255.255.255.0
 neighbor 3.3.3.3 remote-as 65002
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary
!

We advertise network 100.100.100.0/24 originated from R5 to BGP.

##################################

Verify neighbor at R3

R3#sh ip bg summary
BGP router identifier 3.3.3.3, local AS number 65002
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4 65001      17      18        1    0    0 00:05:04        0
4.4.4.4         4 65002      23      23        1    0    0 00:19:23        0
5.5.5.5         4 65002      15      15        1    0    0 00:11:24        0
R3#

Verify neighbor at R2
R2#sh ip bgp  summary
BGP router identifier 10.10.10.2, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4 65002      17      17        1    0    0 00:05:41        0
10.10.10.1      4   100      34      33        1    0    0 00:30:08        0
R2#

Verify that R1 has received network information 100.100.100.0/24 from R5

R2# sh ip bgp
BGP table version is 2, local router ID is 10.10.10.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 100.100.100.0/24 5.5.5.5                  0    100      0 (65002) i
R2#


R1#sh ip bgp
BGP table version is 2, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 100.100.100.0/24 10.10.10.2                             0 200 i
R1#

BGP path selection

Interesting artical  about BGP path selection
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

Multi-Exit Discriminator (MED)  for Best Path Selection

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml

BGP Community attribute

BGP Community attributes

BGP community is a optional attribute of BGP routing protocol. It can be considered as a tag in IGP, making a set of IP addresses. The community strings often use to manipulate route, set BGP attributes for a set of ip addresses. We use access-list or prefix list to assign the community to IP addresses. Once the community attribute has been assigned, it can be changed by the route-map function in the router. By default, the community string is a decimal number. However, we can change to a new format (AA:NN) by using ip bgp-community new-format where AA is Autonomous system number and NN is a value as set by ASN.

In addition, there are 3 special community values. The command name and function are as followings.

To assign BGP community string, we use set community <number>/<special community string> in the route-map command. Or, we can use ip community-list <community string> permit/deny <ACL number> as well.

Below is the sample of how to configure BGP special community string and how it works. We will not talk about a decimal community string here since it is functioning the same as a IGP tag. In the example. R1, R2 and R3 are in AS 100 and R4 is in 200. OSPF is running between R1,R2 and R3. Here is the task list of this example.

• Establish eBGP connection between R1 and R4 
• Establish iBGP connection between R1, R2 and R3 with Route-Reflector
• R3 advertise its loopback network in BGP with the community string as shown in the figure.
• Verify route received and community string on R2, R1, and R4

In this example, we expect as followings

• R2 will not have any clue about prefix 150.150.150.0/24 (R1 does not advertise to any of its peers)
• Prefix 100.100.100.0/24 will not be advertised out of the AS 100
• Prefix 200.200.200.0/24 will be advertised normally.

Configuration R3

Advertising its loopback networks in BGP with the community string as shown in the figure.

Create access-list for each loopback interface

ip access-list standard only-100

 permit 100.100.0.0 0.0.255.255

ip access-list standard only-150

 permit 150.150.0.0 0.0.255.255

ip access-list standard only-200

 permit 200.200.0.0 0.0.255.255

Assign the access-list to the route-map and assign the community string according to the diagram.

route-map communityset permit 10

 match ip address only-100

 set community no-export

!

route-map communityset permit 20

 match ip address only-150

 set community no-advertise

!

route-map communityset permit 30

 set community none

Apply policy "communityset" to bgp session. 

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 network 100.100.100.0 mask 255.255.255.0

 network 150.150.150.0 mask 255.255.255.0

 network 200.200.200.0

 neighbor 1.1.1.1 remote-as 100

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 1.1.1.1 send-community both

 neighbor 1.1.1.1 route-map communityset out

 no auto-summary

Note

1. "neighbor send community" needs to apply to the neighbor in order to send out the community string
2. Apply the route-map to neighbor

Verify the configuration

R1 community string Verification

R1#sh ip bgp 100.100.100.0

BGP routing table entry for 100.100.100.0/24, version 24

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)

  Advertised to update-groups:

        2

  Local, (Received from a RR-client)

    3.3.3.3 (metric 21) from 3.3.3.3 (3.3.3.3)

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

      Community: no-export

R1#

R1#sh ip bgp 150.150.150.0

BGP routing table entry for 150.150.150.0/24, version 25

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)

  Not advertised to any peer

  Local, (Received from a RR-client)

    3.3.3.3 (metric 21) from 3.3.3.3 (3.3.3.3)

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

      Community: no-advertise

R1#

Routing table Verification

1) No 150.150.150.0/24 in R2 routing table 

R2 Routing table 

B    200.200.200.0/24 [200/0] via 3.3.3.3, 16:28:17

     1.0.0.0/32 is subnetted, 1 subnets

O       1.1.1.1 [110/11] via 192.168.1.1, 16:54:32, FastEthernet0/0

     2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.2 is directly connected, Loopback0

     100.0.0.0/24 is subnetted, 1 subnets

B       100.100.100.0 [200/0] via 3.3.3.3, 16:52:28

     3.0.0.0/32 is subnetted, 1 subnets

O       3.3.3.3 [110/11] via 192.168.2.2, 16:53:54, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

O       10.1.1.0 [110/20] via 192.168.1.1, 16:54:32, FastEthernet0/0

     123.0.0.0/24 is subnetted, 1 subnets

B       123.1.1.0 [200/0] via 1.1.1.1, 16:49:44

C    192.168.1.0/24 is directly connected, FastEthernet0/0

C    192.168.2.0/24 is directly connected, FastEthernet0/1

R2#

2) No 100.100.100.0/24 in R4 routing table 

Codes: 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

Gateway of last resort is not set

B    200.200.200.0/24 [20/0] via 10.1.1.1, 16:30:36

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, FastEthernet0/0

     123.0.0.0/24 is subnetted, 1 subnets

C       123.1.1.0 is directly connected, Loopback0

R4#

R1 Routing table

Gateway of last resort is not set

B    200.200.200.0/24 [200/0] via 3.3.3.3, 16:31:09

     1.0.0.0/24 is subnetted, 1 subnets

C       1.1.1.0 is directly connected, Loopback0

     2.0.0.0/32 is subnetted, 1 subnets

O       2.2.2.2 [110/11] via 192.168.1.2, 16:57:33, FastEthernet0/1

     100.0.0.0/24 is subnetted, 1 subnets

B       100.100.100.0 [200/0] via 3.3.3.3, 16:39:33

     3.0.0.0/32 is subnetted, 1 subnets

O       3.3.3.3 [110/21] via 192.168.1.2, 16:55:43, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, FastEthernet0/0

     123.0.0.0/24 is subnetted, 1 subnets

B       123.1.1.0 [20/0] via 10.1.1.2, 16:52:35

C    192.168.1.0/24 is directly connected, FastEthernet0/1

O    192.168.2.0/24 [110/20] via 192.168.1.2, 16:56:55, FastEthernet0/1

     150.150.0.0/24 is subnetted, 1 subnets

B       150.150.150.0 [200/0] via 3.3.3.3, 16:35:24

R1#