| BGP neighbor
negotiation proceeds through different stages before the connection
is fully established. The Figure 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.
The following discussions summarize
the key states in the FSM example illustrated in the Figure:
- Idle -- This is the first
stage of the connection. BGP is waiting for a Start event, which
is normally initiated by an operator or a network event; a Start
event is usually caused by an administrator configuring a BGP
session, resetting an already existing session, or a link coming
up across which a BGP is configured. At 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.
- 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.
- 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.
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 the TCP transport connection is 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.
- 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. If the negotiated hold time is 0, the
hold timer and the KEEPALIVE timer are not restarted.
At the OpenSent state, the BGP will
recognize whether the peer belongs to the same AS (IBGP) or to a
different AS (EBGP) by comparing its AS number to the AS number of
its peer.
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, BGP will send a
NOTIFICATION message with the corresponding error code and will fall
back to the Idle state.
- OpenConfirm -- While in this
state, BGP is waiting 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 error code and will go back to Idle.
- Established -- This is the
final stage in the neighbor negotiation; 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.
Each UPDATE message is checked for
errors, such as missing or duplicate attributes, etc; if errors are
found, a NOTIFICATION is sent to the peer. Any NOTIFICATION received
while Established will cause the BGP process to drop this peer back
to Idle. If the hold timer expires, a disconnect notification is
received from the transport protocol, or a Stop event is received,
then the system will fall back to Idle.
|
|