When a BGP speaker sets up a BGP session with a peer BGP speaker, several different types of messages are communicated during the session starting with the OPEN messages. How to handle different types of messages depends on triggering a number of events and what state to move to depends on the action—which is a stateful mechanism. Thus, a finite state machine is used to describe the relation of a BGP speaker’s state to each of its BGP peers;
that is, a speaker needs to maintain a separate finite state machine with each of its BGP peer- ing speakers. The basic states are classified into the following: Idle state, Connect state, Ac- tive state, OpenSent state, OpenConfirm state, and Established state. BGP specification [591]
documents 28 different types of possible events: 16 of them are mandatory and the rest are optional; they are listed in Table 8.2. In the following, we discuss each state and provide a general overview about state transition. The finite state machine is shown in Figure 8.15; for details, refer to RFC 4271 [591].
IDLESTATE
This is the initial state of a BGP speaker. In this state, the BGP speaker is not yet ready to accept a BGP connection. At the occurrence of either a manual start (ME01) or automatic start (OE03) event, the BGP speaker initializes BGP resources, starts the ConnectRetryTimer, starts a TCP connection to its BGP peer speaker, and also listens for any incoming BGP connection.
It then moves to the Connect state. However, if this BGP speaker were to take the passive role in the sense of event OE04 or OE05, the initialization is similar to when either ME01 or ME02 occurs, except that it moves to the Active state instead of Connect state. If dampening of peer oscillation is activated, then three additional events, OE06, OE07, and OE13, may occur; in this situation, the local BGP speaker tries to prevent peer oscillations using the dampening principle.
F I G U R E 8.15 Finite state machine of a BGP speaker for connection to a peer.
TA B L E 8.2 BGP events.
Event Status Remark
ME01 Mandatory Local BGP administrator manually starts the BGP connection to a peer BGP speaker
ME02 Mandatory Local BGP administrator stops the BGP connection to a peer BGP speaker
OE03 Optional Local system automatically starts the BGP connection
OE04 Optional A local BGP administrator is to manually start the BGP connection to a peer BGP speaker, but it first listens to an incoming BGP connection before starting the BGP connection
OE05 Optional Local system automatically starts the BGP connection, but it first lis- tens to an incoming BGP connection before starting the BGP connec- tion
OE06 Optional Local system automatically starts the BGP connection with the damp- ing of oscillation activated
OE07 Optional Local system automatically starts the BGP connection with the damp- ing of oscillation activated and also first listens for an incoming BGP connection
OE08 Optional Local system automatically stops the BGP connection ME09 Mandatory Indication that the ConnectRetryTimer has just expired ME10 Mandatory Indication that the HoldTimer has just expired
ME11 Mandatory Indication that the KeepAliveTimer has just expired OE12 Optional Indication that the DelayOpenTimer has just expired OE13 Optional Indication that the IdleHoldTimer has just expired
OE14 Optional Indication that the local system has received a valid TCP connection OE15 Optional Indication that the local system has received a TCP connection for the
BGP session with either an invalid source IP address or port number, or an invalid destination IP address or port number
ME16 Mandatory Indication that the local system has successfully set up a TCP connec- tion to its remote BGP speaker that it initiated
ME17 Mandatory Indication that the local system has confirmed the TCP connection ini- tiated by a remote BGP speaker
ME18 Mandatory Indication that the local system has received a notice about failure of a TCP connection to a peer BGP speaker
ME19 Mandatory Indication that a valid OPEN message is received from the remote BGP speaker
OE20 Optional Indication that a valid OPEN message has been received, but is delay- ing the sending of an OPEN message due to DelayOpenTimer running ME21 Mandatory Indication that the header of a received BGP message is not valid ME22 Mandatory Indication that there is some error with the OPEN message received OE23 Optional Indication of the detection of a connection collision during processing
of an incoming OPEN message and this connection is to be discon- nected
TA B L E 8.2 (Continued.)
Event Status Remark
ME24 Mandatory Indication that a version error code has been received with a NOTIFI- CATION message
ME25 Mandatory Indication that an error code other than version error code has been received with a NOTIFICATION message
ME26 Mandatory Indication that a KEEPALIVE message has been received ME27 Mandatory Indication that a valid UPDATE message has been received ME28 Mandatory Indication that an invalid UPDATE message has been received
CONNECTSTATE
In this state, the BGP speaker is now waiting for the TCP connection to be established. Several different actions are possible depending on the triggering of events. If manual stoppage is in- voked (event ME02), the connection is dropped, resources are released, and the BGP speaker then moves to the Idle state. If ConnectRetryTimer expires (event ME09), the BGP speaker drops the connection, restarts the ConnectRetryTimer, stops the DelayOpenTimer if this was activated earlier, starts a new TCP connection while listening to a connection initiated by the other side, and remains in the Connect state.
From a receiving point of view, if the TCP connection is valid (event OE14), it is processed and it stays at the Connect state. If the TCP connection is successful (ME16 or ME17), then the DelayOpen value is checked. If it is true, then timers are reset and it remains at the Connect set; however, if DelayOpen is not set, then the local BGP speaker stops the ConnectRetry- Timer, completes BGP initialization, sends an OPEN message to the remote BGP speaker, sets the HoldTimer to a large value, and moves to the OpenSent state.
If the TCP connection request is invalid (OE15), it is rejected and stays at the Connect state. However, if it is valid but the connection fails (ME18), the system checks if DelayOpen- Timer is running. If so, the timers are reset, and it continues to listen to a connection from its peer, and then moves to the Active state. If DelayOpenTimer is not running, the connection is dropped, BGP resources are released, and it moves to the Idle state.
It is possible to receive an OPEN message while the DelayOpenTimer is still running (OE20). If so, an OPEN message is sent in response and a KEEPALIVE message is also gen- erated, and the state is changed to the OpenConfirm state. This also occurs when the au- tonomous system number on the received OPEN message is checked to determine if the peer is external or internal.
If there is any error while checking BGP header (ME21) or OPEN message (ME22), all BGP resources are released and the connection is dropped.
In response to an OPEN message, it is possible to receive a NOTIFICATION message with a version error (ME24); if so, BGP resources are released, the TCP connection is dropped, and it changes to the Idle state. For the rest of the events, if any of them occurs, the same handling procedure is used.
ACTIVESTATE
The role of this state is to acquire a BGP peer. If manual stoppage occurs (ME02), the connec- tion is dropped and the state is changed to the Idle state. If the ConnectRetryTimer expires, a new TCP connection is initiated and, at the same time, listens to one, then moves its state to the Connect state. If the DelayOpenTimer expires or delayed open is not set, an OPEN message is sent to its BGP peer, and it moves to the OpenSent state. If, however, an OPEN message is received and the delay open timer is running (OE20), an OPEN message is sent and a KEEPALIVE message is sent.
If there is an error detected when checking the BGP message header or OPEN message, the connection is dropped and the state changes to the Idle state. In case of a NOTIFICATION message with version error (ME24), the handling is the same.
OPENSENT
Normally, the speaker arrives at the OpenSent state from the Active state; in this state, an OPEN message is sent immediately or later depending on the DelayOpenTimer value and at the same time it waits for an OPEN message from its BGP peer. If an OPEN message is received and there is no error in the message (ME19), a KEEPALIVE message is sent, the KeepAliveTimer is activated, and it moves to the OpenConfirm state. In all other events, the connection is dropped while sending a NOTIFICATION message as applicable and the state is changed to Idle, except if TCP connection fails (ME18); in this case, the state is changed to the Active state.
Once the optional local DelayOpenTimer expires, the speaker sends the OPEN message and waits to hear an OPEN message from its neighboring BGP speaker. If an OPEN message is received, fields are checked; if errors occurs such as a bad version number or an unaccept- able AS number, it sends a NOTIFICATION message and moves to the Idle state.
Note that if the BGP speaker supports the Capabilities option, it can advertise this infor- mation when it sends the OPEN message and inquire, for example, if the ROUTE–REFRESH capability is supported by the receiving speaker. If the other end responds using a NOTIFI- CATION message stating that it does not support the ROUTE–REFRESH capability, a new OPEN message is generated in which the optional capability is turned off.
OPENCONFIRMSTATE
In this state, the speaker waits for either a KEEPALIVE or a NOTIFICATION message, or generates a KEEPALIVE message. An important action here is when the HoldTimer expires;
in this case, a NOTIFICATION message is sent and the TCP connection is dropped. If the KeepAliveTimer expires, a KEEPALIVE message is sent and a new KeepAliveTime value is generated, and the state is changed to the Established state.
If a NOTIFICATION or a NOTIFICATION with a version error (ME24) is received, the connection is dropped and the state changes to the Idle state. If an OPEN message is received (ME19), a NOTIFICATION is sent and the connection is closed and moves to the Idle state.
Note that at this state, a NOTIFICATION message from its peer BGP speaker is also possible if the peer does not support the ROUTE–REFRESH capability; this situation arises only if it has included ROUTE–REFRESH capability in the optional capability parameter when it sent out its OPEN message.
ESTABLISHEDSTATE
In the established state, a BGP speaker normally exchanges UPDATE, NOTIFICATION, and KEEPALIVE messages with a peering BGP speaker. If a stoppage event occurs (ME02, OE08), a NOTIFICATION is sent, the connection is closed, and it moves to the Idle state.
If HoldTimer expires (ME10), a NOTIFICATION is sent, the TCP connection is dropped, peer oscillation damping is performed, and the system changes to the Idle state. If the KeepAliveTimer expires, a KEEPALIVE message is sent and a new KeepAliveTime value is generated, and the state is changed to the Established state. Note that each time a KEEPALIVE or UPDATE is received, the KeepAliveTimer is re-initialized with a new value.