EBGP Multihop

eBGP (external BGP) by default requires two Cisco IOS routers to be directly connected to each other in order to establish a neighbor adjacency. This is because eBGP routers use a TTL of one for their BGP packets. When the BGP neighbor is more than one hop away, the TTL will decrement to 0 and it will be discarded.

When these two routers are not directly connected then we can still make it work but we’ll have to use multihop. This requirement does not apply to internal BGP.

Here’s an example:

BGP AS1 AS3 R1 R3

Above we will try to configure eBGP between R1 and R3. Since R2 is in the middle, these routers are more than one hop away from each other. Let’s take a look at the configuration:

R1(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2
R3(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2

First I will create some static routes so that R1 and R3 are able to reach each other. Now we can configure eBGP:

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.23.3 remote-as 3
R3(config)#router bgp 3
R3(config-router)#neighbor 192.168.12.1 remote-as 1

Even though this configuration is correct, BGP will not even try to establish a eBGP neighbor adjacency. BGP knows that since these routers are on different subnets, they are not directly connected. We can verify this with the following command:

R1#show ip bgp neighbors | include External
  External BGP neighbor not directly connected.
R3#show ip bgp neighbors | include External
  External BGP neighbor not directly connected.

Just for fun, let’s disable this check so that R1 and R3 try to become eBGP neighbors. We can do that like this:

R1(config-router)#neighbor 192.168.23.3 disable-connected-check
R3(config-router)#neighbor 192.168.12.1 disable-connected-check

Our routers will now try to become eBGP neighbors even though they are not directly connected. Here’s what happens now:

BGP TTL 1

The wireshark capture above shows us that R1 is trying to connect to R3. As you can see the TTL is 1. Once R2 receives this packet it will decrement the TTL by 1 and drop it:

BGP TTL ICMP TTL Exceeded

Above you can see that R2 is dropping this packet since the TTL is exceeded. It will send an ICMP time-to-live exceeded message to R1. Our BGP routers will show a message like this:

R1#
BGP: 192.168.23.3 open failed: Connection timed out; remote host not responding, open active delayed 27593ms (35000ms max, 28% jitter)

This is R1 telling us that it couldn’t connect to R3. To fix this issue, we’ll tell eBGP to increase the TTL. First let’s enable the directly connected check again:

R1(config-router)#no neighbor 192.168.23.3 disable-connected-check
R3(config-router)#no neighbor 192.168.12.1 disable-connected-check

And now we will increase the TTL:

R1(config-router)#neighbor 192.168.23.3 ebgp-multihop 2
R3(config-router)#neighbor 192.168.12.1 ebgp-multihop 2

Use the ebgp-multihop command to increase the TTL. Using a value of 2 is enough in our example. R2 will receive a packet with a TTL of 2, decrements it by 1 and forwards it to R3. We can verify this change by looking at the show ip bgp neighbors command:

R1 & R3
#show ip bgp neighbors | include External
  External BGP neighbor may be up to 2 hops away.

R1 and R3 both agree that the BGP neighbor could be 2 hops away. Here’s what the BGP packet looks like in wireshark:

BGP TTL 2

This capture shows us the TTL of 2. After a few seconds, our routers will become eBGP neighbors:

R1#
%BGP-5-ADJCHANGE: neighbor 192.168.23.3 Up
R3#
%BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up

That’s it, problem solved!

Configurations

Want to take a look for yourself? Here you will find the configuration of each device.

R1

hostname R1
!
interface fastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
ip route 192.168.23.3 255.255.255.255 192.168.12.2
!
router bgp 1
 neighbor 192.168.23.3 remote-as 3
 neighbor 192.168.23.3 ebgp-multihop 2
!
end

R2

hostname R2
!
interface fastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
interface fastEthernet1/0
 ip address 192.168.23.2 255.255.255.0
!
end

R3

hostname R3
!
interface fastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
!
ip route 192.168.12.1 255.255.255.255 192.168.23.2
!
router bgp 3
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.12.1 ebgp-multihop 2
!
end


Even though R1 and R3 are now neighbors, having a non-BGP in router in between R1 and R3 is a bad idea. R1 and R3 might exchange prefixes through BGP but once packets reach R2, it will have no clue where to forward these packets to…

Now you understand how eBGP multihop works, let’s take a look at a more useful scenario:

BGP R1 R2 dual link multihop

Above we have two routers…R1 and R2. They are directly connected but we have two links in between them and we would like to use these for load balancing. Instead of using the IP addresses on these FastEthernet interfaces for the eBGP neighbor adjacency we will use the IP addresses on the loopback interfaces for this. Let’s take a look at the configuration:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 654 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

540 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. Hi Hamood,

    That’s right, if you source eBGP from the loopback interfaces then you’ll need multihop.

    The problem with the R1-R2-R3 scenario is that R2 will never learn about any prefixes, when R1 tries to reach a network behind R3 (or R3 wants to reach something behind R1) then R2 will receive an IP packet with a destination it doesn’t know about.

    If you really had to use eBGP between R1 and R3 then a GRE tunnel might be a solution…

    Rene

  2. Hi Rouzbeh,

    In the example with the two interfaces, we use static routes only for the neighbor adjacency. Once BGP is up and running, we’ll use it to advertise networks. With only two routers there’s no need to run BGP, just imagine that R1 and R2 are part of a much larger network with multiple ASes, routers, etc. :slight_smile:

    Rene

  3. Hi Jason,

    R1(config-router)# neighbor 2.2.2.2 remote-as 2

    That command instructs R1 to establish a neighbor relationship with 2.2.2.2. It does not, however, tell R1 to use any specific interface as source or “from” address when establishing the relationship. By default, BGP will try to use the closest interface to the neighbor to establish the relationship. Knowing this, what do you suppose would happen if we just used the command above to try to establish a BGP neighbor relationship with R2?

    From R2’s perspective it would be receiving packets from R1, but t

    ... Continue reading in our forum

  4. I’m still not clear on why the second scenario requires multihop when the neighbours are directly connected.

    Are you saying that when traffic is sourced from and to a loopback, it is effectively taking 3 hops? (2 of which are virtual within the routers).

  5. Hello Chris

    Essentially, if you use the FastEthernet interfaces to interconnect BGP, then the routers are considered directly connected and you wouldn’t need to use multihop. However, because we are using two redundant links to connect the two routers, if we use the fastEtherent interfaces, and one link goes down, then the BGP connection between them will also go down, thus rendering the redundant link unusable. This is why it is preferable to use the loopback interfaces. However, If you use the loopback interfaces, you can see that these loopbacks are not d

    ... Continue reading in our forum

98 more replies! Ask a question or join the discussion by visiting our Community Forum