How to Read a BGP Looking Glass: AS Paths, Next Hops, and RPKI Explained

A BGP looking glass is one of the most useful — and most misread — tools in network operations. It lets you see how the internet routes to a given prefix from a vantage point that isn’t your own. When a customer says “your site is slow from my office” or you suspect someone is announcing your address space, a looking glass is where you start.

But the output is dense, and a lot of engineers learn to skim it without really understanding what each field means. This post walks through every column of a typical looking glass result, explains how to read an AS path (which trips up more people than you’d expect), and shows how to turn that information into an actual diagnosis.

You can follow along with the BGP Looking Glass tool — it pulls live paths from route collectors in the US and annotates them with origin, RPKI status, and ARIN registration data.

What a looking glass actually shows you

First, an important distinction: a looking glass does not show your routing table. It shows the routing table of a route collector — a router (or set of routers) that peers with many networks purely to observe and record what they advertise. The most widely used public collectors are run by RIPE RIS and Oregon RouteViews.

That means every result you see is answering the question: “From this collector’s position in the internet, how would traffic reach this prefix?” Change the collector, and you change the vantage point — which is exactly why the same prefix can show different paths from different locations.

Here’s a representative result for one of Cloudflare’s prefixes, the kind of output you’d get from a collector in New York:

Prefix:     104.16.0.0/13
Origin AS:  AS13335 (Cloudflare, Inc.)
RPKI:       valid
Collector:  rrc11 — New York (NYIIX)

Peer AS    AS Path            Next Hop
AS3356     3356 13335         4.68.x.x
AS174      174 13335          38.x.x.x
AS6939     6939 13335         216.66.x.x

Three peers, three slightly different paths, all converging on the same origin. Let’s take it apart.

Reading the AS path (right to left)

The AS path is the heart of a BGP route. It’s the list of autonomous systems a route has traversed, and the single most important thing to know is this: you read it right to left.

• The rightmost ASN is the origin — the network that first announced the prefix into BGP. In the example above, that’s 13335 (Cloudflare).
• The leftmost ASN is the network closest to the observer — the collector’s direct peer.
• Everything in between is the chain of networks the route passed through, in order.

The reason it reads this way is mechanical. When a network propagates a route to a neighbor, it prepends its own ASN to the front of the path. So the path grows leftward as the route travels outward from its origin. The leftmost AS is therefore the most recent hop; the rightmost is where the journey began.

In 3356 13335, the route originated at Cloudflare (13335), was handed to Lumen (3356), and Lumen advertised it to the collector. Read it as “to reach this prefix, go through 3356, then 13335.”

AS path length and why it matters

BGP uses AS path length as a tiebreaker when selecting the best route — after local preference, which is the operator’s own policy knob and almost always wins first. All else being equal, a shorter AS path is preferred. This is why path length is a rough proxy for “closeness” in BGP, though it’s a topological measure, not a latency one. A three-AS path can easily be faster than a two-AS path depending on where those networks actually interconnect.

AS path prepending

If you see the same ASN repeated, like 3356 3356 3356 13335, that’s prepending — the origin or an upstream deliberately padding the path to make it look longer and therefore less preferred. It’s the most common form of inbound traffic engineering: a multihomed network prepends on its backup link so the internet prefers the primary. When you see prepending, you’re looking at someone’s intentional policy, not an accident.

Loop prevention

The AS path is also how BGP prevents loops: if a router receives a route whose AS path already contains its own ASN, it rejects it. This is worth remembering when you’re debugging why a route isn’t showing up where you expect — a downstream that’s also a peer somewhere else may be dropping it.

The next hop

The next hop is the IP address traffic should be forwarded to in order to follow this route. In looking glass output it’s the address of the peer that advertised the route to the collector. On your own routers the next hop matters enormously for forwarding (and for the next-hop-self configuration on iBGP), but in a looking glass it’s mostly useful for confirming which interconnect a route came in on — and for spotting when a peer is handing you a next hop you can’t actually reach.

The origin AS — and when there’s more than one

The origin AS is the network responsible for the prefix. Normally there’s exactly one. When you see a prefix originated by more than one AS, that’s a MOAS (Multiple Origin AS) condition, and it deserves a closer look.

MOAS is sometimes completely legitimate:

• Anycast services intentionally announce the same prefix from multiple ASNs in different locations.
• A network migrating address space between ASNs may briefly originate from both.
• Some multihoming arrangements legitimately produce multiple origins.

But MOAS is also the signature of a route hijack — someone announcing address space that isn’t theirs, either by mistake (a fat-fingered static route redistributed into BGP) or maliciously. Two of the most instructive real-world cases are the Pakistan Telecom / YouTube hijack and the MyEtherWallet / Route 53 hijack — both started as anomalous origins visible in exactly this kind of data.

The way you tell legitimate MOAS from a hijack is the next field.

RPKI status: valid, invalid, not found

RPKI (Resource Public Key Infrastructure) cryptographically binds a prefix to the AS that’s authorized to originate it, via a signed object called a ROA (Route Origin Authorization). When a looking glass shows an RPKI status, it’s comparing the observed announcement against published ROAs:

• Valid — the announcement matches a ROA. The origin AS is authorized and the prefix length is within the ROA’s maxLength. This is what you want to see.
• Invalid — the announcement conflicts with a ROA. Either the origin AS is wrong, or the prefix is more specific than the ROA allows. Networks that enforce Route Origin Validation (ROV) will drop these routes.
• Not found (or unknown) — no ROA covers this prefix. The route isn’t cryptographically vouched for, but it isn’t rejected either. A large share of the table is still in this state.

An RPKI-invalid route is the strongest signal that something is wrong. If you’re investigating a suspected hijack and the rogue origin shows invalid, that’s close to a smoking gun. For the full picture of how RPKI is built and deployed, see Securing BGP with RPKI.

Why different collectors disagree

This is the part that confuses people new to looking glasses: query the same prefix from a collector in New York and one in Frankfurt, and you’ll often get different AS paths. That’s not an error — it’s the entire point.

Each collector sits in a different part of the internet and peers with different networks, so each sees its own best path. Comparing them tells you how reachability and routing policy differ by geography:

• If a prefix looks fine from three US collectors but is missing from a European one, you may have a propagation problem or a regional policy issue.
• If one location takes a wildly longer path than the rest, you’re probably seeing suboptimal routing worth raising with an upstream.
• If only some vantage points see a suspicious origin, the hijack (or leak) may be localized to certain networks rather than global.

When a customer reports a problem “from their location,” picking a collector near them is how you reproduce what they’re seeing instead of what you see.

Putting it together: a troubleshooting workflow

Here’s how the fields combine in practice when you’re actually diagnosing something:

1. Is the prefix even there? If the looking glass returns nothing, the prefix isn’t being announced or isn’t reaching that vantage point. Start with propagation.
2. Is the origin correct? Confirm the rightmost ASN is your AS (or the one you expect). An unexpected origin is a MOAS event — investigate immediately.
3. What does RPKI say? Valid is reassuring. Invalid on your own prefix means your ROA and your announcement disagree — fix the ROA or the announcement. Invalid on someone else’s origin of your space is a likely hijack.
4. Is the path sane? Compare path length and the transit ASNs across collectors. Unexpected prepending, a surprise transit provider, or a much longer path from one region points to a policy or engineering issue.
5. Check the next hop and peer to confirm which interconnect the route is arriving on.

You can run steps 2 through 4 directly in the BGP Looking Glass: enter a prefix or IP, pick a US source location, and it shows the origin, per-peer AS paths, next hops, RPKI status, and ARIN registration data side by side.

Related tools

• BGP Looking Glass — live AS paths from US RIS collectors, with origin, RPKI, and ARIN data.
• BGP Route Lookup — origin AS, announced prefixes, and RPKI validity for any IP, prefix, or ASN.
• BGP Communities Decoder — translate the community tags that control much of the routing policy behind these paths.
• AS-SET Resolver — expand an AS-SET into its member ASNs to see what a provider’s filters should accept.
• My Network Info — see your own public IP, origin AS, prefix, and RPKI status.

If you’re newer to this, Autonomous System Numbers Explained covers what an AS is and how ASNs work before you go deeper into reading paths.