Cisco SPCOR BGP Neighbor States

It is very important to know the BGP neighbor states for the theory as well as practical application of the BGP protocol in the context of SPCOR.

This post on the subject is borrowed from the content of our SPCOR course here at Lammle.com. This course is currently under development as part of our Professional level membership and is a one of a kind training experience for this difficult to find content.

There are six neighbor states in BGP that you should be familiar with. Here is the information you should know about each state, especially of you are thinking about pursuing professional certification in this area.

Idle State

The idle state is one of those BGP states that typically strikes fear and dismay in the hearts of engineers. This and the active state are often states that devices get “stuck” in due to some misconfiguration issue.

The idle state is how BGP starts its life. But note, it should not remain in this state for long. When you provide the correct configuration for BGP, it will leave this state and enter the Connect state. By the way, if you have a misconfiguration and you are indeed “stuck” in the idle state, your system will refuse all attempts at BGP connections.

Your BGP speaker might hit the idle state due to an error, but notice that it will attempt the connect state after a timer-controlled period of wait time. This time is known as the ConnectRetry timer.

Connect State

This is an aptly named state for sure. Here your BGP speaker is waiting for the TCP session to complete. If all goes well, your BGP speaker will complete the session, send an Open message, and then enters the OpenSent state.

If there are issues with the TCP connection, your device might enter the active or the idle states.

Active State

Here your router is attempting to initiate the TCP connection with the neighbor. Notice that if things go well here, your device will transition to the OpenSent state. If things do not go well here, your device might stay in active, head back to the connect state, or head to the idle state. Much of this depends on the ConnectRetry timer of course.

OpenSent State

In this state, your device has sent the open message and is waiting to hear the open message from the neighbor. Of course, your local router will check all of the field information and if there is a problem, it will send a notification message which results in the idle state again.

If things go well, the OpenSent state transitions to the OpenConfirm state.

OpenConfirm State

In this state, your local BGP speaker is about to finish its peering work. It is waiting for a Keepalive from the neighbor so it can achieve the established state. Of course, should a notification message be received, it is off to the idle state.

Established State

In this state, your BGP speakers are fully adjacent and can exchange the updates and keepalive messages that make it do its magic. Remember, notification messages indicating an error can cause the neighborship to return to the idle state.

Remember, when you run a show ip bgp summary and you do not see state information for the peer, you are in the established state. That column of state is now showing the number of prefixes received from the neighbor.