Reading the state
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.
By the end you will be able to:
- Read a BGP session's state and last reset reason, and name the layer to investigate
- Recognise Idle (Admin), Idle (PfxCt) and No path to specified Neighbor, and fix each
- Tell a firewall drop from an unconfigured peer with a packet capture on TCP port 179
- Diagnose OPEN failures (Bad Peer AS) and eBGP TTL problems from the log and the packets
- Explain hold-timer expiry, missing eBGP policy, import filtering and unreachable next hops on an established session
Prerequisites: BGP Fundamentals
When a BGP session is broken, the state it's stuck in tells you which layer to look at, so the first command is always the summary, not the configuration. This lesson breaks a working lab in a dozen different ways, one at a time, and shows exactly what each failure looks like: the state, the log line and, where it helps, the packets.
Every BGP problem is one of two kinds:
- The session won't come up. The state column shows something other than a prefix count. The cause is somewhere between the cable and the OPEN message.
- The session is up, but the routes are wrong. The state column shows a number, or
(Policy). The cause is policy, limits or next hops.
What each state is telling you
A BGP session is driven by a finite state machine (FSM) with six states. When it's stuck, the state it's stuck in narrows the search:
| State | What the router is doing | Look at |
|---|---|---|
| Idle | Not trying at all: shut down, held down after an error, or waiting to start | Configuration and the last reset reason |
| Connect | Has sent a TCP SYN to port 179 and is waiting for an answer | The path: firewalls, routing back |
| Active | Has no TCP connection; waiting to retry, or for the peer to call | Reachability, and whether the peer is configured for you |
| OpenSent | TCP is up and its OPEN is sent; waiting for the peer's OPEN | AS numbers, router IDs, capabilities |
| OpenConfirm | OPENs agreed; waiting for the first KEEPALIVE | Rarely stuck here for long |
| Established | Up. Problems from here on are about routes | Policy, limits and next hops |
Active misleads everyone: it does not mean "working". It means the router is actively retrying. A session that flips between Connect and Active has a TCP problem, not a BGP configuration problem.
Three tools, in this order
show bgp summary: the state of every session, and the prefix counts for the established ones.show bgp neighbors <address>: the detail for one session, especially Last reset, which records why it last went down.- The log. FRR writes a line every time a session goes up or down, with the reason, but only if you ask it to (
bgp log-neighbor-changes). When even that isn't enough,tcpdumpon TCP port 179 shows whether the problem is below BGP entirely.
The labs here use FRRouting (FRR), so the commands are FRR's vtysh commands. VyOS runs FRR underneath and its operational commands are almost the same (show ip bgp summary, show ip bgp neighbors), so everything you see here reads the same on a VyOS router.
Interactive: The BGP state machine Step through the events that move a session between states; every one of them appears in this lesson's lab. (needs JavaScript)