ebgp multihop command only applies to loopbacks?

[steven.crutchley]

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:

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?

[Peter Paluch · Accepted solution]

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

[steven.crutchley]

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]

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

[elecommeng]

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

[Ronak Vyas]

Hey there, thank you for sharing the link. It was constructive.

Let me summarize what I understood and what was helpful.

Scenario:
1. The two routers are directly connected. (They have at least one interface each, on the same IP subnet)

2. The two routers want to establish neighbor adjacency using their respective loopback interfaces.

Router A Interfaces - S0/0, Loopback1
Router B Interfaces - S0/1, Loopback1

When Router A sends a neighbor adjacency request from its S0/0 interface, it is received at Router B's S0/1 interface with a TTL=1.
Since we are trying to establish the neighborship with the loopback1 interface of Router-B, the packet is destined for loopback1 and not S0/1 interface on which the packet is received.

The receiving interface S0/1 of Router B understands that the packet is not for it and checks with its IP forwarding (IP Routing) logic for a way to reach the loopback1 IP address.
Router B S0/1 interface learns that the destination address is on loopback1 and that it needs to exit the S0/1 interface to reach the destination.

Router B's IOS packet forwarding logic decrements the TTL value each time a packet exits an interface.
Here, the moment the packet exits Router B S0/1 interface to go to loopback1, its TTL value will be decremented from 1 to 0. And subsequently, the packet will be dropped since the TTL=0.

Hence, when using loopback interfaces for establishing eBGP neighborships between directly connected routers, it is necessary to change the TTL value to at least 2 using the

ebgp-multihop

command.

I hope this helps!

Copied from CCNP Route 300-101 > eBGP Multihop concepts.

Cheers,
RV

[idrees_cse]

Outstanding Explaination. Thank you peter

[milton oliveira vieira]

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

[Ciro Gustavo Mele]

On Router 2

Loopback are number 2 no number 1

neighbor 1.1.1.1 update-source Loopback 2

Ciro Gustavo Mele.