← ROOTBEER

Unexpected R&E Paths Explorer

Networks whose LPP probes answered over R&E paths
How to read this page

The local-preference probe (LPP) tests networks across the whole internet. Listed here are origins whose prefixes are not seen in the R&E routing tables, yet whose probe responses returned over the R&E path — or with equal local preference to it — a sign that R&E routes may be reaching networks beyond the R&E ecosystem. These are indications, not verdicts. Expand an origin AS to see its prefixes, the R&E ASes whose known routes intersect them, and (fetched on demand) the probed addresses with their PTR records.

What gets listed

  • Two prefix filters are on by default. "Only prefixes where the majority of replies use R&E" keeps a prefix when strictly more than half of its probed targets returned over R&E (LPP classes re or equal-localpref — 3 of 5 passes, 2 of 4 does not). "Only prefixes with two or more replies" keeps a prefix with at least two probe responses. An origin stays listed while at least one of its prefixes passes every active filter, and its expanded view shows only the passing prefixes (with a count of the hidden ones).
  • Uncheck both filters to browse the whole snapshot instead. There the bar is much lower: a prefix is included when a single probed address inside it answered with the reply returning over the R&E path while not being covered by any prefix in that day's R&E routing tables — no minimum number of targets, no percentage — and an origin is included with at least one such prefix. (Origin AS11537, an artifact of the measurement infrastructure itself, is always excluded. AS16509, Amazon, is treated as not in R&E by this explorer alone — it is never listed as an intersecting R&E AS nor badged as an R&E origin.)
  • Once a prefix is in the snapshot, all of that run's probe results for its addresses are attached — including addresses that answered over the commodity path — so listed rows can show well under 100% over R&E. Addresses covered by a more-specific prefix that is in the R&E tables are left out.

The origins table

AS
The AS originating the listed prefixes in the global routing table. Click to expand the detail view.
Name / holder
The AS's name and holder organization (CAIDA AS-organizations data captured in the snapshot).
In R&E
A badge means the AS itself appears in the R&E routing tables as the origin of other prefixes — the prefixes listed here are still outside those tables. "—" means the AS is entirely absent from the R&E tables.
Prefixes
How many of the origin's prefixes are in this run's snapshot (whether or not they pass the prefix filters).
Targets
Probed addresses with results across those prefixes.
% over R&E
The share of those targets whose LPP class was re or equal-localpref (hover for the raw counts; red at 50% or more). Unclassifiable targets stay in the denominator, so the figure is conservative.
R&E links
How many R&E ASes are direct BGP neighbors of the origin in CAIDA's AS-relationship data (hover for the provider / peer / customer breakdown). These are the candidate junctions through which R&E routes could be reaching the origin; zero means no known adjacency — the path indication stands, but there is nothing to graph.

Click a column header to make it the primary sort (click again to flip its direction); the columns you sorted before stay behind it as tie-breakers. Shift+click a header to add it as the last tie-breaker, or to flip a tie-breaker in place. Each sorted header shows its priority number. Default: In R&E first, then most prefixes first. The sort order is kept in the page URL (#sort=), so a copied link reproduces it. The search box matches AS number, AS name, AS holder, prefix, and — once resolved — each prefix's registered holder. The snapshot picker holds one run per day ("Latest" by default); the chosen date and any expanded AS persist in the page URL, so links can be shared.

The expanded origin view

Expanding a row fetches that one AS's detail on demand (a rate-limited endpoint — the only way individual probed addresses are ever served). It shows:

  • Intersecting R&E ASes — chips for the R&E networks that are BGP neighbors of the origin, colored by CAIDA relationship: green = provider of origin, blue = peer, red = customer of origin. Hover a chip for the holder organization.
  • "View topology graph →" — shown when at least one R&E AS intersects the origin and it has a majority prefix (the population the RE Topology Report graphs, regardless of the filters here). It opens that report's Unexpected R&E paths graph, which always uses its own latest snapshot — even when an older run is being browsed here.
  • One card per prefix passing the active filters (a note counts the hidden ones) — the prefix with a v4/v6 chip; its registered holder from RIR whois/RDAP (fills in shortly after the page loads); a "% over R&E" chip; one chip per LPP class with its target count (red-tinted chips are the classes counted as over R&E); and a "majority" chip when the prefix passes the strict-majority rule.

Probed targets and LPP classes

"Show probed targets" on a prefix card reveals the per-address rows (already loaded — nothing new is fetched): the address that responded in this run, its PTR (reverse-DNS name as captured at snapshot time; often the quickest clue to what the address actually is), and its LPP result:

Class Over R&E? Meaning
re counted Replies to both the R&E-preferring and the commodity-preferring probes returned over R&E; the default-route probe gave no answer, so an explicit R&E preference can't be distinguished from a default route pointing at R&E.
equal-localpref counted R&E and commodity routes carry equal local preference, so AS-path length decides per prefix — each reply followed its probe's engineered path preference.
re-localpref — The network explicitly prefers R&E paths via BGP local preference (the default-route probe returned over commodity) — a deliberate arrangement rather than an accident.
re-default — All replies returned over R&E, most likely because the network follows a default route that points that way rather than an explicit preference.
commodity — Replies preferred the commodity path.
none — Too few probe replies to classify the address.
weird — The replies don't match any consistent routing policy.
unknown — The snapshot carries no classification for this address.

Every "% over R&E" figure on this page counts exactly the two classes marked above — the same rule the RE Topology Report applies.