In the last article, we mentioned that there are two forms of BGP sessions: IBGP and EBGP. By default, BGP speakers are supposed to be directly connected for an EBGP session to form between them; however, there are situations when this sort of direct connection is not possible and we need a method for the peers to form a session called Multihop EBGP.

CCNA Training – Resources (Intense)

IBGP peers Do Not Have to Be Directly Connected

Above I said that by default, EBGP peers need to be directly connected for them to form an EBGP session. This requirement does not apply to IBGP peers, as we will now consider using the network diagram below:

The configuration on the routers is as follows:

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.13.1 255.255.255.0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.23.2 remote-as 1
 no auto-summary
!
ip route 192.168.23.0 255.255.255.0 192.168.13.3
hostname R2
!
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.13.1 remote-as 1
 no auto-summary
!
ip route 192.168.13.0 255.255.255.0 192.168.23.3
hostname R3
!
interface FastEthernet0/0
 ip address 192.168.13.3 255.255.255.0
!
interface FastEthernet0/1
 ip address 192.168.23.3 255.255.255.0

The BGP session between R1 and R2 will form without any extra configuration on these peers even though they are not directly connected.

If we were to look at one of the BGP messages between these two peers, we will see that the TTL in the IP header is 255 (from the initiating peer or 254 when it gets to the other peer).

We will keep this observation here for now while we move on to EBGP peering sessions.

EBGP Peering Session

For our EBGP scenario, we will use the network diagram below. In this scenario, both BGP speakers are directly connected.

The configuration on the routers is as follows:

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
router bgp 1
 neighbor 192.168.12.2 remote-as 2
!
hostname R2
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
router bgp 2
 neighbor 192.168.12.1 remote-as 1
!

The EBGP session forms between R1 and R2 because the peers are directly connected. Also, if we were to look into one of the BGP packets, we will notice that the TTL in the IP header is set to 1.

Therefore, by default (without any extra configuration), Cisco sets the TTL in EBGP session packets to 1 unlike in the case of IBGP, where the maximum TTL value is used.

Multihop EBGP

Now, let’s consider multihop EBGP using the network diagram below. Note that the EBGP session is between R1 and R2; R3 does not have BGP enabled.

The configuration on the routers is as follows (the configuration on R3 remains the same as in the IBGP scenario):

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.13.1 255.255.255.0
!
router bgp 1
 neighbor 192.168.23.2 remote-as 2
!
ip route 192.168.23.0 255.255.255.0 192.168.13.3
hostname R2
!
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
!
router bgp 2
 neighbor 192.168.13.1 remote-as 1
!
ip route 192.168.13.0 255.255.255.0 192.168.23.3

In this scenario, if you attempt to capture BGP-related TCP packets and other BGP messages across the link, you will not see any packets because the routers do not even attempt to establish a BGP session. We see the reason for this in the show ip bgp neighbors command output:

Therefore, we see that for the EBGP session to be formed, Cisco’s implementation does two things by default (without any extra configuration): it checks that the peers are directly connected and it sets the TTL in the IP header to 1.

To form an EBGP session between two indirectly connected peers, we need to configure the neighbor ebgp-multihop
command so that the EBGP peers can be at a maximum hop count specified by that command instead of the default hop count of 1.

The configuration on R1 is

neighbor 192.168.23.2 ebgp-multihop

, while the configuration on R2 is

neighbor 192.168.13.1 ebgp-multihop

. A snippet of the show ip bgp neighbors command shows us that the BGP session has been established:

Using the ebgp-multihop command without any maximum hop count value sets that hop-count (or TTL) to the maximum value of 255. In our case, however, a maximum hop count of 2 would have also worked.

EBGP Session Between Loopback Interfaces

There is an interesting discussion about EBGP peering sessions using loopback interfaces as follows: “Must you use the ebgp-multihop command for EBGP sessions when peering with Loopback interfaces between directly connected peers?” The default answer is that this command is required; but I will show that this answer is not necessarily true. Consider the following scenario:

The configuration on the routers is as follows:

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
router bgp 1
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source lo0
!
ip route 2.2.2.2 255.255.255.255 192.168.12.2
hostname R2
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
router bgp 2
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source lo0
!
ip route 1.1.1.1 255.255.255.255 192.168.12.1

This EBGP session will not be formed because, even though the neighbors are directly connected via their Fa0/0 interfaces, the neighbor statements under the BGP process specify neighbors that are not “directly connected”; i.e., 1.1.1.1 and 2.2.2.2 are not directly connected.

If we were to configure

neighbor 2.2.2.2 ebgp-multihop 2

on R1 and

neighbor 1.1.1.1 ebgp-multihop 2

on R2, the EBGP session will form as shown below:

But why did the session come up? Was it because we used the ebgp-multihop command to increase the hop count between R1 and R2 from 1 to 2? What I am asking is: Do we need a TTL of 2 to get from R1’s Loopback interface to R2’s Loopback interface? Let’s investigate using traceroute, which uses incrementing TTL values. I will traceroute between the loopback interfaces to see what TTL value is required.

As you can see, we actually only need a TTL value of 1 between the loopback interfaces. Therefore, the ebgp-multihop command must be performing another function other than increasing the TTL value—it disables the requirement that EBGP peers must be directly connected.

Note: This second function of the ebgp-multihop command applies only when the maximum hop count is greater than 1; i.e., neighbor x.x.x.x ebgp-multihop 1 does not disable the directly connected check.

To confirm this, we will remove the ebgp-multihop command and instead enter the other command on Cisco IOS that disabled the requirement for neighbors to be directly connected: neighbor disable-connected-check.

Notice that the EBGP session went down and came back up. This tells us that we don’t have to use the ebgp-multihop command when forming EBGP session between directly connected peers over their loopback interfaces; we can use the disable-connected-check command.

Summary

In this article, we have considered multihop EBGP. We discussed that, by design, EBGP peers are supposed to be directly connected—a requirement that does not apply to IBGP sessions. We have seen how to override this default behavior using the ebgp-multihop command. We also discovered that not only does the ebgp-multihop command increase the maximum hop count between EBGP peers, it also implicitly disables the directly connected check. Finally, we saw how we can use the disable-connected-check command to establish EBGP sessions over loopback interfaces instead of the ebgp-multihop command.

References and Further Reading

  1. Cisco IOS IP Routing: BGP Command Reference: neighbor ebgp-multihop: http://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp3.html#wp1106590
  2. Cisco IOS IP Routing: BGP Command Reference: neighbor disable-connected-check: http://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp3.html#wp1106122