BGP NEXT HOP IN SHARED NETWORK
Next-Hop Attribute shows some different behavior in shared media as well as in Non Broadcast Multi Access Networks. This Blog explains BGP Next-Hop in Shared Network.
Below article will explain the both the behaviors in details with help of lab scenarios.
When running BGP over a multiaccess network such as Ethernet, a BGP router uses the
appropriate address as the next-hop address (by changing the next-hop attribute) to avoid inserting additional hops into the path. This feature is sometimes called a third-party next hop.
appropriate address as the next-hop address (by changing the next-hop attribute) to avoid inserting additional hops into the path. This feature is sometimes called a third-party next hop.
The third-party next-hop address issue also makes sense when you review it from an ISP
perspective. A large ISP at a public peering point has multiple routers peering with different
neighboring routers; it is not possible for one router to peer with every neighboring router at the major public peering points.
perspective. A large ISP at a public peering point has multiple routers peering with different
neighboring routers; it is not possible for one router to peer with every neighboring router at the major public peering points.
In the diagram, R1,R2, and R3 are connected through a L2 Switch in a shared network 9.9.123.0/24. Please see the naming scheme in the diagram.
We have formed the BGP peering b/w R1, R2, and R3 on their interface IPs (i.e. 9.9.123.1, 123.2, and 123.3 respectively).
Example config from R2:
We have formed the BGP peering b/w R1, R2, and R3 on their interface IPs (i.e. 9.9.123.1, 123.2, and 123.3 respectively).
Example config from R2:
router bgp 100
bgp log-neighbor-changes
network 9.9.0.2 mask 255.255.255.255
neighbor 9.9.123.1 remote-as 100
neighbor 9.9.123.3 remote-as 300
Next-Hop for prefix 9.9.0.4/32 on R1 is 9.9.14.4.bgp log-neighbor-changes
network 9.9.0.2 mask 255.255.255.255
neighbor 9.9.123.1 remote-as 100
neighbor 9.9.123.3 remote-as 300
R1#show ip bgp | i 9.9.0.4
*> 9.9.0.4/32 9.9.14.4 0 0 400 i
R1 advertises 9.9.0.4/32 to R2 in shared network. The next-hop for 9.9.0.4/32 on R2 will remain same 9.9.14.4.
R2#show ip bgp | i 9.9.0.4
*>i 9.9.0.4/32 9.9.14.4 0 100 0 400 i
As per the Next-Hop Rule, the next-hop for a BGP prefix changes at eBGP peering.
R2 advertises the prefix 9.9.0.4/32 to R3 with expected next hop of 9.9.123.2 but this is not the case.
R2 will advertise 9.9.0.4/32 to R3 with next hop
9.9.123.1 instead of 9.9.123.2 as R1, R2, R3 are connected through the
shared network and in shared network it will be weird for R3 to go to R2
and then R1 while R1 knows the arp for 9.9.123.1 and can reach R1
directly via L2 switch. This is to avoid an unnecessary extra hop on R3
while reaching 9.9.0.4/32.
R3#show ip bgp | i 9.9.0.4
*> 9.9.0.4/32 9.9.123.1 0 100 400 i
However, if the common medium between routers is a Non Broadcast Multiaccess (NBMA) medium, complications might occur.
Router R1 Has 10.10.10.2 as the Next-Hop Attribute to Reach 172.30.0.0, but It Might Be Unreachable,For example, in above figure, Routers R1, R2, and R3 are connected by Frame Relay. Router R2 can reach network 172.30.0.0 via 10.10.10.2. When Router R2 sends a BGP update to Router R1 about 172.30.0.0, it uses 10.10.10.2 as the next hop, not its own IP address (10.10.10.1). A problem arises if Routers R1 and R3 do not know how to communicate directly. In other words, if Routers R1 and R3 do not have a Frame Relay map entry to reach each other, Router R1 does not know how to reach the next-hop address on Router R3.
This behavior can be overridden in Router R2 by configuring it to advertise itself as the next-hop address for routes sent to Router R1, this configuration is described in the later section “Changing the Next-Hop Attribute.”
