Solution | For more technical information on the operation of the BGP FSM, see Section 8 of the BGP-4 RFC 4271. Â BGP establishes a TCP connection with peers or adjacent routers. A Finite State Machine (FSM) is used by BGP to keep track of each BGP neighbor and the operational condition. The following states are possible for the BGP session to report:
BGP states:
The FSM state is tracked per BGP peer. The current FSM state for each BGP peer can be retrieved with the 'get router info bgp summary' command.
get router info bgp summary
VRF 0 BGP router identifier 10.255.255.1, local AS number 65411
BGP table version is 3
1 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.108.2 4 65412 1903 1907 0 0 0 never Active
Total number of neighbors 1
Output shows:
The 'State/PfxRcd' column shows the FSM state name only while the session is not established. Once the peer reaches the Established state, the column shows a number instead: the count of prefixes received from that neighbor. A value of 0 in this column therefore means the session is up but no prefixes were received, which is a different problem from a session that is down. 'Up/Down' shows how long the session has been in its current condition. The value 'never' means the session has not reached the Established state since the BGP process last started. 'MsgSent' incrementing while 'MsgRcvd' stays flat indicates the local side is transmitting but nothing is coming back, which usually points to a filtering or routing problem towards the peer rather than a BGP configuration problem. In a multi-VRF deployment, the output is printed per VRF. Confirm the neighbor is being evaluated under the expected VRF before troubleshooting further.
Idle:
This is the initial state of the BGP FSM. No BGP connections are initiated, all existing connections are closed, and all incoming connections for this neighbor are refused.
When a start event occurs, BGP resources will be initiated, and the FSM will transition to the Connect state. Typically, this is done automatically by the FSM.
If required, the Idle state can be enforced for a particular neighbor by configuring 'set shutdown enable'. This would be done if a connection to this BGP neighbor is not wanted.
config router bgp
config neighbor
    edit <neighbor IP address>
      set shutdown {enable | disable}
    next
  end
end
If an error occurs in any other state, the BGP FSM will transition to Idle first before transitioning to Connect.
 Connect: In this state, FortiOS initiates a BGP connection to the neighbor.  The device uses a dynamic source port, but the destination port is always TCP 179. Similar to the Active state, BGP FSM is also listening for TCP connections from the remote peer while in the Connect state. If no reply is seen to the TCP SYN packet, FortiOS will resend it, doubling the time it waits for a response each time until 6 total transmissions have seen no reply. If the ConnectRetryTimer is long enough, the maximum time of the TCP connection attempt is (1 + 2 + 4 + 8 + 16 + 32) = 63 seconds. If no response is seen, or the TCP connection fails for another reason (for example, if the remote side replied with a FIN packet), the FSM moves to the Active state and restarts the ConnectRetryTimer. If the TCP three-way handshake is successful, an Open message is sent to the neighbor and the local BGP FSM moves to the Open Sent state. If the ConnectRetryTimer expires while the FSM is in the Connect state, FortiOS remains in this state, initiates another TCP connection, and restarts the timer. Ensure that the password is configured on both ends. If it is configured on only one side, the connection will remain stuck in the connect state. In this scenario, a SYN packet is sent, but no SYN-ACK is received in response.
Active:
In this state, BGP is listening for a TCP connection.
The active state is reached if there is a timeout or error in establishing the TCP three-way handshake. While in the Active state, the BGP process will not attempt to initiate a TCP connection with the neighbor. Once the ConnectRetryTimer expires, the BGP FSM will move back to the Connect state.
FortiOS can be forced to only listen for and never initiate a BGP connection by configuring 'set passive enable' on the BGP neighbor.
config router bgp
config neighbor
    edit <neighbor IP address>
      set passive {enable | disable}
    next
  end
end
If 'set passive enable' is configured on both ends of a peering, neither side will ever initiate the TCP connection and the session will remain in the Active state permanently. The Active state is frequently misread as a positive indication because of its name. It is not: a peer reported as Active has no TCP connection to the neighbor.
OpenSent:
In this state, BGP is waiting for an OPEN message from the remote neighbor.
If a keepalive message is received before any OPEN message is received from the remote side, a Notification message is sent to the neighbor, and the local FSM moves to the Idle state.
When an Open message is received, BGP will check the parameters for errors. If there are no errors, BGP will start sending keepalive messages and move to the OpenConfirm state. In this state, the Hold timer is negotiated, and whether EBGP or IBGP will be used.
If there is an error in the received Open message, a Notification message is sent to the neighbor, and the local FSM moves to the Idle state.
Parameters validated at this point include the BGP version, the peer AS number, the BGP identifier (router ID), the proposed hold time, and any optional capabilities. A mismatch results in an OPEN Message Error NOTIFICATION (code 2) with a subcode identifying the specific parameter. See the notification code reference below.
Two frequent causes of an immediate transition from OpenSent back to Idle:
The AS number in the received OPEN does not match the 'set remote-as' value configured locally, producing subcode 2 (Bad Peer AS). This is the most common OPEN error. Both peers advertise the same BGP router ID, producing subcode 3 (Bad BGP Identifier). Set an explicit router ID with 'set router-id' under 'config router bgp'.
OpenConfirm:
In this state, BGP has received a valid OPEN message from the neighbor and is waiting for a Keepalive message acknowledging its own Open message.
When a keep-alive message is received, it moves to the Established state, but if a Notification message is received, it moves to the Idle state.
This state is normally passed through in well under a second. A peer that is observed sitting in OpenConfirm for an extended period, or cycling repeatedly through it, is typically hitting an MTU or path stability problem rather than a BGP parameter problem.
Established:
In this state, the connection is fully established, and update messages with routing information are exchanged.
When a Keepalive or an Update message is received, the Hold timer will reset. If a Notification message is received, the connection will close, and BGP will move to the Idle state.
Once Established, the 'State/PfxRcd' column of 'get router info bgp summary' displays the number of prefixes received rather than the state name.
A session that reaches Established and then drops after roughly the negotiated hold time (180 seconds by default) points to keepalives not being delivered in one direction. Common causes are an intermediate device dropping or rate-limiting BGP traffic, an MTU mismatch that blocks large UPDATE messages while allowing small keepalives through, or CPU exhaustion on either peer.
Notes:
The default TTL of IP packets sent by External BGP is 1. For EBGP neighbors that are not directly connected, ensure Technical Tip: Configuring eBGP MultiHop is enabled to allow BGP packets to traverse the entire path to reach the destination. External BGP is used when the local and peer router have a different AS. ConnectRetryTimer is randomly set for each connection attempt. The estimated range of possible timer values is between half and the full value of connect-timer. For example, with the default connect-timer of 120s, the actual ConnectRetryTimer for a particular BGP connection attempt may be between 60 and 120 seconds. Note that the minimum configurable connect-timer of 1 second may not be sufficient to reliably bring up a BGP connection in high-latency environments. The maximum possible time between TCP SYN packets when FortiOS is attempting to bring up a BGP connection is connect-timer + 32 seconds (152 seconds by default). If the connect-timer is lower than 63 seconds, the maximum possible time between TCP SYN packets is connect-timer.
|
