Unless specified explicitly, the Data field of the NOTIFICATION
message that is sent to indicate an error is empty.
6.1. Message Header Error Handling
All errors detected while processing the Message Header MUST be
indicated by sending the NOTIFICATION message with the Error Code
Message Header Error. The Error Subcode elaborates on the specific
nature of the error.
The expected value of the Marker field of the message header is all
ones. If the Marker field of the message header is not as expected,
then a synchronization error has occurred and the Error Subcode MUST
be set to Connection Not Synchronized.
If at least one of the following is true:
- if the Length field of the message header is less than 19 or
greater than 4096, or
- if the Length field of an OPEN message is less than the minimum
length of the OPEN message, or
- if the Length field of an UPDATE message is less than the
minimum length of the UPDATE message, or
- if the Length field of a KEEPALIVE message is not equal to 19,
or
- if the Length field of a NOTIFICATION message is less than the
minimum length of the NOTIFICATION message,
then the Error Subcode MUST be set to Bad Message Length. The Data
field MUST contain the erroneous Length field.
If the Type field of the message header is not recognized, then the
Error Subcode MUST be set to Bad Message Type. The Data field MUST
contain the erroneous Type field.
6.2. OPEN Message Error Handling
All errors detected while processing the OPEN message MUST be
indicated by sending the NOTIFICATION message with the Error Code
OPEN Message Error. The Error Subcode elaborates on the specific
nature of the error.
If the version number in the Version field of the received OPEN
message is not supported, then the Error Subcode MUST be set to
Unsupported Version Number. The Data field is a 2-octet unsigned
integer, which indicates the largest, locally-supported version
number less than the version the remote BGP peer bid (as indicated in
the received OPEN message), or if the smallest, locally-supported
version number is greater than the version the remote BGP peer bid,
then the smallest, locally-supported version number.
If the Autonomous System field of the OPEN message is unacceptable,
then the Error Subcode MUST be set to Bad Peer AS. The determination
of acceptable Autonomous System numbers is outside the scope of this
protocol.
If the Hold Time field of the OPEN message is unacceptable, then the
Error Subcode MUST be set to Unacceptable Hold Time. An
implementation MUST reject Hold Time values of one or two seconds.
An implementation MAY reject any proposed Hold Time. An
implementation that accepts a Hold Time MUST use the negotiated value
for the Hold Time.
If the BGP Identifier field of the OPEN message is syntactically
incorrect, then the Error Subcode MUST be set to Bad BGP Identifier.
Syntactic correctness means that the BGP Identifier field represents
a valid unicast IP host address.
If one of the Optional Parameters in the OPEN message is not
recognized, then the Error Subcode MUST be set to Unsupported
Optional Parameters.
If one of the Optional Parameters in the OPEN message is recognized,
but is malformed, then the Error Subcode MUST be set to 0
(Unspecific).
6.3. UPDATE Message Error Handling
All errors detected while processing the UPDATE message MUST be
indicated by sending the NOTIFICATION message with the Error Code
UPDATE Message Error. The error subcode elaborates on the specific
nature of the error.
Error checking of an UPDATE message begins by examining the path
attributes. If the Withdrawn Routes Length or Total Attribute Length
is too large (i.e., if Withdrawn Routes Length + Total Attribute
Length + 23 exceeds the message Length), then the Error Subcode MUST
be set to Malformed Attribute List.
If any recognized attribute has Attribute Flags that conflict with
the Attribute Type Code, then the Error Subcode MUST be set to
Attribute Flags Error. The Data field MUST contain the erroneous
attribute (type, length, and value).
If any recognized attribute has an Attribute Length that conflicts
with the expected length (based on the attribute type code), then the
Error Subcode MUST be set to Attribute Length Error. The Data field
MUST contain the erroneous attribute (type, length, and value).
If any of the well-known mandatory attributes are not present, then
the Error Subcode MUST be set to Missing Well-known Attribute. The
Data field MUST contain the Attribute Type Code of the missing,
well-known attribute.
If any of the well-known mandatory attributes are not recognized,
then the Error Subcode MUST be set to Unrecognized Well-known
Attribute. The Data field MUST contain the unrecognized attribute
(type, length, and value).
If the ORIGIN attribute has an undefined value, then the Error Sub-
code MUST be set to Invalid Origin Attribute. The Data field MUST
contain the unrecognized attribute (type, length, and value).
If the NEXT_HOP attribute field is syntactically incorrect, then the
Error Subcode MUST be set to Invalid NEXT_HOP Attribute. The Data
field MUST contain the incorrect attribute (type, length, and value).
Syntactic correctness means that the NEXT_HOP attribute represents a
valid IP host address.
The IP address in the NEXT_HOP MUST meet the following criteria to be
considered semantically correct:
a) It MUST NOT be the IP address of the receiving speaker.
b) In the case of an EBGP, where the sender and receiver are one
IP hop away from each other, either the IP address in the
NEXT_HOP MUST be the sender’s IP address that is used to
establish the BGP connection, or the interface associated with
the NEXT_HOP IP address MUST share a common subnet with the
receiving BGP speaker.
If the NEXT_HOP attribute is semantically incorrect, the error SHOULD
be logged, and the route SHOULD be ignored. In this case, a
NOTIFICATION message SHOULD NOT be sent, and the connection SHOULD
NOT be closed.
The AS_PATH attribute is checked for syntactic correctness. If the
path is syntactically incorrect, then the Error Subcode MUST be set
to Malformed AS_PATH.
If the UPDATE message is received from an external peer, the local
system MAY check whether the leftmost (with respect to the position
of octets in the protocol message) AS in the AS_PATH attribute is
equal to the autonomous system number of the peer that sent the
message. If the check determines this is not the case, the Error
Subcode MUST be set to Malformed AS_PATH.
If an optional attribute is recognized, then the value of this
attribute MUST be checked. If an error is detected, the attribute
MUST be discarded, and the Error Subcode MUST be set to Optional
Attribute Error. The Data field MUST contain the attribute (type,
length, and value).
If any attribute appears more than once in the UPDATE message, then
the Error Subcode MUST be set to Malformed Attribute List.
The NLRI field in the UPDATE message is checked for syntactic
validity. If the field is syntactically incorrect, then the Error
Subcode MUST be set to Invalid Network Field.
If a prefix in the NLRI field is semantically incorrect (e.g., an
unexpected multicast IP address), an error SHOULD be logged locally,
and the prefix SHOULD be ignored.
An UPDATE message that contains correct path attributes, but no NLRI,
SHALL be treated as a valid UPDATE message.
6.4. NOTIFICATION Message Error Handling
If a peer sends a NOTIFICATION message, and the receiver of the
message detects an error in that message, the receiver cannot use a
NOTIFICATION message to report this error back to the peer. Any such
error (e.g., an unrecognized Error Code or Error Subcode) SHOULD be
noticed, logged locally, and brought to the attention of the
administration of the peer. The means to do this, however, lies
outside the scope of this document.
6.5. Hold Timer Expired Error Handling
If a system does not receive successive KEEPALIVE, UPDATE, and/or
NOTIFICATION messages within the period specified in the Hold Time
field of the OPEN message, then the NOTIFICATION message with the
Hold Timer Expired Error Code is sent and the BGP connection is
closed.
6.6. Finite State Machine Error Handling
Any error detected by the BGP Finite State Machine (e.g., receipt of
an unexpected event) is indicated by sending the NOTIFICATION message
with the Error Code Finite State Machine Error.
6.7. Cease
In the absence of any fatal errors (that are indicated in this
section), a BGP peer MAY choose, at any given time, to close its BGP
connection by sending the NOTIFICATION message with the Error Code
Cease. However, the Cease NOTIFICATION message MUST NOT be used when
a fatal error indicated by this section does exist.
A BGP speaker MAY support the ability to impose a locally-configured,
upper bound on the number of address prefixes the speaker is willing
to accept from a neighbor. When the upper bound is reached, the
speaker, under control of local configuration, either (a) discards
new address prefixes from the neighbor (while maintaining the BGP
connection with the neighbor), or (b) terminates the BGP connection
with the neighbor. If the BGP speaker decides to terminate its BGP
connection with a neighbor because the number of address prefixes
received from the neighbor exceeds the locally-configured, upper
bound, then the speaker MUST send the neighbor a NOTIFICATION message
with the Error Code Cease. The speaker MAY also log this locally.
6.8. BGP Connection Collision Detection
If a pair of BGP speakers try to establish a BGP connection with each
other simultaneously, then two parallel connections well be formed.
If the source IP address used by one of these connections is the same
as the destination IP address used by the other, and the destination
IP address used by the first connection is the same as the source IP
address used by the other, connection collision has occurred. In the
event of connection collision, one of the connections MUST be closed.
Based on the value of the BGP Identifier, a convention is established
for detecting which BGP connection is to be preserved when a
collision occurs. The convention is to compare the BGP Identifiers
of the peers involved in the collision and to retain only the
connection initiated by the BGP speaker with the higher-valued BGP
Identifier.
Upon receipt of an OPEN message, the local system MUST examine all of
its connections that are in the OpenConfirm state. A BGP speaker MAY
also examine connections in an OpenSent state if it knows the BGP
Identifier of the peer by means outside of the protocol. If, among
these connections, there is a connection to a remote BGP speaker
whose BGP Identifier equals the one in the OPEN message, and this
connection collides with the connection over which the OPEN message
is received, then the local system performs the following collision
resolution procedure:
1) The BGP Identifier of the local system is compared to the BGP
Identifier of the remote system (as specified in the OPEN
message). Comparing BGP Identifiers is done by converting them
to host byte order and treating them as 4-octet unsigned
integers.
2) If the value of the local BGP Identifier is less than the
remote one, the local system closes the BGP connection that
already exists (the one that is already in the OpenConfirm
state), and accepts the BGP connection initiated by the remote
system.
3) Otherwise, the local system closes the newly created BGP
connection (the one associated with the newly received OPEN
message), and continues to use the existing one (the one that
is already in the OpenConfirm state).
Unless allowed via configuration, a connection collision with an
existing BGP connection that is in the Established state causes
closing of the newly created connection.
Note that a connection collision cannot be detected with connections
that are in Idle, Connect, or Active states.
Closing the BGP connection (that results from the collision
resolution procedure) is accomplished by sending the NOTIFICATION
message with the Error Code Cease.
7. BGP Version Negotiation
BGP speakers MAY negotiate the version of the protocol by making
multiple attempts at opening a BGP connection, starting with the
highest version number each BGP speaker supports. If an open attempt
fails with an Error Code, OPEN Message Error, and an Error Subcode,
Unsupported Version Number, then the BGP speaker has available the
version number it tried, the version number its peer tried, the
version number passed by its peer in the NOTIFICATION message, and
the version numbers it supports. If the two peers do support one or
more common versions, then this will allow them to rapidly determine
the highest common version. In order to support BGP version
negotiation, future versions of BGP MUST retain the format of the
OPEN and NOTIFICATION messages.
8. BGP Finite State Machine (FSM)
The data structures and FSM described in this document are conceptual
and do not have to be implemented precisely as described here, as
long as the implementations support the described functionality and
they exhibit the same externally visible behavior.
This section specifies the BGP operation in terms of a Finite State
Machine (FSM). The section falls into two parts:
1) Description of Events for the State machine (Section 8.1)
2) Description of the FSM (Section 8.2)
Session attributes required (mandatory) for each connection are:
1) State
2) ConnectRetryCounter
3) ConnectRetryTimer
4) ConnectRetryTime
5) HoldTimer
6) HoldTime
7) KeepaliveTimer
8) KeepaliveTime
The state session attribute indicates the current state of the BGP
FSM. The ConnectRetryCounter indicates the number of times a BGP
peer has tried to establish a peer session.
The mandatory attributes related to timers are described in Section
10. Each timer has a "timer" and a "time" (the initial value).
The optional Session attributes are listed below. These optional
attributes may be supported, either per connection or per local
system:
1) AcceptConnectionsUnconfiguredPeers
2) AllowAutomaticStart
3) AllowAutomaticStop
4) CollisionDetectEstablishedState
5) DampPeerOscillations
6) DelayOpen
7) DelayOpenTime
8) DelayOpenTimer
9) IdleHoldTime
10) IdleHoldTimer
11) PassiveTcpEstablishment
12) SendNOTIFICATIONwithoutOPEN
13) TrackTcpState
The optional session attributes support different features of the BGP
functionality that have implications for the BGP FSM state
transitions. Two groups of the attributes which relate to timers
are:
group 1: DelayOpen, DelayOpenTime, DelayOpenTimer
group 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer
The first parameter (DelayOpen, DampPeerOscillations) is an optional
attribute that indicates that the Timer function is active. The
"Time" value specifies the initial value for the "Timer"
(DelayOpenTime, IdleHoldTime). The "Timer" specifies the actual
timer.
Please refer to Section 8.1.1 for an explanation of the interaction
between these optional attributes and the events signaled to the
state machine. Section 8.2.1.3 also provides a short overview of the
different types of optional attributes (flags or timers).
8.1. Events for the BGP FSM
8.1.1. Optional Events Linked to Optional Session Attributes
The Inputs to the BGP FSM are events. Events can either be mandatory
or optional. Some optional events are linked to optional session
attributes. Optional session attributes enable several groups of FSM
functionality.
The linkage between FSM functionality, events, and the optional
session attributes are described below.
Group 1: Automatic Administrative Events (Start/Stop)
Optional Session Attributes: AllowAutomaticStart,
AllowAutomaticStop,
DampPeerOscillations,
IdleHoldTime, IdleHoldTimer
Option 1: AllowAutomaticStart
Description: A BGP peer connection can be started and stopped
by administrative control. This administrative
control can either be manual, based on operator
intervention, or under the control of logic that
is specific to a BGP implementation. The term
"automatic" refers to a start being issued to the
BGP peer connection FSM when such logic determines
that the BGP peer connection should be restarted.
The AllowAutomaticStart attribute specifies that
this BGP connection supports automatic starting of
the BGP connection.
If the BGP implementation supports
AllowAutomaticStart, the peer may be repeatedly
restarted. Three other options control the rate
at which the automatic restart occurs:
DampPeerOscillations, IdleHoldTime, and the
IdleHoldTimer.
The DampPeerOscillations option specifies that the
implementation engages additional logic to damp
the oscillations of BGP peers in the face of
sequences of automatic start and automatic stop.
IdleHoldTime specifies the length of time the BGP
peer is held in the Idle state prior to allowing
the next automatic restart. The IdleHoldTimer is
the timer that holds the peer in Idle state.
An example of DampPeerOscillations logic is an
increase of the IdleHoldTime value if a BGP peer
oscillates connectivity (connected/disconnected)
repeatedly within a time period. To engage this
logic, a peer could connect and disconnect 10
times within 5 minutes. The IdleHoldTime value
would be reset from 0 to 120 seconds.
Values: TRUE or FALSE
Option 2: AllowAutomaticStop
Description: This BGP peer session optional attribute indicates
that the BGP connection allows "automatic"
stopping of the BGP connection. An "automatic"
stop is defined as a stop under the control of
implementation-specific logic. The
implementation-specific logic is outside the scope
of this specification.
Values: TRUE or FALSE
Option 3: DampPeerOscillations
Description: The DampPeerOscillations optional session
attribute indicates that the BGP connection is
using logic that damps BGP peer oscillations in
the Idle State.
Value: TRUE or FALSE
Option 4: IdleHoldTime
Description: The IdleHoldTime is the value that is set in the
IdleHoldTimer.
Values: Time in seconds
Option 5: IdleHoldTimer
Description: The IdleHoldTimer aids in controlling BGP peer
oscillation. The IdleHoldTimer is used to keep
the BGP peer in Idle for a particular duration.
The IdleHoldTimer_Expires event is described in
Section 8.1.3.
Values: Time in seconds
Group 2: Unconfigured Peers
Optional Session Attributes: AcceptConnectionsUnconfiguredPeers
Option 1: AcceptConnectionsUnconfiguredPeers
Description: The BGP FSM optionally allows the acceptance of
BGP peer connections from neighbors that are not
pre-configured. The
"AcceptConnectionsUnconfiguredPeers" optional
session attribute allows the FSM to support the
state transitions that allow the implementation to
accept or reject these unconfigured peers.
The AcceptConnectionsUnconfiguredPeers has
security implications. Please refer to the BGP
Vulnerabilities document [RFC4272] for details.
Value: True or False
Group 3: TCP processing
Optional Session Attributes: PassiveTcpEstablishment,
TrackTcpState
Option 1: PassiveTcpEstablishment
Description: This option indicates that the BGP FSM will
passively wait for the remote BGP peer to
establish the BGP TCP connection.
value: TRUE or FALSE
Option 2: TrackTcpState
Description: The BGP FSM normally tracks the end result of a
TCP connection attempt rather than individual TCP