OPEN Message Format

Figure 4-13 illustrates the format of the OPEN message. The descriptions that follow summarize each of its fields:

•  Version—A 1-byte unsigned integer that indicates the version of the BGP protocol, such as BGP3 or BGP4. During the neighbor negotiation, BGP peers agree on a BGP version number. BGP peers will try to negotiate the highest common version that they both support. Cisco Systems provides the option of predefining the version negotiated to cut down on the negotiation process. Setting the version statically is usually used when the versions of the BGP peers are already known.

•  My Autonomous System—A 2-byte field that indicates the AS number of the BGP router.

•  Hold Time—The maximum amount of time in seconds that may elapse between the receipt of successive KEEPALIVE or UPDATE messages. The hold timer is a counter that increments from zero to the hold time value. Receipt of a KEEPALIVE or UPDATE message causes the hold timer to reset to zero. If the hold time for a particular neighbor is exceeded, the neighbor would be considered dead. The hold time is a 2-byte unsigned integer.
The BGP router negotiates with its neighbor to set the hold time at whichever value is lower—its own hold time or its neighbor's. The hold time could be 0, in which case the hold timer and the KEEPALIVE timers are never reset—that is, these timers never expire, and the connection is considered to be always up. If not set to zero, the minimum recommended hold time is three seconds.

•  BGP Identifier—A 4-byte unsigned integer that indicates the sender's ID. In Cisco's implementation, this is usually the router ID (RID), which is calculated as the highest IP address on the router or the highest loopback address at BGP session startup. (Loopback address is Cisco's representation of the IP address of a virtual software interface that is considered to be up at all times, irrespective of the state of any physical interface.)

•  Optional Parameters—This is a variable length field that indicates a list of optional parameters used in BGP neighbor session negotiation. This field is represented by the triplet <Parameter Type, Parameter Length, Parameter Value> with lengths of 1-byte, 1-byte, and variable length, respectively. An example of optional parameters is the authentication information parameter (type1), which is used to authenticate the session with a BGP peer.

•  Optional Parameter Length—This is a 1-byte unsigned integer that indicates the total length in bytes of the Optional Parameters field. A length value of 0 indicates that no Optional Parameters are present.

Figure 4-13  OPEN message format.

Finite State Machine Perspective

BGP neighbor negotiation proceeds through different stages before the connection is fully established. Figure 4-14 illustrates a simplified finite state machine (FSM) that highlights the major events in the process with an indication of messages (OPEN, KEEPALIVE, NOTIFICATION) sent to the peer in the transition from one state to the other.

Figure 4-14  BGP neighbor negotiation finite state machine.

The following discussions summarize the key states in the FSM example illustrated in Figure 4-14:

1.  Idle—This is the first stage of the connection. BGP is waiting for a Start event, which is normally initiated by an operator. A Start event is usually caused by an administrator establishing a BGP session through router configuration or resetting an already existing session. After the Start event, BGP initializes its resources, resets a connect retry timer, initiates a TCP transport connection, and starts listening for a connection that may be initiated by a remote peer. BGP then transitions to a Connect state. In case of errors, BGP falls back to the Idle state.

2.  Connect—BGP is waiting for the transport protocol connection to be completed. If the TCP transport connection is successful, the state transitions to OpenSent (this is where the OPEN message is sent). If the transport connection is not successful, the state transitions to Active. If the connect retry timer expires, the state will remain in the connect stage, the timer will be reset, and a transport connection will be initiated. In case of any other event (initiated by system or operator), the state will go back to Idle.

3.  Active—BGP is trying to acquire a peer by initiating a transport protocol connection. If it is successful, it will transition to OpenSent (an OPEN message is sent). If the connect retry timer expires, BGP will restart the connect timer and fall back to the connect state. Also, BGP is still listening 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 initiated by the system or the operator.
In general, a neighbor state that is flip-flopping between Connect and Active is an indication that something is wrong with the TCP transport connection not taking effect. It could be because of many TCP retransmissions or the inability of a neighbor to reach the IP address of its peer.

---

Troubleshooting:  
The meaning of flip-flopping between Conne and Active state

---

4.  OpenSent—BGP is waiting for an OPEN message from its peer. The OPEN message is checked for correctness. In case of errors, such as a bad version number or an unacceptable AS, the system sends an error NOTIFICATION message and goes back to Idle. If there are no errors, BGP starts sending KEEPALIVE messages and resets the KEEPALIVE timer. At this stage, the hold time is negotiated, and the smaller value is taken. In case the negotiated hold time is 0, the hold timer and the KEEPALIVE timer are not restarted.
At the OpenSent state, the BGP will recognize, by comparing its AS number to the AS number of its peer, whether the peer belongs to the same AS (Internal BGP) or to a different AS (External BGP).
When a TCP transport disconnect is detected, the state will fall back to Active. For any other errors, such as an expiration of the hold timer, the BGP will send a NOTIFICATION message with the corresponding error code and will fall back to the Idle state. Also, in response to a stop event initiated by system or operator, the state will fall back to Idle.

5.  OpenConfirm—BGP waits for a KEEPALIVE or NOTIFICATION message. If a KEEPALIVE is received, the state will go to 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 will send periodic KEEPALIVE messages at the rate set by the KEEPALIVE timer. In case of any transport disconnect notification or in response to any stop event (initiated by the system or the operator), the state will fall back to Idle. In response to any other event, the system will send a NOTIFICATION message with an FSM (Finite State Machine) error code and will go back to Idle.

6.  Established—This is the final stage in the neighbor negotiation. At this stage, BGP starts exchanging UPDATE packets with its peers. Assuming that it is non-zero, the Hold timer is restarted at the receipt of an UPDATE or KEEPALIVE message. If the system receives any NOTIFICATION message—that is, some error has occurred—the state will fall back to Idle.
The 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 will fall back to Idle. In case the Hold timer expires, or a disconnect notification is received from the transport protocol, or a Stop event is received, or in response to any other event, the system will fall back to Idle.