TTR Networks

BGP troubleshooting cheat sheet

A BGP problem is almost always one of two things: the session won't come up, or the session is up but a route is missing. Work from the bottom of the stack up — link, IP reachability, TCP port 179, the OPEN exchange, then policy — and the cause usually shows itself within a few commands.

Commands are given for VyOS operational mode and for FRR's vtysh (VyOS runs FRR underneath, so the output looks the same). The linked lessons show each one with real output from a lab.

What the session state tells you

StateWhat it meansUsual causes
IdleNot trying: waiting to start, or held down after an errorNeighbour shut down, no route to the peer address, maximum-prefix limit hit
Connect / ActiveTrying to open the TCP connection, failing, retryingWrong peer address, peer not configured for you, a firewall dropping TCP 179, no route back, eBGP to a loopback without multihop, mismatched TCP-MD5 password
OpenSent → IdleTCP worked, but the OPEN was rejectedWrong remote-as, bad router ID, unacceptable hold time, mismatched capabilities
OpenConfirmOPENs exchanged, waiting for the first KEEPALIVERarely stays here; if it does, keepalives are being lost
Established, then drops every few minutesKeepalives lost until the hold timer expiresMTU problems on the path, policers, overloaded control plane

The name Active misleads everyone: it means the router is actively retrying, not that the session is up. A session that flips between Connect and Active is a reachability or TCP problem, not a BGP configuration problem.

Session won't come up

  1. Can you reach the peer address from the address you peer from? ping 192.0.2.1 source-address 198.51.100.1 count 3. When peering between loopbacks, both loopbacks must be in the routing table at both ends.
  2. Is TCP 179 getting through? Capture it: monitor traffic interface eth0 filter "tcp port 179" on VyOS, tcpdump -ni eth0 tcp port 179 on Linux. SYNs with no reply point at a firewall or a peer that isn't configured; a RST means the peer refuses this source address.
  3. Is the router's own firewall blocking it? An input filter that doesn't allow TCP 179 from the peer stops the session as surely as a remote one. Check show firewall ipv4 input filter.
  4. What does the session say about the last failure? show ip bgp neighbors 192.0.2.1 | match "BGP state|Last reset" on VyOS, or show bgp neighbors 192.0.2.1 in FRR. The last reset reason and any NOTIFICATION (bad peer AS, hold timer expired, authentication) usually name the problem.
  5. eBGP between loopbacks? eBGP packets are sent with a TTL of 1 by default and peers are expected to be directly connected; use ebgp-multihop (or disable-connected-check for directly connected loopbacks).

Session is up but a route is missing

  1. Did the peer send it? Compare show ip bgp neighbors 192.0.2.1 received-routes (what arrived, before your policy; needs soft-reconfiguration inbound) with show ip bgp neighbors 192.0.2.1 routes (what your import policy kept). A prefix in the first but not the second was filtered by you.
  2. Is it in the table but not chosen? show bgp ipv4 203.0.113.0/24 lists every path and marks the best one. Work down the best-path order: local preference, AS path length, origin, MED, eBGP over iBGP, IGP cost to the next hop.
  3. Is the next hop reachable? A path whose next hop can't be resolved is never best. This is the classic iBGP problem: routes learned from an eBGP neighbour keep that neighbour's address as next hop unless the border router sets next-hop-self. show ip nht shows what each next hop resolves through.
  4. Is it best in BGP but not in the routing table? Another source with a lower administrative distance (a static route, OSPF) may own the prefix. Check show ip route 203.0.113.0/24.
  5. Are you not sending it? show ip bgp neighbors 192.0.2.1 advertised-routes shows what leaves. A network statement only advertises a prefix that exists in the routing table exactly; an export route-map without a final permit rule sends nothing. FRR also refuses to send or accept any eBGP routes until a policy is applied, by default.

The commands

TaskVyOSFRR (vtysh)
All sessions at a glanceshow ip bgp summaryshow bgp summary
One session in detailshow ip bgp neighbors 192.0.2.1show bgp neighbors 192.0.2.1
Every path for a prefixshow bgp ipv4 203.0.113.0/24show bgp ipv4 unicast 203.0.113.0/24
What you send a peershow ip bgp neighbors 192.0.2.1 advertised-routesshow bgp neighbors 192.0.2.1 advertised-routes
What a peer sent, after policyshow ip bgp neighbors 192.0.2.1 routesshow bgp neighbors 192.0.2.1 routes
Next-hop trackingshow ip nhtshow ip nht
BFD sessionsshow bfd peers briefshow bfd peers brief
Re-apply policy without dropping the session—clear bgp 192.0.2.1 soft in

Learn the why