A BGP neighbor is stuck in Active. What does that tell you, and what do you check?
Show the answer
Say this first
Active means BGP keeps trying to build the TCP session to port 179 and it keeps failing, so the problem is below BGP policy. I check the route to the neighbor address and back, that each side's neighbor statement matches the address the other side sources from (update-source), the eBGP TTL when peering on loopbacks, ACLs or firewalls dropping TCP 179, that the peer is configured for me at all, and MD5 password mismatches.
Go deeper
Checklist in the order I run it
- Reachability with the real addresses.
ping 10.255.0.2 source Loopback0tests exactly the pair BGP will use. A plain ping from the physical interface proves less. - Neighbor address and update-source. If R1 has no
update-source Loopback0, its SYN leaves from the physical interface address. R2 has no neighbor with that address and resets the connection. - eBGP on loopbacks. eBGP expects a directly connected peer. Without
ebgp-multihopordisable-connected-check, IOS does not even try:show ip bgp neighborsreports that the external neighbor is not directly connected and the state sits in Idle rather than Active. Worth knowing as the neighbouring symptom. - Port 179 filtered. Interface ACLs, CoPP, or a firewall in the path. Check ACL hit counters.
- Authentication. A password on one side only or a mismatch logs
%TCP-6-BADAUTHwith "No MD5 digest" or "Invalid MD5 digest" and the TCP session never completes. - The peer. Is the neighbor configured on the far side, with my address, and not shut down?
What does not cause Active
Route maps, prefix lists and filter lists cannot stop a session from forming. A wrong remote-as gets
further: TCP comes up, the OPEN is rejected with NOTIFICATION 2/2, and the log tells you so.
They will ask next
Only one router has update-source configured. Does the session come up?
Often yes. The router with update-source connects from its loopback, which the other side recognises, so that connection succeeds. The reverse direction keeps failing. It works by luck of which side connects; configure both.
What is the difference between stuck in Idle and stuck in Active?
Idle means BGP is not even trying: admin shutdown, max-prefix hold-down, backing off after errors, or on IOS no route to the neighbor. Active means it tries and the TCP handshake fails.
Traps
- Digging through route maps for a neighbor in Active. Policy never blocks the session itself.
- Declaring reachability fine after a ping sourced from the wrong interface.