How to check BGP routes and RPKI validity

When routes go wrong

The scenario is familiar to anyone who has run a public service: the site loads for you, the server is healthy, the certificate is valid — and customers in another country get nothing. Monitoring from your own office says up. Their traffic never arrives, because reachability is not a property of your server. It is a property of the announcements that carry your prefix across other people’s networks, and those announcements can change, be filtered, or be contradicted without anything on your machine changing at all. “The site is down” is sometimes a routing fact wearing a server costume.

Route failures come in three shapes worth telling apart. A hijack: another autonomous system announces your prefix — or a more-specific slice of it — and attracts traffic that was never theirs. A route leak: a network propagates routes it received to peers or providers it should not have sent them to, so traffic takes absurd detours or falls into a network that cannot deliver it. And the quiet one: an announcement withdrawn or filtered away by a config change, a peering dispute or an RPKI drop, so part of the internet simply has no path left. The fixes for the three are entirely different, which is why the first job is telling them apart — and that starts with looking at what is actually announced.

Start with the announcement

The first question is the plainest: is this prefix announced to the global table at all, and if so, by whom? The announcement’s last AS — the origin ASN — names the network claiming to hold the prefix, and the registry data behind it names the organisation that ASN belongs to. If the origin is your own ASN, or your provider’s, the announcement is at least claiming the right home. If it is a name you have never seen, you have learned something important in the first ten seconds.

The edge cases carry the information. A prefix with no origin at all is not being announced anywhere the collectors can see — a typo in the prefix, an announcement never made, or one withdrawn everywhere; check for a covering less-specific prefix before concluding anything, because traffic may still flow under the aggregate. Multiple origins for one prefix are not automatically sinister: anycast services and large CDNs originate the same prefix from many networks by design, and a prefix mid-transfer between providers can legitimately show two origins for a while. Multiple origins plus a holder you do not recognise, starting at a time you did not change anything, is the combination that deserves alarm.

Visibility and AS paths

A looking glass does not ask your router; it asks route collectors — the RIPE RIS collectors behind this site’s data peer with networks all over the world and record what those peers announce to them. Visibility is the count of collector peers that see your prefix at all. A healthy, long-standing prefix is typically seen by nearly all of them. A count in free fall — or one that was full yesterday and is a handful today — suggests an announcement being withdrawn, filtered, or seen only through a narrowing set of paths.

The AS path is the chain of networks an announcement travelled: read it from right to left, from the origin out through transit providers towards the collector’s peer. It tells you which upstreams carry the route and where your own provider sits in the chain — and when a leak happens, the path shows the network that should not be there, in the middle, forwarding traffic sideways. One reading habit to build: a repeated ASN in a path is usually deliberate prepending, a traffic-engineering signal, not a loop; and the shortest path is not always the one real traffic takes, because routing follows commercial policy, not geography.

Calibrate the instrument before trusting it. Collectors see the views of the networks that peer with them — a large, well-placed sample, but not every router on earth. A prefix can be invisible to the collectors yet reachable inside one provider that does not peer with RIS, and visible to collectors while a specific transit filters it further downstream. A looking glass result is evidence about the global table as seen from serious vantage points. It is not a photograph of every forwarding decision being made about your prefix right now.

RPKI in plain terms

RPKI is the internet’s attempt to make “I am allowed to announce this” a checkable claim instead of a shout. A prefix holder publishes a ROA — a Route Origin Authorisation, a signed object stating that a named ASN may originate that prefix, up to a stated maximum prefix length. Validators such as Routinator — the one behind this site’s check — fetch ROAs from the five regional registries’ trust anchors (APNIC, ARIN, LACNIC, RIPE NCC and AFRINIC) and test each announcement against them. A signed statement either covers your announcement or it does not; that is the whole mechanism.

Every announcement lands in one of three states. Valid: a ROA covers this prefix, this origin ASN and this length. Invalid: a ROA covers the prefix but the announcement breaks its terms — and the distinction inside invalid matters: invalid_asn means the wrong network is originating it, while invalid_length means the right network is announcing a more-specific prefix than the ROA permits. Unknown (often called not-found): no ROA covers the prefix at all, so there is nothing to check against.

Now the honesty. Invalid is evidence, not proof of a hijack. ROAs get misissued, go stale after a prefix transfer, or are written with a max length the operations team then forgets when they deaggregate — the wrong-ASN case deserves a fast phone call, but check your own paperwork before accusing anyone. And unknown usually just means nobody published a ROA; a large share of the world’s prefixes still have none, so unknown is a gap in the system, not a mark against the prefix. Invalid still has real teeth, though: many large networks now drop invalid announcements outright, so an invalid state can be the direct cause of the reachability hole you started with.

A five-step check routine

Rule out the simpler layers first — a new DNS record still spreading (check it with the DNS propagation checker) or a service port closed to the outside (check it with the port scanner) imitate routing failures perfectly. Then open the BGP lookup and work in order. Step one, the prefix: enter the IP or prefix and confirm the covering announcement that actually carries your traffic. Step two, the origin: read the origin ASN and holder — yours, your provider’s, or a stranger’s. Step three, visibility: how many collector peers see it, and does that count look like the prefix’s normal?

Step four, RPKI: valid, invalid (which kind?) or unknown — and if invalid_asn names a stranger, escalate before you finish the list. Step five, the AS paths: which upstreams carry the announcement, and is any network sitting in a path where it does not belong? Then write it down while it is in front of you: the prefix, the origin ASN and holder, the visibility count, the RPKI state, the paths you saw — and the time, in UTC. The tool’s data comes from RIPEstat and RIPE RIS and is cached for about an hour, so a screenshot without a timestamp is an anecdote; a note with one is evidence you can diff against the next check.

Limits worth stating

Three limits belong in any report this data feeds. Collector coverage is biased: RIS peers are numerous but not evenly spread — some regions and some kinds of network are far better represented than others, so a visibility count is a sample, not a census. Propagation takes minutes, not seconds: a legitimate change you just made may legitimately not be visible yet, and a withdrawn route can linger in collectors after real traffic has moved on; wait and re-check before declaring either a fix or a disaster. RPKI coverage is partial: with many prefixes still lacking ROAs, the validation layer can only judge the part of the table that participates in it.

And the limit that matters most in an argument: a clean result here does not prove what your own router’s table holds. Your sessions, your filters, your local preference can all make your corner of the internet disagree with the collectors’ — legitimately. Use the BGP lookup to establish what the world announces and sees; use your own router’s BGP table to establish what you are doing about it. An incident report that keeps those two claims separate is one nobody has to retract.

Frequently asked questions