Reading a BGP Looking Glass When a Prefix Disappears

A regional operations team messages me: one of our customer prefixes has stopped being reachable from one corner of the internet. Someone has already opened the public looking glass for the upstream router, typed the prefix, got nothing back, and concluded that BGP is down. The session was up, the prefix was in the table, and the problem was three layers away from the conclusion. That sequence is so common that I now treat the looking glass as a device that answers one narrow question and quietly invites you to answer five others wrongly.

Four questions, one prefix

When a prefix disappears, there are exactly four points where it can be lost, and they belong to different people. A looking glass usually shows you one of them.

The first question is whether the prefix arrived at the router at all. That lives in the Adj-RIB-In, per neighbour, after the session came up. If the neighbour never sent the prefix, nothing this router does will fix it. A public looking glass that shows only the local table cannot tell you this, which is why a single empty lookup is such weak evidence.

The second question is whether the router accepted it. Receiving is not accepting. An inbound prefix-list, an AS-path filter, a maximum-prefix limit, or a policy that matches a community the neighbour stopped setting all leave the prefix visibly absent while the session stays up and healthy. This is the most common place a prefix dies without anybody noticing.

The third question is whether it was selected. A prefix can be present in the BGP table and still not be the path used, because another path wins, or because the winning path has become unusable. Selection is a best-path decision governed by the rules in RFC 4271 and by every local policy term your team has added since. It is also the step where a resolver failure hides: the route can be selected and still get marked as unusable if the next hop does not resolve in the IGP.

The fourth question is whether the router advertised it onwards. A route can be present, accepted and selected, and still not leave the router, because outbound policy drops it, because it was summarised into something else, because the peer is iBGP and the route was learned from another iBGP peer without a route reflector, or because a well-known community such as NO_EXPORT was attached upstream. The fourth question is the one most often skipped, and it is often the right one.

The looking glass usually answers the third question, and sometimes the fourth, for one router. It rarely answers the first and second, because those require per-neighbour state that the page does not expose. That asymmetry is the whole source of confusion: the page looks authoritative and is structurally incomplete.

What the status codes mean, and what they do not

The codes in front of a BGP entry are a compact record of what happened to the route inside the router. They are useful, provided you do not read more into them than the vendor put there.

Code	What it marks	What to check next
*	Valid route	Nothing by itself; validity is not selection
>	Best path	Whether it is also the path that is installed and advertised
i	Learned from an iBGP peer	Route reflector topology and next-hop reachability
r	RIB failure: the route exists but cannot be used	Next-hop recursion into the IGP, or a policy rejection during installation
S	Stale, often after a graceful restart	Whether the peer actually re-converged or the stale entry is expiring
h	History entry	Whether the prefix was withdrawn recently and what withdrew it
d	Damped	Whether route dampening is enabled and what the penalty timer is doing
m or =	Multipath candidate	How many paths are installed and how they are hashed

The RIB-failure marker produces the most misleading looking-glass output. The prefix is there, the session is up, and the next hop is an address the local IGP no longer resolves. The BGP process keeps the route and refuses to install it, so a page that renders only installed paths shows nothing at all. I have seen a team spend a day chasing an upstream provider when the real change was a summarisation boundary in their own IGP.

Dampening is the other one that looks like an outage but is a policy decision. If dampening is enabled, a prefix that flaps a few times gets suppressed for a period that grows with each flap history. The prefix is reachable, the peer is up, and the router is deliberately not using it. The fix is a policy change, not a routing protocol fix, and it is worth knowing whether you have dampening enabled before you start debugging anything else.

One boundary: these codes are conventional shorthand, and the exact set differs by platform and software train. Reading a Junos table with a Cisco decoder ring is how you misdiagnose a route.

The order I actually work in

Start at the session, because a session problem makes every later question meaningless. Then move outward, from what your router knows to what it tells its neighbours. The commands below are illustrative Cisco-style shapes, not verified output, and the exact syntax varies by platform and software version.

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors 192.0.2.1 received-routes
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes
show ip route 203.0.113.0
show bgp ipv4 unicast dampening parameters

The session check is not just up or down. Look at uptime, the last reset reason, prefixes received against the configured maximum, and whether the session has been flapping. A maximum-prefix limit that tripped shuts the session down and produces exactly the symptoms of an upstream outage. Then ask whether the prefix is in the received set from the neighbour you expect. This is the step that distinguishes a local problem from someone else's problem, and the step a passive looking glass cannot do. If the prefix is not in the received set, you are done with your router: go and ask the neighbour, and be prepared to find out the prefix was withdrawn for a commercial or policy reason rather than a technical one.

If it was received, check acceptance. Look at the inbound policy and its counters, not just its text. A prefix-list that has grown a stale deny entry, or an AS-path filter matching a transit path that changed last Tuesday, will produce an empty table with no log line. Then check selection and installation: compare the path with its competitors, look for the RIB-failure marker, and confirm the next hop is resolvable in the forwarding table.

Then check what you advertise. A route that is correct locally and absent at the neighbour is an outbound policy problem, an aggregation problem or an iBGP design problem. If the neighbour is an iBGP peer and the route came from another iBGP peer, a route reflector is involved, and the reflector may be filtering. This is where I look first when a prefix is visible in one data centre and not another: not at the internet, but at the route reflector and its policy.

Communities and aggregation, and the checklist I run

Communities are the last thing I check, and I check them last because they are the least likely to be the cause and the most likely to send you down a rabbit hole. A community is a tag; it does not move a prefix. What moves a prefix is the policy that matches the tag. If the upstream attached NO_EXPORT to a summary, or if your own network uses a community scheme to mark customer, peer and transit routes, then an apparently healthy BGP table at the upstream can coexist with a prefix that never reaches you, because the upstream router is choosing not to advertise it. The well-known communities in RFC 1997, and large community attributes in RFC 8092, behave exactly as specified, and the semantics of every other community in your fabric are a local convention that exists only in your own runbook.

Aggregation deserves equal suspicion: a summary-only advertisement that no longer covers the prefix you think it covers produces a clean withdrawal with no obvious error.

What I run before I touch anything:

• Confirm the peer session state, uptime, last reset reason and prefix count against the maximum.
• Ask which vantage point the report came from, and get a second looking glass from a different AS before drawing a conclusion.
• Check the prefix in the received-routes view, not just the local table.
• Check acceptance against inbound policy counters, prefix limits and any route dampening.
• Check selection and installation, including next-hop recursion and the RIB-failure marker.
• Check what is advertised to each neighbour, including route-reflector policy for iBGP paths.
• Check whether aggregation or a summary-only change landed just before the report.
• Only then read communities, and read them as an explanation for policy, not as a cause in themselves.
• If the prefix is missing from the received set, stop debugging your own router and go and ask the neighbour.