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
Below is the output for R1 in Idle state because R1 doesn't have a route to R2's neighbor address (Lo0).
% Subnet not in table
R1#show ip bgp summary | include 10.10.0.2
10.10.0.2 4 100 0 0 1 0 0 never Idle
R1(config-router)#neighbor 10.10.0.2 shutdown
R1#show ip bgp summary
BGP router identifier 10.10.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
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.
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.
TCB 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.
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
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.
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.
BGP router identifier 10.10.0.1, 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
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.
BGP 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).
0 Comments
Please do not enter any spam link in the comment box.