Day 46 — BGP over TCP: Active/Passive Establishment, Collision Handling and Session Diagnostics

1. Opening

BGP finite-state behavior sits on top of TCP. When engineers jump directly from Active state to route-map changes, they often skip the layer that is actually broken. Understanding who initiated TCP, what happens during simultaneous opens, and when OPEN is exchanged makes session troubleshooting far more deterministic.

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 BGP connection collision handling. Both speakers can attempt TCP establishment at the same time, temporarily creating parallel connections. After OPEN messages reveal BGP identifiers, the collision procedure deterministically retains one connection and closes the other. This is normal protocol handling, not necessarily an outage.

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

Use R1 AS65010 and R2 AS65020 on a directly connected documentation subnet. Capture TCP port 179 and BGP state during startup. Restart BGP on both nearly simultaneously and observe establishment/collision behavior in logs or packet capture if the lab permits.

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.2 remote-as 65020
 !
 address-family ipv4
  neighbor 192.0.2.2 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

Perform a coordinated session restart in the lab and capture TCP SYN, SYN-ACK and ACK followed by BGP OPEN and KEEPALIVE.

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.

Apply an ACL or control-plane rule that silently blocks TCP/179 in one direction while ICMP remains allowed. Ping succeeds, but TCP establishment fails.

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 fault is transport filtering, not BGP policy. Correct the TCP/179 permit in the approved control-plane policy and verify the session progresses past Connect/Active.

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

Active and passive are behaviors, not health labels

BGP speakers normally can initiate and accept TCP connections. The FSM Active state does not mean the router is permanently the active client side.

Collision handling is expected

Two simultaneous TCP attempts are possible. RFC 4271 resolves them once OPEN information is available. Seeing one connection close during startup can therefore be protocol-normal.

Diagnostic ordering

If no TCP handshake completes, capability analysis is premature. If TCP completes but the peer stays OpenSent or sends NOTIFICATION, transport is working and investigation should move upward to OPEN parameters.

Packet evidence

A short capture can distinguish SYN retransmission, RST, successful TCP followed by BGP NOTIFICATION, or stable exchange. Never fabricate capture output; label illustrative fields when exact execution is unavailable.

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 — BGP FSM and connection collision detection
• RFC 9293 — TCP
• Cisco IOS XE 17.x BGP neighbor diagnostics