| The BGP neighbor negotiation process
proceeds through various states, or stages, which can be described
in terms of a finite-state machine (FSM).
The BGP FSM
Recall that in Chapter 6, EIGRP, an FSM was defined as a
set of possible states something can go through, what events causes
those states, and what events result from those states. The figure
presents the BGP FSM, which includes the states and some of the
message events that cause them.
The six states of the BGP FSM are
described below:
- Idle
- Idle is the first
state of a BGP connection. BGP is waiting for a start event,
which is normally initiated by an administrator or a network
event. At the start event, BGP initializes its resources, resets
a connect retry timer, and starts listening for a TCP connection
that may be initiated by a remote peer. BGP then transitions to a Connect state. Note that BGP can
transition back to Idle from any other state in case of errors.
- Connect
- In the connect state; BGP is waiting for the TCP connection to be completed. If
the TCP connection is successful, the state transitions to
OpenSent. If the TCP connection fails, the state transitions to
the Active state, and the router tries to connect again. If the
connect retry timer expires, the state remains in the Connect
state, the timer is reset, and a TCP connection is initiated. In
case of any other event (initiated by system or administrator),
the state returns to Idle.
- Active
- In the Active
state, BGP is trying to acquire a peer by initiating a TCP
connection. If it is successful, it transitions to OpenSent. If
the connect retry timer expires, BGP restarts the connect timer
and falls back to the Connect state. While active, 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 and that there are problems
with the TCP connection. It could be because of many TCP retransmissions,
or the incapability of a neighbor to reach the IP address of its
peer.
- OpenSent
- In the OpenSent
state, BGP is waiting for an open message from its peer. The
open message is checked for correctness. In case of errors, such
as an incompatible 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. If the
negotiated hold time is 0, the hold timer and the keepalive
timer are not restarted.
At the OpenSent state, BGP recognizes
whether the peer belongs to the same AS (an IBGP peer) or to a
different AS (an EBGP peer) by comparing its AS number to the AS
number of its peer.
When a TCP disconnect is detected,
the state falls back to Active. For any other errors, such as an
expiration of the hold timer, BGP sends a notification message with
the corresponding error code and falls back to the Idle state.
- OpenConfirm
- While in
OpenConfirm state, BGP is waiting for a keepalive or
notification message. If a keepalive message is received, the
state goes to the Established state, 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 the case of any TCP disconnect or in response to any stop
event (initiated by the system or the administrator), the state
falls back to Idle. In response to any other event, the system
sends a notification message with an FSM error code and returns
to the idle state.
- Established
- Established
is the final state in the neighbor negotiation; BGP starts
exchanging update packets with its peers. If it is
nonzero, the hold timer is restarted at the receipt of an update
or keepalive message.
Each update message is checked for
errors, such as missing or duplicate attributes. If errors are
found, a notification is sent to the peer. Any notification received
while in the Established state will cause the BGP process to drop
the receiving peer back to idle. If the hold timer expires, a
disconnect notification is received from TCP or if a stop event is
received, the system will fall back to Idle.
|