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 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. 

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 10.10.0.2% Subnet not in tableR1#show ip bgp summary | include   10.10.0.2

10.10.0.2       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)#R1(config-router)#neighbor 10.10.0.2 shutdownR1#show ip bgp summaryBGP router identifier 10.10.0.1, local AS number 100BGP table version is 6, main routing table version 61 network entries using 128 bytes of memory1 path entries using 52 bytes of memory1/1 BGP path/bestpath attribute entries using 124 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP using 304 total bytes of memoryBGP activity 8/7 prefixes, 9/8 paths, scan interval 60 secsNeighbor         V           AS   MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.10.0.2         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 10.10.0.2 Routing entry for 10.10.0.2/32 Known via “ospf 1”, distance 110, metric 2, type intra area Last update from 10.10.12.2 on FastEthernet1/0, 00:00:55 ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.0.2, 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 briefTCB                   Local Address                 Foreign Address             (state)

666AC56C        10.10.0.1.11870               10.10.0.2.179                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 10.10.0.2. Possible reasons could be incorrect routing or TCP Port 179 blocked or filtered somewhere in the network.

R1#show ip bgp summaryBGP router identifier10.10.0.1, local AS number 100BGP table version is 1, main routing table version 1Neighbor        V           AS   MsgRcvd MsgSent   TblVer  InQ OutQ   Up/Down  State/PfxRcd

10.10.0.2       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.

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 summaryBGP router identifier 10.10.0.1, local AS number 100BGP table version is 3, main routing table version 32 network entries using 256 bytes of memory2 path entries using 104 bytes of memory2/2 BGP path/bestpath attribute entries using 248 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP using 608 total bytes of memoryBGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secsNeighbor         V     AS   MsgRcvd    MsgSent   TblVer   InQ  OutQ   Up/Down    State/PfxRcd

10.10.0.2        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 10.10.0.2BGP neighbor is 10.10.0.2,  remote AS 100, internal link  BGP version 4, remote router ID 10.10.0.2

  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).

Click Here for other useful BGP articles

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 [email protected]