BGP Neighbor States

BGP requires a neighbor relationship to be established before any information is exchanged between BGP speakers.

Like most other dynamic protocols, BGP uses periodic keepalive messages to ensure availability of BGP neighbors.

The keepalive timer is one third of the holdtime. If three consecutive keepalive messages are missed from a particular BGP neighbor, the holdtime expires and that neighbor is considered dead. The suggested value for the holdtime is 90 seconds, and for the keepalive timer is 30 seconds. These values are negotiated between BGP neighbors when the neighbors first come up.

When BGP is configured with a neighbor IP address, it goes through a series of stages before it reaches the desired Established state in which BGP has negotiated all the required parameters and is willing to exchange BGP routes.

BGP goes through the following stages of neighbor relationship:

  • Idle
  • Connect
  • Active
  • OpenSent
  • OpenConfirm
  • Established
State Description
Idle BGP waits for a start event.
Connect BGP waits for a TCP connection (3-way handshake) to be completed.
If successful, the state machine moves into OpenSent state after sending the OPEN message to the peer.
Failure in this state could result in either going into Active or Connect state, or reverting back to Idle.
Active BGP tries again a TCP connection to establish a BGP peer session.
If successful, BGP sends its OPEN message to the peer and moves to OpenSent state.
Failure can result in going to the Active or Idle states.
OpenSent After sending an OPEN message to the peer, BGP waits in this state for a OPEN reply.
After receiving the OPEN message from the remote peer, both OPEN messages are checked for errors.
If no errors found in OPEN messages, BGP moves to OpenConfirm and KEEPALIVE is sent to the peer.
Failure can result in sending the BGP state back to Idle or Active.
OpenConfirm BGP waits in this state for KEEPALIVE from the peer.
Upon receipt of the peer’s KEEPALIVE, the state is moved to Established.
Established BGP can exchange routing information between the peers via UPDATE messages.
bgp state machine

Idle

BGP waiting for a start event.

  • This is the first state where BGP waits for a “start event”.
  • The start event occurs when someone configures a new BGP neighbor or when we reset an established BGP peering.
  • BGP detects a start event, tries to initiate a TCP connection to the BGP peer, and also listens for a new connection from a peer router.
  • If an error causes BGP to go back to the Idle state for a second time, the ConnectRetryTimer is set to 60 seconds and must decrement to zero before the connection is initiated again.
  • When successful, BGP moves to the Connect state.

Connect

Waiting for the TCP 3-way handshake to be completed.

  • BGP initiates the TCP connection.
    • During this stage, the neighbor with the higher IP address manages the connection.
    • The router initiating the request uses a dynamic source port, but the destination port is always 179.
  • If the 3-way TCP handshake completes, the established-BGP-Session-BGP-process resets the ConnectRetryTimer and sends the OPEN message to the neighbor, and then changes to the OpenSent State.

If the ConnectRetry timer depletes before this stage is complete, a new TCP connection is attempted, the ConnectRetry timer is reset, and the state is moved to Active. If any other input is received, the state is changed to Idle.

Active

BGP will try another TCP 3-way handshake to be established with the remote peer.

  • BGP will try another TCP 3-way handshake to establish a connection with the remote BGP peer.
  • If it is successful, it moves to the OpenSent state.
  • If the ConnectRetry timer expires, then move back to the Connect state.

In this state, BGP starts a new 3-way TCP handshake. If a connection is established, an OPEN message is sent, the Hold Timer is set to 4 minutes, and the state moves to OpenSent. If this attempt for TCP connection fails, the state moves back to the Connect state and resets the ConnectRetryTimer.

OpenSent

OPEN message sent and waiting an OPEN Reply message from the peer.
OPEN messages are checked for errors.

  • An OPEN message has been sent from the originating router and is awaiting an OPEN message from the other router.
  • After the originating router receives the OPEN message from the other router, both OPEN messages are checked for errors.
  • If the OPEN messages do not have any errors, the Hold Time is negotiated (using the lower value), and a KEEPALIVE message is sent (assuming the value is not set to zero). The connection state is then moved to OpenConfirm.
  • If an error is found in the OPEN message, a NOTIFICATION message is sent, and the state is moved back to Idle.

The following items are being compared:

  1. BGP version must match
  2. The source IP address of the OPEN message must match the IP address that is configured for the neighbor.
  3. The AS number in the OPEN message must match what is configured for the neighbor.
  4. BGP Identifiers (RID) must be unique. If a RID does not exist, this condition is not met.
  5. Security Parameters (Password, TTL, and the like).

OpenConfirm

BGP waiting for a Keepalive or Notification message.

  • In this state, BGP waits for a KEEPALIVE or NOTIFICATION message.
  • Upon receipt of a neighbor’s KEEPALIVE, the state is moved to Established.
  • If the hold timer expires, a stop event occurs, or a NOTIFICATION message is received, and the state is moved to Idle.

Established

BGP session is established and neighbors can start exchanging routes via Update messages.

  • In this state, the BGP session is established.
  • BGP neighbors exchange routes via UPDATE messages.
  • As UPDATE and KEEPALIVE messages are received, the Hold Timer is reset.
  • If the Hold Timer expires, an error is detected and BGP moves the neighbor back to the Idle state.

Leave a Reply

Related Post

BGP PacketsBGP Packets

BGP uses a variety of messages for establishing the connection, exchanging routing information, checking if the remote BGP neighbor is still there and/or notifying the remote side if any errors

BGP FundamentalsBGP Fundamentals

BGP A router’s primary function is to move packets from one network to a different network. A router learns about unattached networks through static configuration or through dynamic routing protocols