Like any other protocol BGP enabled router also requires neighbors or peers to communicate. A router enabled with BGP forms a TCP session with neighbor routers called peers. BGP uses the Finite State Machine (FSM)* to maintain a table of all BGP peers and their operational status. The BGP session may report in the following states:
- Idle
- Connect
- Active
- OpenSent
- OpenConform
- Established
Figure 1. BGP Finite State Machine
Note: An FSM or Finite State Machine is a workflow model, similar to a flow chart, that is composed of the following:
- A finite number of stages (states)
- Transition between those states
- Operation
Details on FSM: URL
Figure 2: BGP Topology
Working details of BGP states:
Idle:
This is the first stage of the BGP FSM. BGP detects a start event, tries to initiate a TCP connection to the BGP peer. And also listen for a new connect from a peer router.
If an error causes BGP to go back to the idle state for a second time, the ConnectRetryTimer is set to 60 seconds and must determent to zero before the connection is initiated again. Further failures to leave the Idle state result in ConnectRetryTimer doubling in length from the previous time.
Connect:
In this state, BGP initiates the TCP connection. If the 3-way TCP handshake completes, the established BGP session BGP process resets the ConnectRetryTimer and sends the open message to the neighbor, and then changes to the OpenSent State.
If the ConnectRetry timer depletes before this stage is complete, a new TCP connection is attempted, the ConnectRetry timer is reset, and the state is moved to Active. If any other input is received, the state is changed to Idle.
During this stage, the neighbor with the highest IP address manages the connection. The router initiating the request uses a dynamic source port, but the destination port is always 179.
Example: Figure 3. Shows an established BGP session between router R1 and R2 using the command show tcp brief to display the active TCP session between the routers. Notice that the TCP source port is 179 and the destination port in 27166 on R1, and the ports are opposite on R2
Figure 3: Show TCP brief on R1
Figure 4: Show TCP brief on R2
Note: Service providers consistently assign their customers the higher or lower IP address for their networks. This helps the service providers create a golden template for proper instructions while creating access control list (ACL) or firewall rules, or for troubleshooting BGP issues.
Active:
In this state, BGP starts a new 3-way TCP handshake. If the connection is established, an open message is sent, the Hold Timer is sent to 4 minutes, and the state moved to OpenSent. If this attempt for TCP connection fails, the state moves back to the Connect state and resets the ConnectRetryTimer, Example with interface shutdown on R2 side which make the neighbor state to Active.
Figure 5: Show TCP brief on R1
OpenSent
In this state, an Open message has been sent from the originating router and is awaiting an Open message from other router. After the originating router receives the OPEN message from the other router, both OPEN messages are checked for errors. The following items are being compared:
- BGP Version must match
- The source IP address of the OPEN message must match to what is configured for the neighbor.
- The AS number in the OPEN message must match to what is configured for the neighbor.
- BGP identifiers (RID) mist be unique, if a RID dose not exist, this condition is not met.
- Security Parameters ( Password, TTL etc.)
If the Open message do not have any errors, the Hold Timer is negotiated ( using the lower value), and a KEEPALIVE message is sent (assuming the value is not set to zero). The connection state is then moved to OpenConfirm . If an error is found in the OPEN message, a Notification is sent, and the state is moved back to Idle.
If TCP receives a disconnect message, BGP close the connection, resets the ConnectRetryTimer, and sets the state to Active. Any other input in this process results in the state moving to Idle.
OpenConform
In this state, BGP waits for a Keepalive or Notification message. Upon receipt of a neighbor’s Keepalive the state is moved to Established. If the Hold Timer expires, a stop event occurs, or a Notification message is received, and the state is moved to Idle.
Established
In this state, the BGP session is established. BGP neighbor exchange routes via Update messages. As Update and Keepalive messages are received, the Hold Timer is reset. If the Hold Timer expires, and error is detected and BGP moves the neighbor back to Idle state.