Troubleshooting BGP Neighbor States

A BGP router goes through a finite state machine that has the Idle, Connect, Active, Open Sent, Open Conform, and Established states with its neighbors. The debug ip bgp privileged command shows the various BGP states throughout the neighbor establishment process.

RT1#debug ip bgp
BGP debugging is on
RT1#
00:00:55: BGP: 12.12.12.2 went from Idle to Active
00:00:55: BGP: 12.12.12.2 open active, delay 26011ms
00:01:11: BGP: 12.12.12.2 passive open
00:01:11: BGP: 12.12.12.2 went from Active to Idle
00:01:11: BGP: 12.12.12.2 went from Idle to Connect
00:01:11: BGP: 12.12.12.2 rcv message type 1, length (excl. header) 26
00:01:11: BGP: 12.12.12.2 rcv OPEN, version 4
00:01:11: BGP: 12.12.12.2 went from Connect to OpenSent
00:01:11: BGP: 12.12.12.2 sending OPEN, version 4, my as: 65001
00:01:11: BGP: 12.12.12.2 went from OpenSent to OpenConfirm
00:01:11: BGP: 12.12.12.2 send message type 1, length (incl. header) 45
00:01:11: BGP: 12.12.12.2 went from OpenConfirm to Established
00:01:11: %BGP-5-ADJCHANGE: neighbor 12.12.12.2 Up
RT1#

After a neighbor BGP router subcommand is configured, the BGP session starts in the Idle state, and the BGP process checks whether there is a route to the newly configured neighbor. The BGP session should remains in the Idle state for only a few seconds. If the BGP process is unable to locate a route to the neighbor, the BGP session remains in the Idle state. If it finds a route, it initiates a TCP connection to the neighbor and the BGP session enters into the Connect state when the TCP SYN ACK segment returns, and the TCP three-way handshake is completed.

After the TCP connection is established, the BGP process sends a BGP Open message to the neighbor and the BGP session enters into the Open Sent state. If there is no response for 5 seconds, the state changes back to the Active state. If a response returns within 5 seconds, the BGP session enters into the Open Confirm state and the BGP process starts scanning (evaluating) the routing table for the paths to send to the neighbor. Eventually the BGP session enters into the Established state and the BGP process begins to exchange routing information with the neighbor.

When a BGP router remains in the Idle state, it means that it unable to reach the IP address configured in the neighbor statement. Verify the following to troubleshoot the BGP Idle state:

• Ensure that the static route to the neighbor IP address is configured correctly.
• Ensure that the IGP has announced the neighbor IP address correctly.
• Ensure that the neighbor IP address is configured correctly.

When a BGP router remains in the Active state, it means that it can reach the IP address configured in the neighbor statement and has sent a BGP Open message to the neighbor but has not received a response (the Open message from the neighbor) back from the neighbor. Verify the following to troubleshoot the BGP Active state:

• Ensure that the neighbor has a return static or IGP route to the source IP address.
• Ensure that the source IP address is advertised into the IGP on the neighbor.
• Ensure that the neighbor has a neighbor statement peering back to the local router.
• Ensure that the neighbor statement on the neighbor is configured correctly.

If the state toggles between Idle and Active, verify that the AS numbers are configured correctly. Below shows the error messages on 2 neighboring routers in which the wrong ASN is configured in the neighbor statements – RT1 in AS 65001 is configured to peer with RT2 in AS 65002; while RT2 in AS 65002 is configured to peer to RT1 in AS 65002.

RT1#
00:01:05: %BGP-3-NOTIFICATION: received from neighbor 12.12.12.2 2/2 (peer in wrong AS) 2 bytes FDE9
RT1#
======================================================================
RT2#
00:01:05: %BGP-3-NOTIFICATION: sent to neighbor 12.12.12.1 2/2 (peer in wrong AS) 2 bytes FDE9 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 FDE9 00B4 C0A8 0101 1002 0601 0400 0100 0102 0280 0002 0202 00
RT2#