show ip bgp summary is the first command most of us type when BGP is in the incident channel. It is also one of the most misread. Here is how to read it in the ten seconds before you decide what to run next.
The header
BGP router identifier and local AS number: confirm you are on the box you think you are on. It sounds obvious; it has saved careers.
BGP table version and main routing table version: if these are far apart and moving, the box is still converging. Wait before you judge anything below.
The memory lines are noise until they are not. A router that has 941712 network entries where it had 20000 last week has started receiving full tables from someone.
The neighbour table
Neighbor: the peer address. Match it against your documentation, not your memory.
V: BGP version. Always 4. If you ever see anything else, stop reading this and start reading the vendor's bug database.
AS: the remote AS. Same number as your own AS means iBGP; the rules for next-hop and route reflection apply. Different means eBGP.
MsgRcvd / MsgSent: they should both be climbing. A peer with a large received count and a sent count that stopped moving is a peer that stopped listening to you; check the TCP session and your outbound policy.
TblVer: the peer's table version. Should match the header's table version on a converged box. A peer stuck behind is a peer you are slow to update, usually because of a heavy outbound policy or a small hold queue.
InQ / OutQ: non-zero and growing is a stuck peer or an overloaded box. Non-zero and steady is normal on a busy edge.
Up/Down: the time since the last state change. 3w2d is boring, which is what you want. 00:02:17 on a peer that should be boring is the peer to look at.
State/PfxRcd: the column that matters. A number is a prefix count and means Established. A word is a state, and every word is a problem:
Idle: not trying. Usually an admin shutdown, a missing route to the peer, or the neighbour was just configured.Connect: trying TCP and failing. Reachability, an ACL, or the wrong update-source.Active: TCP failed and it is retrying. Same causes as Connect; the one you will see most.OpenSent/OpenConfirm: TCP is up, BGP is negotiating. If a peer is stuck here for more than a few seconds, look for an AS mismatch, an MD5 password mismatch, or a capability the other side refuses.
The patterns
One peer Active, everything else Established with stable counts: it is that peer or their side. Check show ip bgp neighbors <peer> | include Last reset|Notification before you touch anything.
Everything Active at once: it is you. Interface, routing to the peers, or someone just changed the router-id.
Established with a prefix count of 0 from a transit provider: you are connected and receiving nothing. Inbound policy, a max-prefix that tripped and was reset, or they are sending you a session and no routes on purpose.
A prefix count that jumped by an order of magnitude: a leak, yours or theirs. Look at show ip bgp summary on the peer's other neighbours next.
Why we wrote this on a product blog
Because the assistant in NetStacks is given this table when you ask about a BGP problem, and its answer is only as good as the reading above. It will tell you 198.51.100.9 is Active and that the other peers are healthy. You should already know that, and be asking it the next question.