|
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 Module 6, EIGRP, an FSM was defined. An FSM is a
set of possible states something can go through, what events causes
those states, and what events will result from those states. 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 as follows:
- Idle – Idle is the first state of a BGP connection. BGP
is waiting for a start event. It is normally initiated by an
administrator or a network event. At the start event, BGP
initializes its resources and resets a connect retry timer. Then it starts
listening for a TCP notice 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 the system or
the 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 returns 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 switching 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 zero (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 or to a different AS. BGP does this by comparing its AS number to the AS
number of its peer. A same AS is an IBGP peer and a different AS is an
EBGP 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. Then
it
returns 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 time, assuming that the
negotiated hold time is not zero. 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 returns
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 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. 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 return to Idle.
| |
Interactive Media Activity
Drag and Drop: BGP Neighbor Negotiation
Upon completion of this activity, the student will be able to
understand the BGP process for establishing neighbor
relationships.
|
|
|
|
