A “BGP session down” alert tells you a neighbor left the Established state. It does not tell you why. The same alert can come from a failed link, a congested path, a misconfigured neighbor, an exceeded prefix limit or a peer that restarted. Working through the layers in order prevents you from editing routing policy when the real problem is an optic.
1. Read the state the session is stuck in
The finite-state machine gives a first clue. Idle usually means the local router is not attempting a connection, for example because the session is administratively shut, no route to the peer exists or a previous failure is in a backoff period. Active means the router is trying to open the TCP connection and not succeeding. OpenSent or OpenConfirm means TCP worked but capabilities, ASN, hold time or authentication did not complete. A session that flips between Active and Idle points at transport, not policy.
2. Prove the transport path
- Can the local router reach the neighbor address, and from the correct source interface?
- For eBGP over loopbacks, is multihop or TTL configured to match?
- Is TCP port 179 permitted in both directions by any firewall or ACL in the path?
- Did the underlying interface, LAG or tunnel change state just before the session dropped?
3. Read the reset reason
Most platforms record why a session closed. “Hold timer expired” means keepalives stopped arriving within the negotiated hold time, which usually implies loss, congestion, CPU starvation or a link problem on the path. A “Cease” notification often indicates an administrative action or a maximum-prefix limit. An OPEN message error points to a mismatch such as a wrong remote AS, an unsupported capability or an authentication failure. Capture the exact reason text and timestamp in the incident.
4. Treat hold timer expiry as a path question
When the hold timer expires, look for what interfered with keepalives: CRC errors or flaps on the transit link, high utilization or drops on the egress queue, control-plane CPU spikes, or a peer that was busy after a reload. If several sessions expired at nearly the same moment, the cause is probably shared, so look for the common link or device before troubleshooting each neighbor.
5. Check negotiation and policy
- Local and remote ASN match what both sides configured
- Authentication keys or TCP-AO/MD5 settings match, including after a rotation
- Address families and capabilities are enabled on both ends
- Maximum-prefix limits were not exceeded by a sudden change in advertisements
- Inbound and outbound policy did not change in a recent deployment
6. Decide whether it is one session or many
A single down session with healthy links elsewhere suggests a neighbor-specific issue. Multiple sessions down across one device suggest a device or shared-link failure. Sessions down on both sides of a link may be one incident with several symptoms. Grouping them correctly is the difference between one page and twelve. See how alert correlation should group related symptoms.
7. Confirm recovery with more than “Established”
A session that returns to Established is not necessarily healthy. Confirm the expected prefixes are being received again, that route counts are near their prior level, that the session is stable across several keepalive intervals and that dependent services have recovered. A flapping session that briefly reaches Established can look fixed on a dashboard and still be failing.
Evidence worth attaching to the incident
- Neighbor address, ASN, VRF and address family
- State before and after, with timestamps
- The reset or notification reason as reported by the device
- Interface and CPU observations near the drop time
- Prefix counts before and after recovery
A good RCA states which layer failed and what evidence supports it. Read the evidence model for network RCA.