Explanation of BGP Neighbor Adjacency States on Cisco Devices

Border Gateway Protocol (BGP) is the fundamental routing protocol that is used on the Internet.  Like most routing protocols, BGP depends upon the creation of neighbor adjacencies between BGP routers to exchange prefixes and routing information. 

In order to successfully create these neighbor adjacencies, they go through a series of neighbor adjacency states. 

In this article, we’ll describe the BGP states and the process through which BGP routers go to become neighbors and begin exchanging routing information.

Fundamentals of BGP Neighbor Adjacencies

BGP is known as a path-vector routing protocol, which is somewhat different from the more conventional link-state or distance-vector routing protocols. 

As such, it is unique in some of the ways it operates as well as in the associated terminology that is used.

BGP peering

Unlike other routing protocols, such as EIGRP or OSPF, BGP neighbors can only be created manually using the neighbor command. 

BGP peers, once configured, begin communicating over a TCP session that uses port 179.  A BGP neighbor adjacency is often called a BGP peering, and the routers involved in that peering are referred to as BGP peers.

Finite State Machine (FSM)

Once the neighbor command is manually configured on a BGP router, the process of establishing the two devices as BGP peers begins. 

This process goes through the various neighbor adjacency states that we will talk about shortly to achieve a successful BGP peering. 

This process of going from state to state, and the rules that govern it, are called the BGP Finite State Machine or FSM.

An FSM is not exclusive to BGP.  In its broader definition, it defines a mathematical model of computation. 

It’s an abstract “machine” or computational entity that can be in exactly one of a finite number of states at any given time. 

An FSM can change from one state to another in response to some inputs or events.  An FSM is defined by a list of its states, its initial state, and the conditions for each transition from one state to the next.

FSMs are used by routing protocols including OSPF and EIGRP to create and manage neighbor relationships.  Of course, BGP also uses an FSM for this purpose.

BGP’s FSM

This explanation will become clearer when we look at a visual representation of BGP’s FSM, which depicts all of the states that the machine goes through to achieve a successful BGP peering:

Once the TCP session between BGP peers has been established, the BGP FSM begins in the Idle state.  It must then go through the various neighbor adjacency states to reach the Established state, which is the condition under which BGP routers have successfully become neighbors or peers. 

There are specific rules that govern the process for success, and these are discussed in the following sections.

BGP neighbor adjacency states of the FSM

Below we delve further into the different stages or “states” that two BGP routers pass through in their attempt to establish neighborship or a BGP peering. 

These stages include references to additional variables and components such as the ConnectRetry timer, KeepAlive timer, hold time timer, as well as open, update, keepalive, and notification BGP messages to name a few.  Let’s take a look at each state in detail:

Idle State

This is the initial state, where BGP anticipates a “start event.” This event triggers when a new BGP neighbor is configured or an established BGP peering is reset. 

Following this event, BGP initializes some resources, resets the ConnectRetry timer, and attempts to create a TCP connection with the remote BGP neighbor. 

Additionally, it begins listening for a connection if the remote BGP neighbor initiates one.  If successful, BGP transitions to the Connect state.  If not, it stays in the Idle state.

Connect State

In this state, BGP awaits the completion of the TCP three-way handshake.  If successful, it proceeds to the OpenSent state.  If it fails, the state changes to Active. 

Should the ConnectRetry timer expire, it remains in the Connect state, resetting the timer and attempting a new TCP three-way handshake.  If any other event occurs (like the resetting BGP), it reverts to the Idle state.

Active State

Here, BGP attempts another TCP three-way handshake with the remote BGP neighbor.  If successful, it transitions to the OpenSent state. 

If the ConnectRetry timer expires, it reverts to the Connect state.  During this state, BGP also remains alert for incoming connections from the remote BGP neighbor.  Certain events can cause it to return to the Idle state (such as resetting BGP).

OpenSent State

In this phase, BGP expects an open message from the remote BGP neighbor.  This message is examined for errors. 

If discrepancies like incorrect version numbers, wrong AS numbers, or other issues are found, BGP responds with a notification message and returns to the Idle state. 

Here, BGP also determines if it will use eBGP or iBGP based on the AS number check.  If all is in order, BGP commences sending keepalive messages and resets its KeepAlive timer. 

The hold time is negotiated (the lowest value is selected) between the two BGP routers.  If the TCP session fails, BGP reverts to the Active state. 

Other events, like the hold timer’s expiration, prompt BGP to send a notification message with the error code and return to the Idle state.  If the BGP process is reset, it also returns to the Idle state.

OpenConfirm State

In this state, BGP waits for a keepalive message from the remote BGP neighbor.  Once the keepalive message is received, it moves to the Established state, completing the neighbor adjacency. 

This event resets the hold timer.  If a notification message is received from the remote BGP neighbor, it falls back to the Idle state.  BGP continues to send keepalive messages.

Established State

At this point, the BGP neighbor adjacency is finalized and the BGP routers exchange routing information via update packets. 

Each time a keepalive or update message is received, the hold timer is reset.  If a notification message is received, it reverts to the Idle state.

Summary Table of BGP FSM States

Value of Understanding the BGP States

In cases where a BGP peering fails, or is intermittent, a series of troubleshooting tasks must be performed in order to determine the problem. 

Understanding the BGP FSM and its states is a fundamental part of being able to successfully troubleshoot, debug, and diagnose such problems. 

The above explanation is a relatively high-level description of the FSM states, and doesn’t include all possible events and contingencies, but it gives an excellent introduction to the process. 

For a complete and authoritative description of the BGP FSM in all its detail, take a look at the FSM section of RFC 4271.

Conclusion

Understanding the various stages of the BGP FSM is fundamental to comprehending the dynamics of neighbor relationships in networking. 

The stages summarize the comprehensive process of establishing a connection, maintaining it, and handling various events, such as error occurrences or session failures. 

These states enable BGP to manage its resources and communications effectively, ensuring the robustness and resilience of the network. 

Comprehending these states is imperative for any self-respecting network engineer, not only because it provides an insight into the inner workings of BGP but also because it equips professionals to troubleshoot and optimize network performance effectively.