When BGP breaks, whole subnets drop off the map at once — it's the protocol that glues networks together, so a single flapping session can black-hole a lot of traffic. You don't need to be a network architect to triage it; you need to answer two questions in order: is the session up, and are the routes right?
1. Check the session state first
A BGP neighbor should be in the Established state. Anything else is your headline:
vtysh -c 'show bgp summary' # one line per peer + state vtysh -c 'show bgp neighbors 10.0.0.1' # Idle/Active = never connected (L3/ACL/config) # Connect = TCP 179 not completing # OpenSent/Confirm = handshake mismatch (ASN/auth)
The stuck state tells you where to look: Idle/Active means the peer is unreachable or filtered (check routing to it and any ACL/firewall on TCP 179); the Open states mean the peers reached each other but disagree on ASN, auth, or capabilities.
2. Session up but traffic still wrong? Look at routes
If the session is Established, the problem is which prefixes are being exchanged. Check what you receive and advertise:
vtysh -c 'show bgp ipv4 unicast' # the BGP table vtysh -c 'show bgp neighbors 10.0.0.1 received-routes' vtysh -c 'show bgp neighbors 10.0.0.1 advertised-routes'
A missing prefix is usually a route-map or prefix-list filtering it out, or it was never originated. A wrong path is usually a policy/attribute (local-pref, AS-path) decision.
3. When (and how) to clear
If config is correct but the session is wedged or holding stale routes, clear it — and prefer a soft clear so you don't tear the whole session down: vtysh -c 'clear bgp ipv4 unicast * soft' re-applies policy without a full reset. A hard clear bgp * bounces every session — effective, but it's a blunt instrument, so scope it to the one peer when you can.
Practise network incidents
BGP session failures and route flaps are among the router incidents the Chaos Engine fires (they need the Network Diagnostics skill to reveal the hint). Work them live in a full incident response shift.