BGP Neighbor Adjacency States

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.

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

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

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

@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?

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

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

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

hello Rene,

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

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

Hi Rene,

What is Connect Timer, is it is second name for Hold time or Keepalive timer?

Hello Navraj

I assume you mean the ConnectRetry timer. This is a separate timer that is used during initial BGP adjacency creation. Specifically, it is set to 60 seconds and is used as the time to wait before a connection is initiated again. It is different than the Hold time or Keepaliave timer. More info about this can be found at this Cisco Documentation.

I hope this has been helpful!

Laz

Hello Rene,

How about configuring Hold-timer as zero on both the peers, BGP will be established and keepalives wont be exchanged, thereby never getting the BGP down.

Am I right?

Hello Tejas

Yes, you can configure the hold timer to be zero. In this case, keepalives are not sent, and the BGP session does remain. This is verified by the BGP RFC 4271. However, this is not an implementation that you should employ in today’s networks. This feature was enabled in order to accommodate running BGP over dialup circuits such as ISDN, where connectivity on demand was configured. The keepalives sent by BGP would continually cause ISDN to redial and connect, resulting in additional costs for the specific circuit.

Today you wouldn’t want to implement a hold down timer of 0 because if a BGP neighbor does indeed go down, a hold down timer of 0 will not allow you to detect it.

I hope this has been helpful!

Laz

Hii Rene.

i am confused with connectRetry timers in IDLE,CONNECT & Active states. "ConnectRetry timers will reset.what will happen if connectRetry timers expires in these states and in which state this timer will reset again???

Regards,
varma

Hello Chandrasekhar

The ConnectRetry Timer plays various roles for different states. However, there seems to be some discrepancy between how Cisco describes it and how it is described in the RFC. Some of the details can be found below, but I believe that the clearest picture can be seen from the RFC, whose link you will find below.

A router will enter the Idle state when BGP is initially activated. At the time of activation, the ConnectRetry timer is undefined and irrelevant. It only begins to have meaning for the Idle state if an error occurs. Specifically, for the Idle state, the ConnetRetry Timer will be set to 60 seconds in the event of a failed start event, or in the event that we reenter the Idle state due to an error at some other stage of the process. The timer must reach zero before another connection attempt is initiated. Further failures to leave the Idle state will cause the ConnectRetry timer to double in length from the previous iteration.

The next state is the Connect state, where a TCP connection is initiated. A 3-way TCP handshake is attempted, and if it completes, the ConnectRetry timer is reset, an Open message is sent to the neighbor, and then the OpenSent state begins. If this process is successful, the ConnectRetry timer plays no role. However, if during the 3-way handshake the ConnectRetry timer depletes before the handshake is complete, then, according to Cisco, the state moves to Active, but according to the RFC 4271, it actually stays in the Connect state and retries the connection.

In the Active state, if the ConnectRetry timer expires, it initiates a TCP connection to the other BGP peer and changes its state back to Connect.

In the OpenSent, OpenConfirm, and Established states, the ConnectRetry timer doesn’t play a role, but if an error occurs, and BGP returns to the Idle state, the ConnectRetry timer is reset to 0.

I hope this has been helpful!

Laz

Hello Rene/Laz,

My questions is regarding the Active and Connect states. I see in your debugs, on R1 BGP goes from Init to Active while on R2 it goes from Init to Connect. Why this discrepancy? I have observed similar results in my Wireshark captures as well. Here is what I am assuming. For the active router, BGP goes from Init to Connect as TCP connection was initiated. While on passive router, TCP connection request was received and hence it goes from Init to Connect. This deduction seems pretty flawed to be honest but after going through numerous sources, this is the only possible reason I could think of. Can you please shed some light on this?

Thanks.

Hello Kunj

Unfortunately, the answer is not very technical. As with many debugs, sometimes events occur quite quickly, and some information may simply be omitted. In this case, it seems that R1 simply went through the states of the FSM quite quickly, so the debug displayed multiple events using a single statement saying that it went from Idle to Active. On R2, the event was not so quick, so it displayed the idle to connect state change.

In the lesson, Rene states that “(it doesn’t show the Connect state in the debug)”.

I hope this has been helpful!

Laz

Hello Rene/Las,
Can u please confirm why and when we need to configure BGP neighborship with APIPA address?
Regards
Unni

Hello Unni

APIPA or Link Local addresses for IPv4 should never be used as the IP addresses of BGP peers. This goes contrary to the address usage rules dictated in RFC 3927. However, some vendors and systems do use them. One such situation is with Amazon’s AWS service, an example of which can be found here. This has been known to be used over an IPsec tunnel setup to Amazon VPC. I am not familiar with other uses of APIPA addresses for such purposes.

I hope this has been helpful!

Laz