Troubleshooting checklist
Work from the bottom of the stack up.
Session will not come up
| Symptom | Likely causes | Check | |
|---|---|---|---|
| Idle | Neighbor shut down, no route to peer, max-prefix triggered | show bgp neighbor X — look for the last reset reason | |
| Connect ↔ Active | TCP not establishing: wrong address, ACL/firewall on 179, peer not configured, TCP-MD5 password mismatch | ping the peer address, `ss -tnp \ | grep 179`, packet capture |
| OpenSent → Idle | OPEN rejected: wrong remote-as, bad router ID, unacceptable hold time | Log messages showing NOTIFICATION codes | |
| Flapping every 180s | Keepalives lost: MTU issues, CPU, policers | Hold timer expiry in logs, interface errors | |
| eBGP over loopbacks won't connect | TTL 1 by default | ebgp-multihop 2 or disable-connected-check |
Session is up but routes are missing
- Did the peer send it?
show bgp neighbor X received-routes(requiressoft-reconfiguration inbound) versusshow bgp neighbor X routes. The difference is your inbound policy. - Is it in the BGP table but not best?
show bgp 203.0.113.0/24— shows every path and why it lost. - Is the NEXT_HOP reachable? An inaccessible next hop makes the path invalid (classic iBGP mistake — use
next-hop-self). - Is it best but not in the RIB? Another protocol with a lower administrative distance may own the prefix (
rRIB-failure). - Am I not advertising it?
networkrequires an exact match in the RIB; checkshow bgp neighbor X advertised-routesand your outbound policy.
Useful FRR commands
show bgp summary
show bgp neighbor 192.0.2.2
show bgp ipv4 unicast 203.0.113.0/24
show bgp neighbor 192.0.2.2 advertised-routes
clear bgp 192.0.2.2 soft in
debug bgp updatesCongratulations — you now understand BGP well enough to read a production edge configuration. Next steps: communities-based traffic engineering, RPKI, and EVPN as a BGP address family.
Check your understanding
A session is Established and the peer says they are sending you 10.0.0.0/8, but it is not in your BGP table at all. What is the most likely cause?
- The TCP session is blocked by a firewall
- Your inbound policy is filtering it
- The hold timer is too short
- The router IDs are the same
Where next
- BGP on loopbacks vs interface addressesBuilds on this lesson · Intermediate · 45 min
Why BGP sessions between loopbacks survive link failures and use parallel links, and what they need to work: an IGP or static routes, update-source, the eBGP connected check, and BFD. Every failure is reproduced on two real VyOS routers.
- IPv4 over an IPv6-only core (RFC 8950)Builds on this lesson · Intermediate · 40 min
Carry IPv4 routes over IPv6 BGP sessions with IPv6 next hops, so core routers need no IPv4 addresses at all. Built on VyOS: the missing router ID, what breaks without the extended next hop capability, native IPv4 on the wire, and why traceroute shows 192.0.0.8.
- Debugging BGP: every session state, reproducedBuilds on this lesson · Intermediate · 60 min
Break a working BGP lab a dozen ways and learn to read each failure: Idle, Connect, Active and OpenSent, max-prefix, firewalls, wrong AS, TTL, hold timers, missing policy and unreachable next hops, all with real FRR output and packet captures.
- Route reflectors on VyOSAlso covers BGP, iBGP, route reflector · Intermediate · 30 min
Replace an iBGP full mesh with route reflectors: see iBGP refuse to pass routes on, turn on reflection, read ORIGINATOR_ID and CLUSTER_LIST, confirm the reflector stays out of the forwarding path, and survive taking one reflector down.