cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
23559
Views
55
Helpful
15
Replies

BGP - no route to peer

Mahesh Gohil
Level 7
Level 7

Hi experts,

I am trying to understnad BGP messages and i configured bgp as below.

@@@@@@@@ A-End @@@@@@@

interface Loopback100
ip address 192.168.14.1 255.255.255.255

router bgp 9498
no synchronization
bgp log-neighbor-changes
neighbor 172.16.16.1 remote-as 64520
neighbor 172.16.16.1 update-source Loopback100
no auto-summary

ip route 172.16.16.1 255.255.255.255 10.10.10.2

@@@@@@@@ B-End @@@@@@@

interface Loopback100
ip address 172.16.16.1 255.255.255.255

router bgp 64520
no synchronization
bgp log-neighbor-changes
neighbor 192.168.14.1 remote-as 9498
neighbor 192.168.14.1 ebgp-multihop 3
neighbor 192.168.14.1 update-source Loopback100
no auto-summary

ip route 192.168.14.1 255.255.255.255 10.10.10.1

I purposefully removed ebgp-multihop 3 command from A-end and bgp is not coming up as expected. I have also captured wireshark and i can see that B end is sending TCP packet and A end is sending RST message. I just what to know how A end is sending reset, I mean what is it verifying. I tried to run bgp debug but only getting below message which is misleading. Is there any way to see how router at A end is decided to send TCP RST message.

*Feb 23 18:04:19.811: BGP: 172.16.16.1 active open failed - no route to peer, open active delayed 10240ms (35000ms max, 60% jitter)

Please let me know if my query is confusing.

Regards

Mahesh

1 Accepted Solution

Accepted Solutions

Hi Mahesh,

A wonderful observation! Yes, I was somewhat vague. In fact, for eBGP peers, the ebgp-multihop 1 is the default and entering it explicitly does not change anything because this setting is already present, albeit implicitly. Very good point indeed!

Thank you - I rephrase my statement as follows:

This "directly connected check" is performed for all eBGP peers having  either ebgp-multihop 1 or no ebgp-multihop configured. If ebgp-multihop 2 or more is configured for  a neighbor, this check is not performed.

Would you agree with this formulation?

Best regards,

Peter

View solution in original post

15 Replies 15

Sending packet from your Loopback to the external interface is already one hop. Your packet will not reach the other router as the ttl  will expire before it exits the first router.

There is no reset being sent, but the ttl expiring. You need that ebgp-multihop 3 command to give it a ttl of 3 hops.

Hi,

Thanks for your reply.

Sending packet from your Loopback to the external interface is already one hop. Your packet will not reach the other router as the ttl  will expire before it exits the first router. >>>> If it is so how bgp comes up when we configure between point to point ip ?

There is no reset being sent, but the ttl expiring. You need that ebgp-multihop 3 command to give it a ttl of 3 hops.  >>>>> If ttl expiring then i seen that A-end is already sending TCP reset message.

May be I need to dig more here. If i am getting answer will update surely here.

Regards

Mahesh

Hello everyone,

Sending packet from your Loopback to the external interface is already  one hop. Your packet will not reach the other router as the ttl  will  expire before it exits the first router.

I do not agree with this statement. It is implied here that just because an IP packet is originated with a source IP address of a different interface than the interface through which the packet is going to be sent out, the TTL is going to be decremented. This is not true. The TTL is decremented only when routing a packet. However, originating a packet is never considered routing a packet, regardless of what IP source address was used and which interface was the packet sent out. A node having multiple IP addresses is their owner, and it can at any time use any of them when originating a packet, regardless of the egress interface, and is never going to decrement the TTL just because the packet went out a different interface than the one used to populate the source IP address field.

The exactly same logic is valid when a packet arrives on an interface and the destination IP address is located on a different interface of the same device. Again, the TTL is not decremented here because the IP packet already arrived at a node that is in possession of all its IP addresses, regardless of which interface the packet came in.

From this it follows that if two eBGP speakers are directly connected then sending IP packets with TTL=1 is completely sufficient to establish a working IP connectivity, even if these packets are sent using loopback IP addresses of these two eBGP speakers (trivially demonstrable by sending a ping from own loopback address to the neighbor's loopback address and setting TTL to one - the ping will succeed). However, people often find that despite this basic IP connectivity is working, the eBGP between two directly connected neighbors does not come up without ebgp-multihop if peering these eBGP neighbors by their loopbacks. This leads to various misconceptions about the TTL handling.

The reason for this eBGP behavior is simple but somewhat obscure. Cisco's eBGP implementation makes two independent checks/precautions when sending TCP messages to a peer:

  1. It is verified whether the IP address of the neighbor is from a directly connected network
  2. Packets are sent with TTL=1 if no ebgp-multihop was specified

As explained above, sending packets with TTL=1 is sufficient to make the TCP messages arrive successfully. However, the first check fails: the neighbor's loopback IP address is understandably not present on any directly connected network, hence the message about "no route to peer".

The first test can be deactivated on a per neighbor basis using the disable-connected-check command, i.e. Mahesh's configuration can be made workable without using ebgp-multihop by adding these commands:

Router A:

router bgp 9498

  neighbor 172.16.16.1 disable-connected-check

Router B:

router bgp 64520

  neighbor 192.168.14.1 disable-connected-check

This will allow these two eBGP peers to start communicating even with TTL=1.

Also note that using ebgp-multihop automatically implies disable-connected-check.

Best regards,

Peter

Hi peter,

where were you. When I posted this question you were in my mind

Just one clarification required and i will be able to understand it fully.

  • It is verified whether the IP address of the neighbor is from a directly connected network.

This is in which case: If packets from b-end sent with TTL of 3 then also this rule applies ?. Or only applies when sent with TTL =1.

In my case when I verified below observation found

> B-end send TCP packet with TTL=3 because it is configured with ebgp-multihop 3

> No visibility at A-end but seen that A-end pop log message: no route to peer and send RST message, also i check that when A-end send TCP RST packet it set TTL of 255, may be sending all defaults....not sure.

Regards

Mahesh

Hello Mahesh,

Hey, I'm not the only guy here who happens to know things But thank you, I appreciate that.

  • It is verified whether the IP address of the neighbor is from a directly connected network.

This  is in which case: If packets from b-end sent with TTL of 3 then also  this rule applies ?. Or only applies when sent with TTL =1.

This "directly connected check" is performed for all eBGP peers for which no ebgp-multihop is configured. If ebgp-multihop is configured for a neighbor, this check is not performed - that is why I wrote that using ebgp-multihop implies disable-connected-check.

> B-end send TCP packet with TTL=3 because it is configured with ebgp-multihop 3

>  No visibility at A-end but seen that A-end pop log message: no route to  peer and send RST message, also i check that when A-end send TCP RST  packet it set TTL of 255, may be sending all defaults....not sure.

My view on this: B sends TCP messages with TTL=3 and A receives them. However, when A - not using the ebgp-multihop - wants to answer, it finds out that the neighbor is not directly connected and no ebgp-multihop is configured for it, clearly a situation that prevents the BGP peering to be successfully established. Therefore, the only thing router A can do is to refuse the BGP peering by sending a TCP RST back. Router A could have remained totally silent but perhaps sending the TCP RST back is a better thing to do because it immediately makes clear to router B that this peering is not going to go up.

Best regards,

Peter

Hi Peter,

Thanks a lot for detailed answer.

This "directly connected check" is performed for all eBGP peers for which no ebgp-multihop is configured. If ebgp-multihop is configured for a neighbor, this check is not performed - that is why I wrote that using ebgp-multihop implies disable-connected-check.

Now let's forget ebgp-multihop 3 and let's talk about ebgp-multihop 2 which is sufficient I think. So let's assume i configured ebgp-multihop 2 and b-end and ebgp-multihop 1 at e-end and bgp is not coming up.  I was expecting that a-end will send atleast TCP packet (not RST) with TTL=1 and then b-end will deny the same stating that no route to peer.

May be ebgp-multihop 1 is treated like i have not configured that command or we can say it is configured to it's default value.

Now here above quoted message seems confusing atleast to me. If i modified this as below then it is not confusing at all.

"" This "directly connected check" is performed for all eBGP peers for which 
"no ebgp-multihop" configured or configured with "ebgp-multihop 1" is configured. ""

or may be you have some other opinion.

Thanks in advance.
Mahesh



Hi Mahesh,

A wonderful observation! Yes, I was somewhat vague. In fact, for eBGP peers, the ebgp-multihop 1 is the default and entering it explicitly does not change anything because this setting is already present, albeit implicitly. Very good point indeed!

Thank you - I rephrase my statement as follows:

This "directly connected check" is performed for all eBGP peers having  either ebgp-multihop 1 or no ebgp-multihop configured. If ebgp-multihop 2 or more is configured for  a neighbor, this check is not performed.

Would you agree with this formulation?

Best regards,

Peter

Awesome Explanation Peter. Super like :-)

Vijay,

Thank you very, very much!

Best regards,

Peter

Hey Peter,

My answer was based on Cisco Press CCIE Study Guide book which has the following example:

"First, the neighbor remote-as commands refer to a different AS than does the router bgp command,

which implies that the peer is an eBGP peer. Second, R3 had to configure the

neighbor 4.4.4.4 ebgpmultihop 2 command (and R4 with a similar command) or

the peer connection would not have formed.

For eBGP connections, Cisco IOS defaults the IP packet’s TTL field to a value of 1, based

on the assumption that the interface IP addresses will be used for peering (like R1-R6 in Example 10-2).

In this example, if R3 had not used multihop, it would have sent packets to R4 with TTL 1.

R4 would have received the packet (TTL 1 at that point), then attempt to route the packet to its

loopback interface—a process that would decrement the TTL to 0, causing R4 to drop the packet.

So, even though the router is only one hop away, think of the loopback as being on the other side

of the router, requiring that extra hop."

The above is verbatim as written in the book. I am not sure if the author of this book has a different view or they are simply wrong?

Hello,

If the book puts it that way then I am willing to say that the book is wrong on the subject which is sad, considering the high level this book should maintain. Routing packets is performed only if the packets are not destined to the local host. However, if a packet arrives that is addressed to one of possibly many IP addresses of the receiving host, the packet is processed immediately and directly, and it is not routed, hence its TTL is not decremented in any way. After all, why would the operating system of the host uselessly "route" the packet to the loopback interface when it already knows that it is addressed to itself?

Best regards,

Peter

Peter,

You are right, I did some further digging and found this document from IETF.

http://www.ietf.org/mail-archive/web/pim/current/msg02033.html

Thanks for your insightful postings.

Hello my friend,

An interesting thread you've linked. Thank you!

Best regards,

Peter

I just want to thank you!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: