BGP States Troubleshooting – BGP Basics

In order to make decisions in its operations with peers, a BGP peer uses a simple finite state machine (FSM) that consists of six states: Idle; Connect; Active; OpenSent; OpenConfirm; and Established.

For each peer-to-peer session, a BGP implementation maintains a state variable that tracks which of these six states the session is in. The BGP defines the messages that each peer should exchange in order to change the session from one state to another.

Idle State

• Refuse all incoming BGP connections.
  • Start the initialization of event triggers.
  • Initiates a TCP connection with its configured BGP peer.
  • Listens for a TCP connection from its peer.
  • Changes its state to Connect.
  • If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:
    • TCP port 179 is not open.
    • A random TCP port over 1023 is not open.
    • Peer address configured incorrectly on either router.
    • AS number configured incorrectly on either router.

Connect State

• Waits for successful TCP negotiation with peer.
  • BGP does not spend much time in this state if the TCP session has been successfully established.
  • Sends Open message to peer and changes state to OpenSent.
  • If an error occurs, BGP moves to the Active state. Some reasons for the error are:
    • TCP port 179 is not open (server side).
    • A random TCP port over 1023 is not open (client side).
    • Peer address configured incorrectly on either router.
    • AS number configured incorrectly on either router.

Active 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.
  
• If the router was unable to establish a successful TCP session, then it ends up in the Active state.
  • BGP FSM tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer.
  • If it is unsuccessful again, the FSM is reset to the Idle state.
  • Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include:
    • TCP port 179 is not open.
    • A random TCP port over 1023 is not open.
    • BGP configuration error.
    • Network congestion.
    • Flapping network interface.

OpenSent State

• BGP FSM listens for an Open message from its peer.
• Once the message has been received, the router checks the validity of the Open message.
  • The OPEN message is used to establish a BGP adjacency. Both sides negotiate session capabilities before a BGP peering establishes. The OPEN message contains the BGP version number, ASN of the originating router, Hold Time, BGP Identifier, and other optional parameters that establish the session capabilities.

The following items are being compared:

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

If there is an error it is because one of the fields in the Open message does not match between the peers, e.g., BGP version mismatch, the peering router expects a different My AS …, The router then sends a Notification message to the peer indicating why the error occurred.

If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.

OpenConfirm State

• The peer is listening for a Keepalive message from its peer.
  • If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state.
  • If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

Established State

• In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer.
• If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state.

Ref: wiki