EBGP Multihop

Configuring iBGP doesn't require the neighbor address to be directly connected. The best practice for iBGP is to use the loopback address as the ip address configured on the BGP neighbor statement. Loopback interfaces never go down so provided that there is an alternate route to the loopback ip address through an IGP, BGP session will not be torn down.


Using loopback addresses for eBGP is also a good practice if there are multiple links between two routers on different autonomous system as shown on the example diagram below. This will also achieve load balancing.

The initial configuration for this lab is shown below.

R1#
!
interface Serial1/0
ip address 10.10.10.1 255.255.255.0
serial restart-delay 0
end
!
interface Serial1/1
ip address 10.10.20.1 255.255.255.0
serial restart-delay 0
end
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
no auto-summary
!
ip route 2.2.2.2 255.255.255.255 10.10.10.2
ip route 2.2.2.2 255.255.255.255 10.10.20.2

R2#
!
interface Serial1/0
ip address 10.10.10.2 255.255.255.0
serial restart-delay 0
end
!
interface Serial1/1
ip address 10.10.20.2 255.255.255.0
serial restart-delay 0
end
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
no auto-summary
!
ip route 1.1.1.1 255.255.255.255 10.10.10.1
ip route 1.1.1.1 255.255.255.255 10.10.20.1

Notice that in both routers we put 2 static routes to achieve load balancing. Currently the BGP session is not established eventhough both loopbacks are reachable. Now, lets configure "ebgp-multihop" on both routers and see if this will make the BGP session establish.

The purpose of "ebgp-multihop" is to connect to eBGP neighbors that are not directly connected.
As we know, BGP expects eBGP peers to be directly connected but this command will make
neighborship possible even though they are not directly connected.

Now let's configure the routers.

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2

R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2

R1#sh ip bgp sum
BGP router identifier 1.1.1.1, local AS number 1
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     2       0       0        0    0    0 never    Active

The BGP session is not established even though we configured the "ebgp-multihop" command. Before we find out why, lets first discuss the "ebgp-multihop" command. The default value of this command if we don't put anything will be 255. We put a value of 2 because it will take 2 hops to reach 2.2.2.2 from 1.1.1.1 as they are not directly connected. Provided all the requirements are met except the hop count value, if the hop count value is lesser than what it should be, the eBGP neighborship will not be established.


Going back to why its not established, its because by default for BGP to establish the TCP session it will use the outgoing interface ip address as the source. The other router will reject the incoming TCP SYN packets because it doesn't recognize the source IP address as a configured neighbor. In our case, it will source the TCP session using the two physical interfaces ip addresses.

The BGP session updates should be sourced from the IP address that the the neighbor
configured for eBGP Multihop to work. The command "neighbor ip_address update-source
Loopback0" in our example is needed.

Now lets configure, the update-source command sourcing all BGP negiotiations and updates from Loopback0 which are the ip addresses configured on our neighbor statements.

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 update-source Loopback0

R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 update-source Loopback0

R1#sh ip bgp su
*Aug 13 14:41:43.175: %SYS-5-CONFIG_I: Configured from console by consolem
BGP router identifier 1.1.1.1, local AS number 1
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     2      11      11        1    0    0 00:00:47        0

R2#sh ip bgp sum
*Aug 13 14:41:38.099: %SYS-5-CONFIG_I: Configured from console by console
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4     1      11      11        1    0    0 00:00:42        0

BGP session now established. We can see in CEF that this is load balanced.

R1#sh ip cef 2.2.2.2
2.2.2.2/32, version 27, epoch 0, per-destination sharing
0 packets, 0 bytes
via 10.10.20.2, 0 dependencies, recursive
traffic share 1
next hop 10.10.20.2, Serial1/1 via 10.10.20.0/24
valid adjacency
via 10.10.10.2, 0 dependencies, recursive
traffic share 1
next hop 10.10.10.2, Serial1/0 via 10.10.10.0/24
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes

Now, BGP session is established. Let's try shutting down one link and see if the session is still established.

R2(config)#int se1/0
R2(config-if)#shut
R2(config-if)#^Z
R2#sh ihp b
*Aug 13 14:42:38.871: %SYS-5-CONFIG_I: Configured from console by console
*Aug 13 14:42:39.095: %LINK-5-CHANGED: Interface Serial1/0, changed state to administrativ
*Aug 13 14:42:39.095: %ENTITY_ALARM-6-INFO: ASSERT INFO Se1/0 Physical Port Administrative State Down
*Aug 13 14:42:40.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down
R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4     1      12      12        1    0    0 00:01:45        0