It’s important to know about BGP States if you want to know how BGP works. BGP sets up a BGP Peering with other routers before they share any routing information, just like the IGPs EIGRP, OSPF, or ISIS. For neighbor discovery, BGP doesn’t use broadcast or multicast, though. That’s how BGP was made. Instead, the neighbors are set up manually and peers talk to each other through TCP Port 179 to create a BGP Session. The BGP Finite State Machine moves a router through the different states shown below when the neighbor command is added to the BGP process.
BGP Neighbor States
Let’s get a comprehensive understanding of all the BGP Neighbor States by utilizing a straightforward topology consisting of two routers.
Idle State
When BGP Idle State is reached, the router looks in the routing table for a good route for the IP address of the neighbor. If it does not have a route for the IP address of its neighbor, it stays in the Idle State. In this state, no or very few BGP resources are assigned. Another reason why BGP State stays in Idle State is when the physical link that connects to the neighbor is administratively down or when the BGP neighborship is admin-shut in the BGP process.
R1 is in the “Idle” state because it doesn’t have a way to reach R2’s neighbor address (Lo0).
R1#show ip route 100.100.0.2 % Subnet not in table R1#show ip bgp summary | include 100.100.0.2 100.100.0.2 4 100 0 0 1 0 0 never Idle
In the event that the BGP is administratively turned down by the administrator of the network due to maintenance related activities, the BGP state will once again remain in the idle state, as demonstrated below.
R1(config)# R1(config-router)#neighbor 100.100.0.2 shutdown R1#show ip bgp summary BGP router identifier 100.100.0.1, 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 100.100.0.2 4 100 0 0 1 0 0 00:09:19 Idle (Admin)
Connect State
The BGP peer goes into Connect State, starts a Connect Retry Timer (with a default value of 60 seconds), initiates the TCP 3-Way Handshake, and attempts to finish the TCP connection on TCP port 179 if the router discovers a route to the neighbor IP address.
R1#show ip route 100.100.0.2 Routing entry for 100.100.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 100.100.0.2, 00:00:55 ago, via FastEthernet1/0 Route metric is 2, traffic share count is 1
In addition, the following command can be used to view the current state of the TCP connection.
R1#show tcp brief TCB Local Address Foreign Address (state) 666AC56C 100.100.0.1.11870 100.100.0.2.179 ESTAB
When the Connect Retry Timer goes out and the TCP 3-Way Handshake goes through successfully, the BGP peer goes to the Open Sent state and sends a BGP OPEN message to its neighbor or other peer. If this does not happen, the peer will enter BGP Active State and start the connection process all over again, this time waiting for the TCP 3-Way Handshake to finish. Additionally, it can go straight to Idle State for the reasons mentioned in the Idle State section.
Active State
In order to establish a BGP peer adjacency, a TCP connection is opened once more when the system is in the Active state. The BGP protocol will shift to the Open Sent state and send an OPEN message to the peer if it is successful. Should the attempt fail, the system may enter either the Active or Idle state.
The router R1 is currently locked in the Active state with its peer 100.100.0.2, as shown in the output below. There could be a number of causes for this, including faulty routing or the fact that TCP Port 179 is restricted or filtered throughout the network.
R1#show ip bgp summary BGP router identifier100.100.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 100.100.0.2 4 100 0 0 1 0 0 00:00:02 Active
OpenSent State
While the OpenSent State was in effect, the BGP Peer communicated with its neighbor by sending an Open message that contained the parameters for the BGP session. After that, the BGP peers wait for the neighbor’s Open message in response to the message they received. Errors are checked for in the Open message, such as if there is something wrong with the BGP version numbers or if there is an invalid AS number. The Border Gateway Protocol (BGP) will respond with a notification message and then return to the idle state in the event that an issue is discovered. While in the same state, the BGP process makes a decision regarding whether to form an iBGP or an eBGP neighborship based on whether the AS-number of the peer is the same or different. The BGP protocol will begin issuing Keepalive Messages and will reset its keepalive timer if everything is in perfect working order. Additionally, the hold-down duration is being negotiated between the two BGP peers at the same present moment. In the event that BGP peers are configured with differing hold-down timers, the value of the lower hold-down timer is negotiated. Once more, in the event that the TCP session is unsuccessful, BGP will restart from the Active state. In the event that any other failures occur, such as the expiration of the hold-down timeout, the BGP peer will send a notification message to its neighbor including the error code and will then return to the idle state.
