Day 48 — BGP OPEN Capabilities, NOTIFICATION Errors and Session-Engineering Capstone

1. Opening

Once TCP succeeds, BGP still has to agree on the OPEN message and optional capabilities. Many sessions that appear almost up are failing here—not because route policy is wrong, but because the two speakers disagree on parameters or required capabilities.

A session-engineering problem should be solved from the bottom up. Before modifying route policy, prove endpoint reachability, source address, TCP behavior, TTL/security controls, authentication and negotiated BGP parameters. An Established session is the result of all of those layers agreeing.

2. Concept and standards behavior

RFC 4271 defines OPEN message fields and NOTIFICATION error handling. RFC 5492 defines capability advertisement using an OPEN optional parameter so extensions can be negotiated gracefully. Capabilities are not assumed merely because both devices support a feature locally; the relevant capability must be exchanged as required by that extension.

The engineering boundary matters: RFC behavior defines interoperable protocol rules, while dynamic-neighbor syntax, password configuration, peer templates and some security commands are implementation-specific. Exact syntax and feature support must therefore be verified on the actual IOS XE platform and release used in the lab or production network.

3. Scenario

Build a loopback eBGP session from AS65010 to AS65020 with validated multihop and authentication. Activate IPv4 unicast and inspect neighbor capability output. Then introduce one controlled OPEN or capability mismatch.

Success criteria

1. The intended TCP endpoints and source addresses are explicit.
2. BGP reaches Established without weakening unrelated security controls.
3. Negotiated capabilities match the required address families/features.
4. A negative test proves an unauthorized or incorrectly formed session fails.
5. Rollback returns the neighbor relationship to the captured baseline.

4. Topology diagram

A matching editable SVG and PNG are stored under media/diagrams/.

5. Prerequisites

• Cisco IOS XE 17.18.x documentation baseline.
• Documentation-safe IPv4 addressing only.
• Stable underlay reachability before BGP troubleshooting.
• Independent management access.
• Time synchronization and logging for authentication/failure analysis.
• Pre-change capture of neighbor state and relevant TCP/BGP diagnostics.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 neighbor 192.0.2.20 remote-as 65020
 neighbor 192.0.2.20 update-source Loopback0
 neighbor 192.0.2.20 ebgp-multihop 2
 neighbor 192.0.2.20 password LAB-ONLY-PLACEHOLDER
 !
 address-family ipv4
  neighbor 192.0.2.20 activate
 exit-address-family

Any authentication secret shown in a lab must be a non-production placeholder. Never copy a tutorial key into production.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors
show tcp brief all
show ip route
show logging

When the session does not reach Established, identify the last successful layer: IP reachability, TCP establishment, BGP OPEN exchange, capability negotiation, or post-OPEN KEEPALIVE.

8. Controlled modification

Inspect negotiated capabilities before enabling any optional feature. Record route-refresh, multiprotocol/address-family and four-octet-AS capability evidence where shown by the platform.

Capture the expected state transition before changing configuration. If the modification is expected to reset the TCP session, state that explicitly and preserve logs.

9. Fault injection

Illustrative lab — not a real incident.

Configure the wrong remote AS on one side while leaving TCP reachability and authentication otherwise correct. The peer should reject the OPEN rather than reaching normal route exchange.

Inject only one fault at a time. A failed session is useful evidence only if the experiment can identify which layer rejected it.

10. Step-by-step troubleshooting

1. Confirm the configured neighbor address or dynamic range.
2. Confirm local and remote source addresses.
3. Verify a valid route exists to the remote endpoint.
4. Verify return-path reachability.
5. Inspect TCP state and port 179 behavior.
6. Validate TTL, multihop and GTSM assumptions.
7. Validate authentication configuration and key-selection state where used.
8. Inspect BGP FSM state.
9. Inspect OPEN message parameters and negotiated capabilities.
10. Read the NOTIFICATION/error evidence rather than repeatedly clearing the session.
11. Correct the smallest proven cause.
12. Re-run both positive and negative tests.

11. Root cause and correction

The OPEN parameters are inconsistent. Restore the correct remote-AS value, verify OPEN and KEEPALIVE progression, then confirm expected capabilities and route exchange.

12. Post-fix verification

Confirm TCP stability, BGP Established state, expected AFI/SAFI activation, route exchange, absence of recurring NOTIFICATION messages, and intended rejection of the negative test.

13. Rollback

Restore the exact prior neighbor/session configuration. Authentication or TTL changes need a synchronized rollback plan on both peers. Roll back if the session cannot be restored within the approved change window, if another peer is affected, or if the security posture is weakened beyond the approved design.

14. Deep-dive engineering notes

OPEN is the protocol identity exchange

The OPEN message communicates version, AS-related identity, hold-time, BGP identifier and optional parameters. A completed TCP handshake is necessary but not sufficient for BGP adjacency.

Capabilities prevent blind extension use

RFC 5492 lets speakers announce optional protocol capabilities. Extensions such as multiprotocol AFI/SAFI, four-octet ASN support, route refresh and ADD-PATH rely on capability mechanisms defined by their standards.

NOTIFICATION is evidence

An OPEN Message Error or other NOTIFICATION should be interpreted before clearing the session. Repeated resets can erase the timeline that identifies the mismatch.

Capstone method

Troubleshoot in this order: reachability, source and return path, TCP, TTL/GTSM, authentication, FSM/OPEN, capabilities, AFI/SAFI, route policy. That ordering prevents a high-layer change from masking a lower-layer fault.

15. Production lessons

• Treat transport, security and BGP negotiation as separate diagnostic layers.
• Never weaken authentication or TTL controls merely to force Established state.
• Feature support is platform/release specific; standards support does not guarantee identical CLI support.
• Capture negative tests as part of session acceptance.
• Document which side initiates, what source address is expected, and what capabilities are required.

16. Knowledge check

1. Why can successful IP reachability coexist with a failed BGP session?
2. Which evidence distinguishes TCP failure from an OPEN/capability failure?
3. Why is temporarily removing authentication a poor troubleshooting default?

Answers

1. Reachability proves only IP forwarding; TCP, TTL controls, authentication, FSM parameters and capabilities can still fail.
2. TCP state plus BGP neighbor/error/NOTIFICATION evidence.
3. It changes the security boundary and can hide the actual mismatch instead of proving it.

17. Sources

• RFC 4271 — OPEN/NOTIFICATION/error handling
• RFC 5492 — BGP Capabilities Advertisement
• RFC 8810 — capability-code registry revision
• Cisco IOS XE 17.x — BGP neighbor capability diagnostics