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