Esc
Type to search posts, tags, and more...
Skip to content

BGP error handling

BGP error detection and response — NOTIFICATION codes and subcodes, revised error handling (treat-as-withdraw), and connection collision resolution.

Contents

Error handling model

RFC 4271 uses a strict error model: detect an error, send a NOTIFICATION, close the session. This causes complete route withdrawal from the peer — disruptive for a protocol carrying the full Internet routing table.

RFC 7606 introduced revised error handling that allows certain UPDATE errors to be handled by treating the affected route as withdrawn rather than tearing down the entire session.

Error codes and subcodes

Code 1: Message Header Error

SubcodeNameTrigger
1Connection Not SynchronizedMarker field not all ones
2Bad Message LengthLength < 19 or > 4096, or wrong for message type
3Bad Message TypeUnrecognized Type field value

Data field: Bad Message Length includes the erroneous Length value. Bad Message Type includes the erroneous Type value.

Code 2: OPEN Message Error

SubcodeNameTrigger
1Unsupported Version NumberVersion field not supported
2Bad Peer ASAS number not acceptable per configuration
3Bad BGP IdentifierNot a valid unicast IPv4 address
4Unsupported Optional ParameterParameter Type not recognized
5DeprecatedWas Authentication Failure
6Unacceptable Hold TimeHold Time = 1 or 2 seconds
7Unsupported CapabilityAdded by RFC 5492

Data field: Unsupported Version Number includes the highest locally-supported version less than what the peer bid.

Code 3: UPDATE Message Error

SubcodeNameTrigger
1Malformed Attribute ListTotal length inconsistent, or duplicate attribute
2Unrecognized Well-known AttributeWell-known attribute not implemented
3Missing Well-known AttributeMandatory attribute absent from UPDATE
4Attribute Flags ErrorFlags inconsistent with Type Code
5Attribute Length ErrorLength doesn’t match expected for type
6Invalid ORIGIN AttributeORIGIN value not 0, 1, or 2
7DeprecatedWas AS Routing Loop
8Invalid NEXT_HOP AttributeNot a valid IP host address
9Optional Attribute ErrorRecognized optional attribute has invalid value
10Invalid Network FieldNLRI syntactically incorrect
11Malformed AS_PATHAS_PATH fails syntactic check

Data field: typically includes the offending attribute (type, length, value). Missing Well-known Attribute includes only the Type Code.

Code 4: Hold Timer Expired

No subcodes. Sent when no KEEPALIVE, UPDATE, or NOTIFICATION arrives within the negotiated Hold Time.

Code 5: Finite State Machine Error

No subcodes in RFC 4271. RFC 6608 added subcodes:

SubcodeName
1Receive Unexpected Message in OpenSent State
2Receive Unexpected Message in OpenConfirm State
3Receive Unexpected Message in Established State

Code 6: Cease

Administrative or resource-driven session teardown. RFC 4486 defined subcodes:

SubcodeNameCommon trigger
1Maximum Number of Prefixes ReachedPrefix limit exceeded
2Administrative ShutdownOperator-initiated (carries shutdown message)
3Peer De-configuredNeighbor removed from configuration
4Administrative ResetSession cleared by operator
5Connection RejectedInbound connection refused
6Other Configuration ChangeConfig change requires session reset
7Connection Collision ResolutionLost collision detection
8Out of ResourcesMemory or CPU exhaustion

RFC 7606: Revised UPDATE error handling

The original model resets the session for any UPDATE error. RFC 7606 changes this for most attribute-level errors:

ConditionRFC 4271 actionRFC 7606 action
Malformed well-known mandatory attributeSession resetTreat-as-withdraw
Unrecognized well-known attributeSession resetTreat-as-withdraw
Attribute flags errorSession resetTreat-as-withdraw
Invalid NEXT_HOPLog and ignore routeTreat-as-withdraw
Malformed optional transitive attributeSession resetTreat-as-withdraw
Missing well-known attributeSession resetTreat-as-withdraw

“Treat-as-withdraw” means: the routes in that UPDATE are removed from Adj-RIB-In as if a withdrawal was received, but the session remains up. Other routes from the same peer are unaffected.

Conditions that still require session reset under RFC 7606:

  • Malformed Attribute List (structural corruption)
  • Any error that makes it impossible to determine which NLRI are affected

NEXT_HOP semantic checking

NEXT_HOP has two validation layers:

Semantic errors do not trigger a NOTIFICATION — the route is logged and ignored, keeping the session alive.

Connection collision detection

When two peers simultaneously initiate TCP connections, both reach OpenSent or OpenConfirm. Upon receiving an OPEN from a peer that already has another connection in OpenConfirm:

  1. Compare BGP Identifiers as 4-octet unsigned integers
  2. Higher ID wins — the connection initiated by the higher-ID speaker survives
  3. The loser sends Cease NOTIFICATION on the duplicate connection

A collision with an existing Established session keeps the Established connection and closes the new one (unless CollisionDetectEstablishedState is enabled).

Operational impact

Session flaps from UPDATE errors (pre-7606)

A single malformed UPDATE from a peer resets the entire session. For a peer advertising 900k+ prefixes, this means full re-convergence. RFC 7606 support is critical for production stability.

Hold Timer tuning

The default 180-second Hold Time (60-second keepalive) is conservative. Some operators reduce to 9/3 seconds for fast detection, but this risks false positives on congested control planes. RFC 9687 adds a Send Hold Timer that detects a stuck local TCP socket (peer appears up but never drains the buffer).

Prefix limits

Max-prefix limits (Cease subcode 1) are a defense against route leaks and hijacks. Operators configure thresholds per address family per peer.

Sources

Last synthesized: 2026-05-07

AI-assisted synthesis from the RFCs and sources linked above.