Articles
recent

BGP Next-Hop Behaviour With Multi-path Enabled

Today I am going to talk about BGP Next-Hop Behaviour With Multi-path Enabled.In default configuration, iBGP sessions preserve the next hop attribute learned from eBGP peers i.e. When a BGP speaker advertises the route to a BGP speaker located in its own autonomous system, the advertising speaker shall not modify the NEXT_HOP attribute associated with the route, unless we have next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop.

When we receive same subnet via multiple EBGP Neighbors on a device and we have BGP Multipath configured on it, then based on the BGP Selection Algorithm, multiple paths will be installed in the routing table. 

when the multipath route needs to advertised to the IBGP Peer, then the value of the BGP Next Hop Path Attribute in the update will be local IP instead of the external peer address

Fig 1.1- BGP Next Hop Behaviour with Multi-Path
Configurations on Router R1
!
router bgp 65500
bgp router-id 192.168.10.10
bgp log-neighbor-changes
network 192.168.10.10 mask 255.255.255.255
neighbor 10.10.12.2 remote-as 65400
neighbor 10.10.12.130 remote-as 65400
!

Configurations on Router R2
router bgp 65400
bgp router-id 192.168.10.20
bgp log-neighbor-changes
network 192.168.10.20 mask 255.255.255.255
neighbor 10.10.12.1 remote-as 65500
neighbor 10.10.12.129 remote-as 65500
neighbor 10.10.22.1 remote-as 65400
!

Configurations on Router R3
!
router bgp 65400
bgp router-id 192.168.10.30
bgp log-neighbor-changes
network 192.168.10.30 mask 255.255.255.255
neighbor 10.10.22.2 remote-as 65400
!
ip route 10.10.12.0 255.255.255.0 10.10.22.2 
!

Verify

In Ideal Scenario, when no multipath is configured on R2, then the route for the loopback interface 192.168.10.10/32 of R1 on R2 is learned only via one path in routing table:

R2#sh ip route 192.168.10.10
Routing entry for 192.168.10.10/32
  Known via "bgp 65400", distance 20, metric 0
  Tag 65500, type external
  Last update from 10.10.12.1 00:06:35 ago
  Routing Descriptor Blocks:
  * 10.10.12.1, from 10.10.12.1, 00:06:35 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65500
      MPLS label: none

R2#sh ip bgp 192.168.10.10
BGP routing table entry for 192.168.10.10/32, version 2
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          3
  Refresh Epoch 1
  65500
    10.10.12.1 from 10.10.12.1 (192.168.10.10)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65500
    10.10.12.129 from 10.10.12.129 (192.168.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

R2# <debug ip bgp update>

Jun 23 12:36:18.223: BGP(0): (base) 10.10.22.1 send UPDATE (format) 192.168.10.10/32, next 10.10.12.1, metric 0, path 65500

<>

The route on R3 when received from R2 (IBGP Peer) is with next-hop 10.10.12.1 
Thus the next hop value was not changed by R2 while advertising the route to R3

R3#sh ip bgp 192.168.10.10
BGP routing table entry for 192.168.10.10/32, version 2
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65500
    10.10.12.1 from 10.10.22.2 (192.168.10.20)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R3#sh ip route 192.168.10.10
Routing entry for 192.168.10.10/32
  Known via "bgp 65400", distance 200, metric 0
  Tag 65500, type internal
  Last update from 10.10.12.1 00:01:55 ago
  Routing Descriptor Blocks:
  * 10.10.12.1, from 10.10.22.2, 00:01:55 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65500
      MPLS label: none

When maximum paths command is configured on R2:

R2(config)#router bgp 65400
R2(config-router)#maximum-paths 2

R2#sh ip route 192.168.10.10
Routing entry for 192.168.10.10/32
  Known via "bgp 65400", distance 20, metric 0
  Tag 65500, type external
  Last update from 10.10.12.129 11:20:37 ago
  Routing Descriptor Blocks:
    10.10.12.129, from 10.10.12.129, 11:20:37 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65500
      MPLS label: none
  * 10.10.12.1, from 10.10.12.1, 11:20:37 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65500
      MPLS label: none

R2# <debug ip bgp update>

Jun 23 12:34:58.206: BGP(0): (base) 10.10.22.1 send UPDATE (format) 192.168.10.10/32, next 10.10.22.2, metric 0, path 65500

<>

Then the route on R3 is learned with the Next-Hop of R2 10.10.22.2
Thus the next hop value was changed by R2 while advertising the route to IBGP Peer R3, without any configuration to force the R2 to advertise itself as the next hop.

R3#sh ip bgp 192.168.10.10
BGP routing table entry for 192.168.10.10/32, version 5
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65500
    10.10.22.2 from 10.10.22.2 (192.168.10.20)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R3#sh ip route 192.168.10.10
Routing entry for 192.168.10.10/32
  Known via "bgp 65400", distance 200, metric 0
  Tag 65500, type internal
  Last update from 10.10.22.2 00:00:28 ago
  Routing Descriptor Blocks:
  * 10.10.22.2, from 10.10.22.2, 00:00:28 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65500
      MPLS label: none


Popular Posts

Powered by Blogger.