cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
47719
Views
95
Helpful
7
Replies
steven.crutchley
Beginner

ebgp multihop command only applies to loopbacks?

If I pair up two routers using eBGP using loopbacks as the source and one router between them, the ebgp-multihop 2 command lets them come up as neighbors. This should not work however as they are more than 2 hops away.

For example I have the following network:

bgp question.png

The configuration on each router is:

ROUTER 1
----------
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface Serial0/0
ip address 80.80.80.1 255.255.255.0
clock rate 2000000
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback1
no auto-summary
!
ip route 2.2.2.2 255.255.255.255 Serial0/0


ROUTER 2
----------
interface Loopback1
ip address 2.2.2.2 255.255.255.255
!
interface Serial0/1
ip address 90.90.90.1 255.255.255.0
clock rate 2000000
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback1
no auto-summary
!
ip route 1.1.1.1 255.255.255.255 Serial0/1


ROUTER 3
----------
interface Serial0/0
ip address 80.80.80.2 255.255.255.0
clock rate 2000000
!
interface Serial0/1
ip address 90.90.90.2 255.255.255.0
clock rate 2000000
!
ip route 1.1.1.1 255.255.255.255 Serial0/0
ip route 2.2.2.2 255.255.255.255 Serial0/1
!

In this instance the neighborship comes up. Not that I'm complaining but shouldn't I need ebgp-multihop 3 to get this working?

1 ACCEPTED SOLUTION

Accepted Solutions
Peter Paluch
Hall of Fame Cisco Employee

Hello Steven,

If I pair up two routers using eBGP using loopbacks as the source and one router between them, the ebgp-multihop 2 command lets them come up as neighbors. This should not work however as they are more than 2 hops away.

No, they aren't. They are just 2 hops away. You must count routers, not links. When sending packets to a distant router, with respect to the hop count, it is irrelevant which of the destination router's IP addresses you are talking to. In your case, when R1 sends a packet with TTL=2 towards R3, the TTL gets decremented on R2 to TTL=1 and the packet arrives to R3. There, the packet is not routed anymore because it has already been delievered to the destination device, so the TTL is not decremented on R3 anymore.

I believe that a part of this confusion stems from the fact that even if you have two routers connected back to back and run eBGP between them, you are told to use ebgp-multihop 2 if you are peering them using their loopbacks. This creates a notion as if talking to the opposite router's loopback involved decrementing the TTL. However, there is a totally different and slightly hidden agenda inside: Cisco's BGP implementation makes two precautions when establishing eBGP neighborships:

  1. It checks whether the client is on a directly connected network. If it is not, it does not even try to establish the relationship. This check can be deactivated on a per-neighbor basis using the neighbor disable-connected-check
  2. It sets the TTL of packets carrying BGP messages to 1, unless the ebgp-multihop is configured. If the ebgp-multihop is configured, the router automatically and implicitly behaves to the neighbor as if the disable-connected-check was configured. In other words, using ebgp-multihop automatically implies disable-connected-check

In fact, the disable-connected-check was created precisely for the purpose of peering two back-to-back routers on their loopbacks without using the ebgp-multihop. So in other words, if you're talking to a directly connected eBGP neighbor by its loopback address, you are perfectly fine with TTL=1 (i.e. don't use the ebgp-multihop), just use the disable-connected-check and the peering will come up.

Of course, please feel welcome to ask further!

Best regards,

Peter

View solution in original post

7 REPLIES 7
Peter Paluch
Hall of Fame Cisco Employee

Hello Steven,

If I pair up two routers using eBGP using loopbacks as the source and one router between them, the ebgp-multihop 2 command lets them come up as neighbors. This should not work however as they are more than 2 hops away.

No, they aren't. They are just 2 hops away. You must count routers, not links. When sending packets to a distant router, with respect to the hop count, it is irrelevant which of the destination router's IP addresses you are talking to. In your case, when R1 sends a packet with TTL=2 towards R3, the TTL gets decremented on R2 to TTL=1 and the packet arrives to R3. There, the packet is not routed anymore because it has already been delievered to the destination device, so the TTL is not decremented on R3 anymore.

I believe that a part of this confusion stems from the fact that even if you have two routers connected back to back and run eBGP between them, you are told to use ebgp-multihop 2 if you are peering them using their loopbacks. This creates a notion as if talking to the opposite router's loopback involved decrementing the TTL. However, there is a totally different and slightly hidden agenda inside: Cisco's BGP implementation makes two precautions when establishing eBGP neighborships:

  1. It checks whether the client is on a directly connected network. If it is not, it does not even try to establish the relationship. This check can be deactivated on a per-neighbor basis using the neighbor disable-connected-check
  2. It sets the TTL of packets carrying BGP messages to 1, unless the ebgp-multihop is configured. If the ebgp-multihop is configured, the router automatically and implicitly behaves to the neighbor as if the disable-connected-check was configured. In other words, using ebgp-multihop automatically implies disable-connected-check

In fact, the disable-connected-check was created precisely for the purpose of peering two back-to-back routers on their loopbacks without using the ebgp-multihop. So in other words, if you're talking to a directly connected eBGP neighbor by its loopback address, you are perfectly fine with TTL=1 (i.e. don't use the ebgp-multihop), just use the disable-connected-check and the peering will come up.

Of course, please feel welcome to ask further!

Best regards,

Peter

View solution in original post

Hi Peter. Thank you for your answer it is very helpful

I have a couple of queries though...

So what you are saying is that if two routers are connected back to back and using loopbacks are their respective sources I can:

1) Type neighbor disable-connected-check

OR

2) Type ebgp-multihop which in effect behaves as if I have typed neighbor disable-connected-check

Both if these commands will make the TTL not decrement when the packet moves to a loopback interface.

My question then is that if I have two routers that are directly connected and I enter ebgp-multihop 1 on their respective neighborship statements, will the neighborship form?

The TTL check on the loopbacks will not be done and they are in fact, only 1 hop away...

Also, I not sure on what you mean by "It checks whether the client is on a directly connected network. If it is not, it does not even try to establish the relationship." - what relationship are you refering to? The bgp relationship? If that is the case then your statement implies that two directly connected neighbors cannot become eBGP peers which I know can't be the case. Can you elaborate on that?

Peter Paluch
Hall of Fame Cisco Employee

Hello Steven,

So what you are saying is that if two routers are connected back to back and using loopbacks are their respective sources I can:

1) Type neighbor disable-connected-check

OR

2) Type ebgp-multihop which in effect behaves as if I have typed neighbor disable-connected-check

Yes, that is correct. Recall, though, that ebgp-multihop without a numerical argument causes the TTL to be set to 255. Once again, the disable-connected-check is not the same as ebgp-multihop: the disable-connected-check does not modify the TTL. On the other hand, configuring ebgp-multihop cuases the disable-connected-check to be activated automatically.

Both if these commands will make the TTL not decrement when the packet moves to a loopback interface

I am not sure if I get you on this one. TTL is decremented when packets are routed through a router. TTL is not decremented as a result of these commands.

My question then is that if I have two routers that are directly connected and I enter ebgp-multihop 1 on their respective neighborship statements, will the neighborship form?

No, it won't, because ebgp-multihop 1 is the default. Even if you specified that command, no new command would be added to the running-config. The ebgp-multihop will imply disable-connected-check only if the argument is higher than 2 (or is not present, signifying 255).

So, the eBGP neighborship between two back-to-back routers peered on their loopback addresses will form if:

  • either disable-connected-check is configured for a neighbor
  • or ebgp-multihop either without an explicit TTL or with an explicit TTL set to at least 2 (because it implies disable-connected-check - the TTL set to 2 or more is not that relevant in the back-to-back connection)

Also, I not sure on what you mean by "It checks whether the client is on  a directly connected network. If it is not, it does not even try to  establish the relationship." - what relationship are you refering to?  The bgp relationship?

Yes, by "relationship", I am referring to BGP peering.

If that is the case then your statement implies  that two directly connected neighbors cannot become eBGP peers which I  know can't be the case. Can you elaborate on that?

I am not saying that two directly connected neighbors cannot become eBGP peers. The Step 2 says:

It sets the TTL of packets carrying BGP messages to 1, unless the ebgp-multihop is configured.  [... cut ...] In other words, using ebgp-multihop automatically implies disable-connected-check

Let's take it one step at a time. For an eBGP peering to be successfully established, each BGP peer must

  1. consider the other eBGP peer as directly connected, or skip this check
  2. send its packets with a sufficient TTL so that they can reach the other eBGP peer

The first requirement is either met by referring to the other eBGP peer by its address on a common interconnection (if such exists at all), or by using the disable-connected-check, or by configuring the ebgp-multihop because configuring it automatically activates the disable-connected-check along.

The second requirement is either met by having the eBGP peer directly connected, in which case the default TTL=1 is sufficient, or by configuring ebgp-multihop with a sufficient TTL.

I am not certain if I this all is understandable... so please feel welcome to ask further.

Looking forward to your response.

Best regards,

Peter

Kindly read the following,

https://books.google.com.eg/books?id=li2bKtSNsEkC&pg=PA428&lpg=PA428&dq=loopback+interface+decrement+ttl&source=bl&ots=7PhlZQ-dHS&sig=_vqVcqFjcGiY7kRlDiOetk1LkXI&hl=ar&sa=X&ved=0ahUKEwju18yPj5HPAhVGthoKHa6yC4wQ6AEIPjAC#v=onepage&q=loopback%20interface%20decrement%20ttl&f=false

idrees_cse
Beginner

Outstanding Explaination. Thank you peter

Hi guys!

I was looking for ebgp-multihop, and simulating the same topology R1-->R2-->R3.

The BGP session between R1 and R3 is up and running, I'm advertising the networks and through BPG and I can see on the routing table, but can't reach LAN R1 to LAN R3 even with the routing table appearing OK. I saw on the cef, that the traffic appears to going firstly to R2 instead to R3 (R3 is the next-hop on the routing table, but it appears the traffic is flowing through R2).

After add static routes for both LANs on R2, it worked fine. I was wondering if it's really necessary, because my intension was only advertise on the BGP and traffic works. For me it doesn't make sense to add static routes on the router on the middle of the path.

If you've any information about that, please share that with us.

Thank you!

MOV

On Router 2

Loopback are number 2 no number 1

neighbor 1.1.1.1 update-source Loopback 2

Ciro Gustavo Mele.