A BGP session reaches OpenSent, then drops to Idle with a NOTIFICATION on every retry; what in the OPEN exchange, including capability negotiation, causes that?
answer
- TCP worked; the OPEN did not
- the subcode names the field
- AS, hold time, identifier, version
- both must advertise a capability
basics
~20 sThe peer's OPEN failed a check: wrong AS, an unacceptable hold time, a bad BGP Identifier, an unsupported version or optional parameter, or a required capability missing. The receiver sends an OPEN Message Error NOTIFICATION whose subcode names the problem, then returns to Idle.
solid answer
~50 sReaching `OpenSent` proves TCP to port 179 works; the session is failing on the `OPEN` itself. RFC 4271 checks each field and answers a bad one with a `NOTIFICATION`, error code OPEN Message Error, and a subcode: Unsupported Version Number, Bad Peer AS (the AS in the OPEN is not the one configured for this peer), Bad BGP Identifier, Unsupported Optional Parameter, or Unacceptable Hold Time. RFC 5492 adds capabilities, carried as optional parameter type 2: a capability is used only when both peers advertise it, an unrecognised one MUST be ignored, and a speaker that needs one its peer lacks MAY close with Unsupported Capability (subcode 7). So the usual causes are a mistyped remote AS, a 4-octet ASN that one side reads as AS_TRANS 23456, or a required address family the peer does not support.
go deeper
Recall that an OPEN carries the version, the sender's AS, a hold time and an identifier, and that a bad OPEN ends with a NOTIFICATION.
Explain the OPEN fields and their subcodes, and the capability rules: both must advertise, unknown ones are ignored.
Use the NOTIFICATION subcode to go straight to the cause, and know the traps: a mistyped remote AS, AS_TRANS with four-octet ASNs, a required address family missing on one side.
Discuss how capability negotiation let BGP grow for decades without flag days, and what an estate must standardise so that sessions are not refused when features are rolled out.
## Where the session is failing A **BGP session** that reaches **OpenSent** has already completed its TCP connection to port 179, because OPEN is the first message sent after TCP connects. If it then falls back to **Idle** with a NOTIFICATION on every attempt, the fault is in the **OPEN exchange**: one speaker read the other's OPEN and rejected it. The NOTIFICATION's subcode says which check failed, so it is the first thing to read. ## What an OPEN carries | Field | Size | Meaning | |---|---|---| | Version | 1 octet | the BGP version; 4 for BGP-4 | | My Autonomous System | 2 octets | the sender's AS number | | Hold Time | 2 octets | the sender's proposed hold time, in seconds | | BGP Identifier | 4 octets | the sender's identifier, the same on every interface and peer | | Optional Parameters Length | 1 octet | total length of the optional parameters | | Optional Parameters | variable | type, length and value triplets; type 2 is Capabilities | With the 19-octet header, an OPEN is at least 29 octets long. ## The checks and their subcodes Every failure is reported with the **OPEN Message Error** code and one of these subcodes: | Subcode | Name | What triggers it | |---|---|---| | 1 | Unsupported Version Number | the Version field holds a version the receiver does not run | | 2 | Bad Peer AS | the AS in the OPEN is not acceptable; which values are acceptable is local configuration | | 3 | Bad BGP Identifier | RFC 4271: not a valid unicast host address; RFC 6286 relaxes this to any non-zero 4-octet value, and flags an internal peer that sends the receiver's own Identifier | | 4 | Unsupported Optional Parameter | an optional parameter type the receiver does not recognise | | 6 | Unacceptable Hold Time | an offer of 1 or 2 seconds, which MUST be rejected, or any value the receiver chooses to refuse | | 7 | Unsupported Capability | added by RFC 5492: the peer lacks a capability this speaker requires | The most common in practice is **Bad Peer AS**. In this scenario, the speaker in AS 64500 is configured to expect AS 64501 from 192.0.2.2, but the peer's OPEN says 64502. TCP connects, OPENs cross, the check fails, a NOTIFICATION goes out, and the cycle repeats on the next retry. ## How capability negotiation works Base BGP-4 had a problem: a speaker that received an optional parameter it did not recognise had to end the session, so every new feature risked breaking old peers. **RFC 5492** (which obsoletes RFC 3392) fixed this with a **Capabilities** optional parameter, type 2, holding one or more triples of capability code, length and value. Its rules: - **Both sides must advertise.** A capability can be used on a session only if both peers advertised it in their OPEN messages. - **Unknown capabilities are ignored.** A speaker that receives a capability it does not support MUST ignore it; it MUST NOT send Unsupported Capability or end the session for that reason. - **A required capability can end the session.** If a speaker needs a capability the peer did not advertise, it MAY send Unsupported Capability, listing what was missing, and close. RFC 5492's example is a session set up to exchange IPv6 routes with a peer that lacks multiprotocol support. Such a session SHOULD NOT be re-established automatically. - **Old speakers get a second try.** A speaker too old to know the Capabilities parameter answers with Unsupported Optional Parameter; the sender SHOULD then retry without capabilities. Some capabilities that show up in every OPEN: | Code | Capability | Defined in | |---|---|---| | 1 | Multiprotocol extensions (address families beyond IPv4 unicast) | RFC 4760 | | 2 | Route refresh | RFC 2918 | | 64 | Graceful restart | RFC 4724 | | 65 | Four-octet AS number support | RFC 6793 | Capabilities travel only in OPEN, so one switched on later takes effect when the session is next established. ## The four-octet AS trap The My Autonomous System field is only 2 octets. A speaker whose AS number does not fit, say 65550, writes **AS_TRANS (23456)** there and carries its real number in capability 65 (RFC 6793). A peer that supports the capability reads 65550 from it; a peer that does not sees only 23456. A remote-AS setting that does not match what the receiver actually reads produces Bad Peer AS on every attempt. The rest of AS_TRANS belongs to the autonomous-systems subject. ## Working the fault 1. Read the NOTIFICATION's code and subcode on both ends. 2. For Bad Peer AS, compare the configured remote AS with the AS the peer really sends. 3. For Unsupported Capability, compare the address families and features each side requires. 4. For Unacceptable Hold Time, compare the hold times configured on each side.
- Why did BGP need a capabilities mechanism at all, instead of just adding new optional parameters to OPEN?Under RFC 4271, a speaker that receives an optional parameter it does not recognise must reject the OPEN with Unsupported Optional Parameter, ending the session. Every new feature would have broken peering with older speakers. RFC 5492 puts features inside one Capabilities parameter whose unknown entries MUST be ignored, so new features can be announced without breaking peers that lack them.
- A BGP speaker with a four-octet AS number peers with an old speaker that lacks capability 65; what AS does the old speaker see?It sees AS_TRANS, 23456, in the 2-octet My Autonomous System field, because the real number does not fit and the old speaker cannot read the capability that carries it. The old side must be configured to expect 23456 for that peer; if it expects anything else, it rejects the OPEN with Bad Peer AS.
saying these in an interview costs you the question
- A session that reaches OpenSent and drops must have a routing or firewall problem.
- An unrecognised capability in a BGP OPEN must be answered with Unsupported Capability.
- A BGP capability can be used once either peer advertises it.
- The NOTIFICATION subcode is just noise; the log line says nothing useful.
- Capabilities can be renegotiated mid-session with another OPEN.