Log BGP State Transition Events
Purpose
Border Gateway Protocol (BGP) state transitions indicate a network problem and need to be logged and investigated.
Action
To log BGP state transition events to the system log, follow these steps:
- In configuration mode, go to the following hierarchy level:[edit] user@host# edit protocol bgp
- Configure the system log:user@host# set log-updown
- Verify the configuration:user@host# show
- Commit the configuration:user@host# commit
Meaning
Log messages from BGP state transition events are sufficient to diagnose most BGP session problems. Table 1 lists and describes the six states of a BGP session.
Table 1: Six States of a BGP Session
BGP State | Description |
|---|---|
Idle | This is the first state of a connection. BGP waits for a start event initiated by an administrator. The start event might be the establishment of a BGP session through router configuration or the resetting of an existing session. After the start event, BGP initializes its resources, resets a connect-retry timer, initiates a TCP transport connection, and starts listening for connections initiated by remote peers. BGP then transitions to a Connect state. If there are errors, BGP falls back to the Idle state. |
Connect | BGP waits for the transport protocol connection to complete. If the TCP transport connection is successful, the state transitions to OpenSent. If the transport connection is not successful, the state transitions to Active. If the connect-retry timer has expired, the state remains in the Connect state, the timer is reset, and a transport connection is initiated. With any other event, the state goes back to Idle. |
Active | BGP tries to acquire a peer by initiating a transport protocol connection. If it is successful, the state transitions to OpenSent. If the connect-retry timer expires, BGP restarts the connect timer and falls back to the Connect state. BGP continues to listen for a connection that may be initiated from another peer. The state may go back to Idle in case of other events, such as a stop event. In general, a neighbor state flip-flopping between Connect and Active is an indication that there is a problem with the TCP transport connection. Such a problem might be caused by many TCP retransmissions or the inability of a neighbor to reach the IP address of its peer. |
OpenSent | BGP receives an open message from its peer. In the OpenSent state, BGP compares its autonomous system (AS) number with the AS number of its peer and recognizes whether the peer belongs to the same AS (internal BGP) or to a different AS (external BGP). The open message is checked for correctness. In case of errors, such as a bad version number of an unacceptable AS, BGP sends an error-notification message and goes back to Idle. For any other errors, such as expiration of the hold timer or a stop event, BGP sends a notification message with the corresponding error code and falls back to the Idle state. If there are no errors, BGP sends keepalive messages and resets the keepalive timer. In this state, the hold time is negotiated. If the hold time is 0, the hold and keepalive timers are not restarted. When a TCP transport disconnect is detected, the state falls back to Active. |
OpenConfirm | BGP waits for a keepalive or notification message. If a keepalive is received, the state becomes Established, and the neighbor negotiation is complete. If the system receives an update or keepalive message, it restarts the hold timer (assuming that the negotiated hold time is not 0). If a notification message is received, the state falls back to Idle. The system sends periodic keepalive messages at the rate set by the keepalive timer. In case of a transport disconnect notification or in response to a stop event, the state falls back to Idle. In response to other events, the system sends a notification message with a finite state machine (FSM) error code and goes back to Idle. |
Established | This is the final state in the neighbor negotiation. In this state, BGP exchanges update ackets with its peers and the hold timer is restarted at the receipt of an update or keepalive message when it is not set to zero. If the system receives a notification message, the state falls back to Idle. Update messages are checked for errors, such as missing attributes, duplicate attributes, and so on. If errors are found, a notification is sent to the peer, and the state falls back to Idle. BGP goes back to Idle when the hold timer expires, a disconnect notification is received from the transport protocol, a stop event is received, or in response to any other event. |
For more detailed BGP protocol packet information, configure BGP-specific tracing. See Checklist for Tracking Error Conditions for more information.
