Useful Articles


BGP States

BGP States

Understanding of BGP States is important in order to understand How BGP Works. Just like the IGPs EIGRP, OSPF or ISIS, BGP also establishes a BGP Peering with other routers before exchanging any routing information. However, BGP does not use broadcast or multicast for the neighbor discovery. BGP is designed like that. Instead, the neighbors are configured manually and communication happens between the peers through TCP Port 179 to form a BGP Session. This article will help us Demystifying BGP States. When we put neighbor command under the BGP process, BGP Finite State Machine takes a router through the various states as shown in the picture below.

  BGP States


BGP Neighbor States

Let's understand all the BGP Neighbor States in detail with the help of a simple 2 routers topology. As the routers R1 and R2 form a BGP Session, we will capture the exchange of BGP messages using the Wireshark tool to understand BGP States thoroughly. 


BGP States

Idle State

In BGP Idle State, the router searches the routing table for a valid route for the neighbor's IP address. If it does not have a route for its neighbor's IP address, it remains in the Idle State. No or negligible BGP resources are allocated in this state. Another reason for BGP State to remain in Idle State is when you have admin-shut the physical interface that connects to the neighbor or you have admin-shut the BGP neighborship going in the BGP process.

Below is the output for R1 in Idle state because R1 doesn't have a route to R2's neighbor address (Lo0).

R1#show ip route
% Subnet not in table

R1#show ip bgp summary | include       4          100       0       0        1    0    0  never    Idle

When the BGP is admin-shut by the network administrator because of maintenance activity, the BGP state will again remain in Idle state as shown below.
R1(config-router)#neighbor shutdown

R1#show ip bgp summary
BGP router identifier, local AS number 100
BGP table version is 6, main routing table version 6
1 network entries using 128 bytes of memory
1 path entries using 52 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 304 total bytes of memory
BGP activity 8/7 prefixes, 9/8 paths, scan interval 60 secs

Neighbor         V           AS   MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4          100        0             0            1           0    0       00:06:29   Idle (Admin)

Connect State

If the router finds a route to the neighbor IP address, BGP peer moves to Connect State, initiates a Connect Retry Timer (default value 60 seconds), and begins the TCP 3-Way Handshake process and tries to complete the TCP connection on TCP port 179.

R1#show ip route
 Routing entry for
 Known via "ospf 1", distance 110, metric 2, type intra area
 Last update from on FastEthernet1/0, 00:00:55 ago
 Routing Descriptor Blocks:
 *, from, 00:00:55 ago, via FastEthernet1/0
 Route metric is 2, traffic share count is 1

The status of TCP connection can also be seen using the below command.

R1#show tcp brief
TCB                   Local Address                 Foreign Address             (state)
666AC56C                     ESTAB

If the TCP 3-Way Handshake process is successful before the Connect Retry Timer expires, the BGP peer sends BGP OPEN message to its neighbor/peer and moves to Open Sent state. Else, the peer will move to BGP Active State and again begins the process of connectivity with the neighbor (waiting to complete the TCP 3-Way Handshake process). It can also directly jump to Idle State because of the possible reasons explained in the Idle State section.


Active State

In the Active state, a TCP connection is again initiated to establish a BGP peer adjacency. If successful, BGP sends OPEN message to the peer and moves to Open Sent state. Failure can result in going to the Active or Idle states.

In below output, router R1 is in stuck in Active state with its peer Possible reasons could be incorrect routing or TCP Port 179 blocked or filtered somewhere in the network.
R1#show ip bgp summary

BGP router identifier10.10.0.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor        V           AS   MsgRcvd MsgSent   TblVer  InQ OutQ   Up/Down  State/PfxRcd       4           100        0            0               1           0     0       00:00:02    Active

OpenSent State

In the OpenSent State BGP Open message was sent by the BGP Peer to its neighbor with the parameters for the BGP session. Afterwards, the BGP peers also wait for the neighbor's Open message in reply. The Open message is checked for errors for example if there is something incorrect related to BGP version numbers, a wrong AS number. In case some issue is identified, BGP will respond with a Notification message and jumps back to the Idle state. At the same state, the BGP process decides on forming iBGP or eBGP neighborship based on the same or a different AS-number of the peer. If everything is OK then BGP starts sending Keepalive Messages and resets its keepalive timer. At the same time, the hold-down time is negotiated between the two BGP peers. If BGP peers are configured with different hold-down timers, the lower hold-down timer value is negotiated. Again, if the TCP session fails, BGP will jump back to the Active state. In case of any other errors, for instance, hold-down timer expiry, the BGP peer will send a notification message to its neighbor with the error code and jumps back to the Idle state.

If both the BGP peers agree on the parameters (sent in Open message) and the BGP peer receives the Open message from its neighbor, it moves to Open Confirm state and sends the BGP Keepalive message to its peer.

OpenConfirm State

In the OpenConfirm State, BGP waits of a Keepalive message from the peer. Once the Keepalive message is received, the BGP peer moves to Established state and starts exchanging the prefixes using the Update Messages. Otherwise, the state moves back to Idle based on the errors. A Wireshark snapshot for BGP Peers R1 and R2 exchanging  BGP Open Message and corresponding Keepalive message is shown below.


Established State

In the Established State, a BGP peering session is established (successful) between the routers and advertisement of Update Messages, exchange of Keepalive messages (every 60 seconds by default) or Notification messages begin in this stage. Based on Update Messages (NLRI and Attributes) received from each BGP peer, a BGP Table is formed and the best routes from this table are sent to the Routing Table. The below output from R1 shows that the BGP session is up between R1 and R2 from more than 5 minutes and 15 seconds and R1 has learned one route or prefix from the neighbor R2.

R1#show ip bgp summary
BGP router identifier, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 256 bytes of memory
2 path entries using 104 bytes of memory
2/2 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 608 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor         V     AS   MsgRcvd    MsgSent   TblVer   InQ  OutQ   Up/Down    State/PfxRcd        4     100    349             348            3            0     0        05:15:23           1

It is interesting to note that you do not find "Established" keyword in above command output. There is another command to check BGP state between the peers as shown below. This command will give you complete details about the BGP neighbor's state.

R1# show ip bgp neighbors
BGP neighbor is,  remote AS 100, internal link
  BGP version 4, remote router ID
  BGP state = Established, up for
05:15:45  Last read 05:15:45, last write 05:15:45, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: advertised and received
  Message statistics, state Established:
    InQ depth is 0
    OutQ depth is 0

                               Sent       Rcvd
    Opens:                   1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:            1          1
    Route Refresh:       0          0
    Total:                      2          2
------------------- Output Ommitted ----------------------


To summarize, as soon you enter the neighbor command, BGP starts in the IDLE state, and the BGP process checks that it has a route to the IP address listed. BGP should be in the IDLE state for only a few seconds. If BGP does not find a route to the neighboring IP address, it stays in the IDLE state. If it finds a route, it goes to the CONNECT state when the TCP handshaking synchronize acknowledge (SYN-ACK) packet returns (when the TCP 3-way handshake process is complete).

I hope you have found this article informative and useful and now have a fair understanding of BGP States and what BGP messages are exchanged during these BGP States. For any of the related queries or feedback, kindly write to us at


Post a Comment