Routing / BGP · engineering note

BGP Neighbor Stuck in Active: A Structured Troubleshooting Approach

NetworkSupport.live · Technical reference review: 16 October 2026 · Cisco IOS / IOS XE IPv4 examples

Active describes connection establishment, not a diagnosed fault. Use the state alongside transport evidence and logs to decide where to investigate.

1. Understand the state

BGP’s finite state machine includes Idle, Connect, Active, OpenSent, OpenConfirm, and Established. Connect waits for TCP connection completion. In Active, the speaker listens for and accepts a peer connection; retry-timer expiry initiates another connection attempt and returns to Connect. Successful TCP establishment normally leads to OPEN exchange, then OpenConfirm and Established. Optional timers and errors affect transitions. “Active” does not mean routes are being exchanged. [1]

2. Establish a reliable baseline

Record the peer, VRF or routing context, observed state, last reset reason, timestamps, and recent changes on both ends. Compare repeated observations; a single snapshot can hide a brief transition.

show ip bgp summary
show ip bgp neighbors 192.0.2.2
show ip route 192.0.2.2
show ip interface brief
show logging

These are diagnostic examples, not commands executed for a customer. Syntax varies by platform, release, VRF, and address family. Review local output securely; redact credentials and identifying data before sharing.

3. Trace addresses, routes, and source selection

Confirm each neighbor address and the return route to the actual BGP source. A ping from the wrong source can test a different path. For loopback peering, review neighbor … update-source and loopback reachability. [2]

Direct eBGP commonly uses TTL 1. A multihop design needs suitable TTL and routing; IOS also has connected-peer checks. Review ebgp-multihop, connected-check behavior, and any TTL-security configuration against the intended design. Do not increase TTL or disable checks as a blanket fix. [3]

4. Verify TCP, then BGP negotiation

BGP listens on TCP 179. The initiating connection typically uses an ephemeral source port. Examine both directions, return traffic, ACLs, firewall rules, and control-plane filtering. Ping success alone does not prove TCP reachability. [1]

With authorization, a source-aware TCP probe or bounded packet capture can help. No SYN reply, a reset, and a completed handshake suggest different next checks; none alone proves the cause. A generic TCP probe may use a different source or lack BGP authentication. Check the actual BGP flow before concluding.

If TCP succeeds but the session resets, inspect notifications and compare neighbor IPs, local/remote AS values, enabled state, authentication, and relevant capabilities. Wrong AS values can be rejected during OPEN processing, rather than causing an initial TCP failure. Authentication mismatches can disrupt transport. Compare configuration without exposing keys. [3]

5. Propose, authorize, and validate

Document observations, supported conclusions, and unresolved hypotheses. Propose a scoped correction and rollback plan; obtain authorization before changes, session resets, or intrusive debugging. After remediation, validate stable session establishment and the intended routing and traffic outcome. Record results and handover notes. Established alone does not prove the application path works.

References

1. RFC 4271, sections 4, 6, and 8
2. Cisco IOS BGP command reference: update-source and multihop
3. Cisco: Troubleshoot Border Gateway Protocol Basic Issues