BGP Neighbor Adjacency States

(Rene Molenaar) #1

This topic is to discuss the following lesson:

0 Likes
(Joey B) #2

This information on how BGP neighbors establish adjacency is articulate and useful. Thank You!

Joey

0 Likes
(kandhla c) #3

Hi Rene

Thank you for great article. I had a question though.
Why didn’t R1 enter connect state and instead shifted to Active straight from idle? On the other hand i see R2 did enter connect state?

thanks
Kandhla

0 Likes
(Rene Molenaar) #4

Hi Kandhla,

Good question, I’m not sure why it doesn’t show up initially…

Rene

0 Likes
(Jie C) #5

Hei Rene,
Thanks for the lesson, in my working experience, i am stuck in a situation for 2 sites. i have the ebgp peering up, but i am receiving 0 prefix from my isp. The isp said when they show ip bgp nei adverticed route that are hundreds of routes advertised, they can receive our route. Any good debug command to troule should this? We have plain bgp config, the same config (different peering ip though) is working with other sites.

One interesting thing is that when i ping the isp with mtu 1500 it does not work, but it works with 1496. After reading cisco doc, there was a solution which is changing the ip tcp adjuest-mss to 1000 it helps with one location but the other one still has no luck.

0 Likes
(Rene Molenaar) #6

Hi Jie,

It’s possible that the MTU is causing your issue. Your ISP might be sending BGP updates of 1500 bytes which are dropped on your end. Here’s the default TCP segment size that is used for BGP:

R1#show ip bgp neighbors 192.168.12.2 | include segment
Maximum output segment queue size: 50
Datagrams (max data segment is 1460 bytes):

The segment size is 1460 bytes, add a TCP header (20 bytes) and IP header (20 bytes) and you have a 1500 byte packet. In other words, you should be able to send/receive up to 1500 bytes which is not possible at the moment.

There’s two ways how you can fix this. BGP uses path MTU discovery which you can verify here:

R1#show ip bgp neighbors 192.168.12.2 | include tcp
  Transport(tcp) path-mtu-discovery is enabled

So if we reduce the MTU, BGP should reduce its MSS:

R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip mtu 1400

R1#clear ip bgp *

Here’s the new MSS:

R1#show ip bgp neighbors 192.168.12.2 | include segment
Maximum output segment queue size: 50
Datagrams (max data segment is 1360 bytes):

You shouldn’t have any issues now.

The other way to solve this is by changing the TCP MSS manually. The command you used is for clients, not for the router itself. Here’s an example if you want to learn more. Try this instead:

R1(config)#interface GigabitEthernet 0/1
R1(config-if)#no ip mtu 1400

R1(config)#ip tcp mss 1450

R1#clear ip bgp *

R1#show ip bgp neighbors 192.168.12.2 | include segment
Maximum output segment queue size: 50
Datagrams (max data segment is 1450 bytes):

This should solve the problem.

Rene

1 Like
(Sravanthi N) #7

Hi Rene,

In ebgp loop avoidance is done by as-path, if bgp sees it’s own AS coming from a neighbor it will be ignored. And in Opensent stage: This is also the moment where BGP decides whether we use EBGP or IBGP (since we check the AS number). How is this different from ebgp loop avoidance, bgp will see its own AS and considers it as IBGP but not ebgp loop avoidance ? Please clarify. Thank you!

0 Likes
(Andrew P) #8

Sravanthi,
The neighbor relationship defines whether the neighbor is considered external or internal. If you form a neighbor relationship with a BGP router that has the same ASN as you, then it is internal. Since a neighbor relationship must be established before NLRI is exchanged, there is no conflict, since an iBGP neighbor is not subjected to the eBGP loop avoidance techniques you mention.

0 Likes
(Roland W) #9

I know, that the neighbor with the lowest router-id initiates the connection, but at which point in the exchange is it determined who is going to be the active vs passive neighbor. i.e. who will have the local port of 179 when running the command “sh ip bgp neigh | i host” ?

Thank you.

Roland

0 Likes
(Roland W) #10

please disregard my last question. I ran a wireshark capture and it seems the router-id determination only comes into play when thereis a “collision” when both sessions try to initiate the bgp session at the same time. Otherwise no matter what the router id is it appears the first bgp keeaplive that makes it to the other side is the one that is listed as the initiator/the router with the “random” source port and the remote router will show the port of 179.

Thank you.

Roland

0 Likes
(Brian C) #11

OMG RENE! your FSM Diagram is so easy to understand.

I bought this book called Routing TCP/IP, Volume II: CCIE Professional Development 2
Great book but they have very complex descriptions on some things let me show you their chart lol… your chart below nocked it out of the ball park. don’t get me wrong that’s a great book but its hard as hex to understand and works better when paired with something like your website which can break it down in simple terms. I just had to laugh over the two diagrams though as yours was so easy to understand lol…

Capture

now compare that to yours…

Capture

1 Like
(Deep) #12

@ReneMolenaar @andrew @lagapides
Is it possible for BGP packets: control and data packets to be segregated into different queues? I meant I want BGP session to be never go down even in case of congestion. I want BGP peering intact even there is no TCP data passing! Do we need to change TCP behavior or some QOS precedence for only BGP control packets?

0 Likes
(Rene Molenaar) #13

Hi Deep,

That will be difficult, all BGP traffic goes through the same TCP session (TCP port 179). If you want to make sure BGP remains up during congestion, I would configure your router to give it some preference. By default, all BGP traffic is marked with CS6.

If you really want to do this, I guess you could go crazy by doing some inspection, looking into the BGP packets only give preference to the “KEEPALIVE” packets.

Rene

0 Likes
(Deep) #14

Rene, how could we give preference to keepalives only? Can’t understand what u mean by inspection; if you meant packet capture!

0 Likes
(Lazaros Agapides) #15

Hello Deep

Inspection is a method by which QoS classification can be applied to specific types of packets. Specifically, it is possible to do either header inspection or payload inspection in order to determine if a packet is a BGP Keepalive packet, and if so, to classify it appropriately for QoS precedence. You can find out more about inspection at the following lesson:


I hope this has been helpful!

Laz

0 Likes
(Pinki D) #16

hello Rene,

can you explain why we cant have Load Balancing in Bgp? also whats the advantage of BGP over Default route?

0 Likes
(Lazaros Agapides) #17

Hello Pinki

It is possible to apply load balancing in BGP. BGP will not perform Equal Cost Multi-Path (ECMP) routing by default but it can be configured to do so. Specifically, you can use BGP multipath load sharing. You can see how to configure eBGP and iBGP to use more than one path in the following lesson:

Additionally, it is possible for BGP to advertise multiple paths for the same prefix allowing traffic to take various paths to the destination. This is called BGP Additional Paths feature and you can find out more about it at this lesson:

I hope this has been helpful!

Laz

0 Likes