How this tool works

Methodology & terminology

This looking-glass is built to be cited. Every result is a snapshot you can link to, and this page explains exactly how that snapshot is produced — so you can trust it, or check it yourself.

Where the data comes from

Paths come from RIPE RIS, the RIPE NCC's Routing Information Service. Instead of one router's view, a query aggregates what hundreds of public peers across dozens of route collectors are seeing, retrieved through the RIPEstat looking-glass. Every result states its source, the number of peers and collectors it rests on, and the UTC timestamp of the data.

A country vantage (for example Iran · RIS peers) is not a second looking glass. The same RIS answer is filtered to the peers whose AS is registered in that country. RIS has no collector in Iran; the Iranian view is the Iranian networks that multi-hop into a RIS collector (today typically AS49666 at RRC25). A prefix those networks do not carry will not appear from that vantage, even if the rest of the world sees it. In that case the lookup continues on the global table and the snapshot says so, rather than failing.

The red line: Most Observed AS-PATH

There is no single “best path” on the global internet. Each router picks its own according to local policy, and two routers inside the same network can disagree. So the red line here is not a best path. It is the Most Observed AS-PATH: the exact complete path that the largest number of peers actually reported. It is a real path present in the data, not a route stitched together from individually popular hops.

How paths are normalized

When a network repeats its own AS number to make a path look longer (AS prepending), the repeats are collapsed so the graph stays readable — but the prepend count is kept in the stored snapshot. Paths containing AS23456 (AS_TRANS), the placeholder older routers use in place of 32-bit AS numbers, are flagged rather than quietly dropped.

AS names

AS names come from RIPEstat. The graph shows a short organization name for readability; the full registered name, including the NIC handle where one exists, appears in the Evidence panel and is kept in the snapshot.

RPKI origin validation

Route Origin Validation is performed by the RIPE NCC RPKI Validator, which compares the observed origin AS against the prefix's published ROAs. Each snapshot records the exact validator URL it used, so you can open that route's verdict yourself rather than taking this page's word for it.

Four outcomes are distinguished, because they mean different things: valid — a ROA covers the prefix and authorises this origin; invalid (ASN) — a ROA covers it but names a different AS; invalid (length) — a ROA covers it but the announcement is more specific than the ROA's maximum length; and not found — no ROA covers the prefix at all, so validation reaches no verdict. That last case is reported separately from unknown, which means the check itself did not complete or more than one origin AS was seen. The snapshot also keeps the count of ROAs that matched, named another AS, or allowed only a shorter prefix.

Multiple origins (MOAS)

If more than one AS is seen originating the same prefix, the result is flagged MOAS. That happens legitimately with anycast, multi-homed networks, and migrations — and it is also the signature of a hijack. The tool reports the condition and leaves the judgement to you.

Nothing is hidden

When a hostname resolves to several addresses, or an AS announces many prefixes, all of them are listed; the tool never silently picks one. A network announcing thousands of prefixes gets a paged, filterable list rather than a truncated one, and the page states the total. Busy graphs omit the rarest edges for legibility, and when that happens the result says how many were left out and what the peer threshold was. The complete raw upstream response behind every snapshot is stored unchanged and is reachable at /api/v1/snapshot/{id}?view=raw.

IPv4 and IPv6

Both families are handled the same way, and every snapshot records which one it describes. Addresses are canonicalized before anything is queried, so 2606:4700:4700:0:0:0:0:1111 and 2606:4700:4700::1111 are one query, and host bits below the prefix length are cleared — ask about 8.8.8.8/24 and you get 8.8.8.0/24.

A prefix more specific than anything actually announced has no paths of its own. Rather than reporting nothing, the lookup falls back to the covering prefix the routing system really carries and records that substitution in the quality flags. This matters most for IPv6, where a /64 or a single host address is usually part of a much shorter routed allocation.

Freshness and caching

Upstream answers are cached for a short window — on the order of a minute for routing data, far longer for AS names, which change rarely. Repeating a query inside that window is served from disk, so it returns in milliseconds instead of seconds. Each snapshot carries the UTC data_timestamp of the routing data it was built from, so a cached answer is never ambiguous about how old it is.

Limits worth knowing

RIS data is near-real-time, with a short processing delay. Low-visibility announcements that few peers see may not appear at all. A looking-glass shows the control plane — what is announced — which is not always the same as the data plane, where the packets actually go.

A single lookup resolves names for a bounded number of AS numbers and draws a bounded number of edges; both limits are stated in the result when they bite. Lookups are rate limited per address because each one costs an upstream request, while reading a stored snapshot is free and unlimited.

Data: RIPE RIS, retrieved through RIPEstat.