Enhance your Career in Networking With IPinBits!!!​

BGP states in details

BGP converges through different states before exchanging prefixes (NLRIs). It starts from IDLE state and converges to ESTABLISHED state. Now there are multiple states in between them. Below is a look at BGP state machine.

DONT WORRY ABOUT THE COMPLEXITY OF THE ABOVE DIAGRAM!!! We are here to explain it. So let’s get on with the BGP states.
1. IDLE – This is the first state in BGP. It is usually when BGP is enabled and BGP is ready to make TCP connection. Some keynotes in IDLE state are 

The IDLE state is the initial state of the BGP Finite State Machine on startup. A BGP speaking router in the IDLE state is awaiting a session it sits in the IDLE state awaiting the ManualStart event or the AutomaticStart event. When either start event is received BGP performs the following:
Iinitializes all resources for the peer connection
Sets ConnectRetryCounter to zero
Starts the ConnectRetryTimer with the initial value
Initiates a TCP connection to the other BGP peer
Listens for a connection that may be initiated by the remote BGP peer
Changes its state to CONNECT.

The BGP router will not start a BGP session until either start event occurs. Cisco classifies initial configuration or clearing of a BGP peering session as a start event and the system transitions to the CONNECT state. Whenever a BGP peering session is shut down because of an error, it returns to the IDLE state. NOTIFICATION messages used to signal connection errors return the router to the IDLE state.

*Jan  3 14:33:11.083: BGP: 12.12.12.2 passive open to 12.12.12.1
*Jan  3 14:33:11.084: BGP: Fetched peer 12.12.12.2 from tcb
*Jan  3 14:33:11.084: BGP: 12.12.12.2 passive went from Idle to Connect

2. CONNECT – From IDLE state BGP goes into CONNECT state where the routers will try to form the TCP connection at port 179. If TCP connection is successful router will go in OPEN SENT state, if TCP connection fails it will go into ACTIVE state. 
Once the BGP software and it’s environment have been initialized, BGP initiates a TCP connection to the remote neighbor IP address. The CONNECT state indicates the router has awaiting the completion of a TCP connection between itself and another BGP speaking peer. The BGP Finite State Machine remains in CONNECT until the TCP three-way handshake completes.
It is assumed that both sides of the connection will attempt to initiate a BGP session with the peer. The peer with the higher router ID (highest IP address) becomes the router that manages the BGP session and the connection attempted by the other router is abandoned.

     2.a Active state – ROuter will wait for Connect_Retry_Timer (120 seconds) before attempting TCP connection again. If it fails again then it will wait 2*Connect_Retry_Timer. If TCP connection is still not formed it will go in IDLE state.

The router has started the first phase of establishing a BGP session by initializing a new TCP three-way handshake to the remote router (peer) because the initial connect failed. Typically, you only see this state if you failed the initial connect. From the ACTIVE state, BGP will attempt to send another OPEN message to negotiate a BGP session. If the second attempt fails, the state falls back to CONNECT.
If you check the state of BGP, and it shows ACTIVE, you do NOT have a functional BGP session. The Finite State Machine passes through ACTIVE only when the CONNECT phase fails.

*Jan  3 14:33:11.084: BGP: 12.12.12.2 passive went from Idle to Connect
*Jan  3 14:33:11.085: BGP: ses global 12.12.12.2 (0x10F04AD0:0) pas Setting open delay timer to 60 seconds.
*Jan  3 14:33:11.093: BGP: 12.12.12.2 passive rcv message type 1, length (excl. header) 38
*Jan  3 14:33:11.093: BGP: ses global 12.12.12.2 (0x10F04AD0:0) pas Receive OPEN
*Jan  3 14:33:11.095: BGP: 12.12.12.2 passive rcv OPEN, version 4, holdtime 180 seconds
*Jan  3 14:33:11.095: BGP: 12.12.12.2 passive rcv OPEN w/ OPTION parameter len: 28
*Jan  3 14:33:11.096: BGP: 12.12.12.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Jan  3 14:33:11.099: BGP: 12.12.12.2 passive OPEN has CAPABILITY code: 1, length 4
*Jan  3 14:33:11.099: BGP: 12.12.12.2 passive OPEN has MP_EXT CAP for afi/safi: 1/1
*Jan  3 14:33:11.100: BGP: 12.12.12.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jan  3 14:33:11.100: BGP: 12.12.12.2 passive OPEN has CAPABILITY code: 128, length 0
*Jan  3 14:33:11.101: BGP: 12.12.12.2 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
*Jan  3 14:33:11.102: BGP: 12.12.12.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jan  3 14:33:11.102: BGP: 12.12.12.2 passive OPEN has CAPABILITY code: 2, length 0
*Jan  3 14:33:11.103: BGP: 12.12.12.2 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
*Jan  3 14:33:11.104: BGP: 12.12.12.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jan  3 14:33:11.104: BGP: 12.12.12.2 passive OPEN has CAPABILITY code: 70, length 0
*Jan  3 14:33:11.105: BGP: ses global 12.12.12.2 (0x10F04AD0:0) pas Enhanced Refresh cap received in open message
*Jan  3 14:33:11.107: BGP: 12.12.12.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Jan  3 14:33:11.107: BGP: 12.12.12.2 passive OPEN
Router#has CAPABILITY code: 65, length 4
*Jan  3 14:33:11.108: BGP: 12.12.12.2 passive OPEN has 4-byte ASN CAP for: 200
*Jan  3 14:33:11.109: BGP: 12.12.12.2 passive rcvd OPEN w/ remote AS 200, 4-byte remote AS 200
*Jan  3 14:33:11.110: BGP: ses global 12.12.12.2 (0x10F04AD0:0) pas Adding topology IPv4 Unicast:base
*Jan  3 14:33:11.111: BGP: ses global 12.12.12.2 (0x10F04AD0:0) pas Send OPEN
*Jan  3 14:33:11.112: BGP: ses global 12.12.12.2 (0x10F04AD0:0) pas Building Enhanced Refresh capability
*Jan  3 14:33:11.115: BGP: 12.12.12.2 passive went from Connect to OpenSent

 3. Open Sent – This state is when routers formed TCP connection and have sent/received the OPEN  message. In this state things like OPEN Compare – for deciding if BGP is EBGP or IBGP and Hold on timer negotiation happens. 

*Jan  3 14:33:11.116: BGP: 12.12.12.2 passive sending OPEN, version 4, my as: 100, holdtime 180 seconds, ID 1010101
*Jan  3 14:33:11.116: BGP: 12.12.12.2 passive went from OpenSent to OpenConfirm

4. OPEN Confirm – In this state BGP is waiting for either KEEPALIVE or Notification message.
5. If the BGP peer reply with KEEPALIVE message, next stage is ESTABLISHED but if the reply is NOTIFICATION MESSAGE, the next state is IDLE.

*Jan  3 14:33:11.364: BGP: 12.12.12.2 passive went from OpenConfirm to Established

Related blog posts