Documentation

How drift is calculated

Data sources

Peer Drift ingests two independently-run public datasets, each with a different methodology and update cadence:

• CAIDA's AS Relationships dataset (monthly) — inferred from BGP data collected at many vantage points worldwide, using an algorithm (Luckie et al., IMC 2013) that doesn't assume valley-free paths but instead relies on structural assumptions about the internet's hierarchy. This is the more authoritative of the two sources.
• RouteViews RIB archives (daily, two collectors: route-views2 for IPv4, route-views6 for IPv6) — Peer Drift parses the full routing table dump from a single BGP vantage point each day and infers relationships using a valley-free path heuristic. This gives daily granularity CAIDA can't match, at the cost of being a single vantage point's view rather than a validated multi-source consensus.

Every relationship change shown on this site is tagged with which of these two sources it came from, and the drift feed explicitly calls out RouteViews-derived changes as noisier than CAIDA's.

Change detection

Each new snapshot is diffed against the most recent prior snapshot from the same source and collector — CAIDA is never diffed against RouteViews, and route-views2 is never diffed against route-views6, since each pairing sees a structurally different slice of the internet and comparing across them would just measure coverage differences, not real change. Every added or removed relationship is stored permanently, not overwritten.

Raw churn counts are not very informative by themselves — 50 relationship changes means something very different for a 20-relationship regional network than for a transit provider with thousands. Peer Drift flags an AS as having "significant" churn based on added and removedrelationships separately, not one blended ratio: added churn needs to reach 30% of its prior relationship count (with at least 3 individual changes); removed churn needs a higher bar, 50% (with at least 5 changes). That asymmetry isn't arbitrary — checked directly against real confirmed-vs-reversed outcomes, additions hold up as real roughly 74% of the time, while removals hold up only 60% of the time (a single vantage point losing a route is genuinely ambiguous between a real relationship ending and its best-path selection just shifting elsewhere), so removals need stronger evidence before being called significant. Peer Drift separately tracks how many consecutive transitions in a row an AS has been flagged — a network flagged every single day is more likely a persistent classification quirk than a fresh event.

Peer Drift also detects reclassification: when the same counterparty AS appears as both an addition and a removal in the same transition (e.g. a peer that became a customer), that isn't a real gain and a real loss — it's one event, and is shown that way rather than as two contradictory-looking rows.

Persistence window & confirmation

RouteViews is a single vantage point run through a heuristic classifier, so a real share of what it reports on any given day is transient — the same relationship added one day and removed a day or two later, never a lasting change. Rather than trying to algorithmically detect which individual changes are real (a problem CAIDA's own research has found no reliable automated solution to, even with hundreds of vantage points), Peer Drift applies the one mitigation that research supports: a persistence window. A RouteViews or RIPE RIS change is marked confirmed once it has held for three consecutive snapshots of its own collector without reversing; until then (or if it reverses and never gets the chance), it stays provisional. CAIDA changes are confirmed on arrival — CAIDA's own pipeline already does multi-vantage-point validation before Peer Drift ever sees the data, so re-checking it here would add delay for no benefit.

Provisional changes are never hidden — every changed row on the History tab and drift feed carries a visible badge stating which it is — but they're excluded from significance and streak scoring, so a run of flapping doesn't itself get flagged as an "unusually high churn" event. Each AS page also has an Unstable filter alongside New/Left, listing counterparties that have changed at least twice recently — a direct, visible signal for exactly the kind of relationship this section describes, without waiting on the persistence window to resolve one way or the other.

ASPA cross-check

Where CAIDA and RouteViews both infer relationships from observed BGP behavior, ASPA (Autonomous System Provider Authorization) is a network cryptographically declaringits own upstream providers, via the same RPKI infrastructure ROAs use. On an AS page's Providers tab, a provider relationship gets a green ASPAbadge when that provider also appears in the AS's own signed ASPA record — independent corroboration, not just an inference. Adoption is still small (roughly 2% of tracked ASNs publish any ASPA record at all), so the badge only appears where real ASPA data exists; its absence isn't a negative signal, the same convention as RPKI's unknown status above.

Checked directly against Peer Drift's own data (2026-07-22, 1,817 ASNs with both CAIDA and ASPA data): CAIDA's inferred providers exactly match an AS's ASPA-declared set 44.2% of the time, and share at least one provider 98.6% of the time. That's real, first-party evidence against an unverified secondary claim (a paywalled 2025 conference poster reporting a much lower 17.7% match on a much smaller sample) that had previously been the only available data point on this question — not a precise replication of that paper's methodology, which was never publicly readable, but multiple independently-computed comparison metrics on real data instead.

Customer cone

Every AS page shows a customer cone size: the count of ASes transitively reachable from that AS through customer relationships (its customers, their customers, and so on). This is a standard measure of an AS's reach in the provider hierarchy, computed directly from CAIDA's relationship data rather than any proprietary ranking — it will not be identical to CAIDA's own ASRank, which uses additional signals, but reflects the same underlying concept.

Related ASNs & topology graph

Every AS page has separate Providers, Customers, and Peers tabs, plus a combined Related tab that merges all three into one searchable table (deduped by ASN if one somehow appears in more than one role). Rows carry a role badge and, where recognized, a small cloud-icon badge naming the provider for major cloud/CDN networks — a small hand-curated list of primary backbone ASNs (Google, AWS, Azure, Cloudflare, Akamai, and others), not an exhaustive or automatically-updated set, since most of these providers don't publish a machine-readable list of every ASN they operate.

The Graph tab renders the same relationship data as a fixed three-tier diagram — providers above, peers in their own row, customers below, this ASN centered — capped to 12 nodes per tier ("+N more" beyond that, since large transit networks can have hundreds of relationships). It's a fixed layout, not a drag/rearrange graph editor.

Prefixes, MOAS & RPKI

The Prefixes tab lists every IP prefix an ASN originated in the latest RouteViews snapshot for each collector (route-views2 for IPv4, route-views6 for IPv6), with a filter for text search, address family, and total counts including the /24-equivalent IPv4 address-space rollup described under Top ASNs above, plus the average AS_PATH hop count across those prefixes (split All/IPv4/IPv6). That average is a rough, single-vantage-point read — AS-path prepending inflates it, and the first hop is the collector's own peer, not necessarily distance from the ASN itself — not an authoritative topology measure.

Two validity checks run against that prefix list, both computed at query time against daily-refreshed reference data, and both flagged, not adjudicated — Peer Drift shows what it observed, not a verdict on whether it's malicious:

• MOAS (Multiple Origin AS) — another ASN also originated the same prefix in the same snapshot. Can be legitimate (anycast, multihoming) or a misconfiguration/ hijack. The header count is a clickable filter down to just the conflicting prefixes.
• RPKI ROV (Route Origin Validation) — each prefix/origin-ASN pair is checked against the current set of published RPKI ROAs (Route Origin Authorizations), sourced from Cloudflare's public aggregate export of all five RIR trust anchors and reloaded daily. Prefixes come back valid (an authorizing ROA exists), invalid (a covering ROA exists but doesn't authorize this origin or allows a shorter max length), or unknown (no covering ROA published at all — the default for a large share of the global routing table, so it isn't badged on its own to avoid noise). The invalid count is also a clickable header filter. A summary figure — the share of allof an ASN's announced prefixes that are RPKI-valid — sits alongside these counts; unknown prefixes count against that percentage the same as invalid ones do, since it answers "how RPKI-covered is this network," not just "of the ROAs that exist, how many are correct."

RPKI validation here is checked against the most recent daily RIB snapshot, not against BGP announcements as they happen — see Architecture for why that's a structural property of the whole pipeline, not specific to this feature.

Prefix Path

Every prefix row on the Prefixes tab links to a dedicated /prefix page showing the raw AS_PATH(s) currently recorded for that prefix — how a single RouteViews/RIPE RIS vantage point routes to reach it, rendered as a connected chain of hops. Usually one path; a real MOAS conflict shows one path per origin, each labeled separately, since which origin is legitimate is exactly the question a conflict leaves open.

Two display modes over the same path: Full path shows every recorded hop; Condensed keeps only the two intermediate hops with the largest customer cone (plus the first hop and the origin, always). That's a deliberate substitute for a hand-curated "Tier 1 backbone" list — cone size is already computed for every ASN, so reusing it avoids maintaining a second, inherently subjective classification the way the cloud-provider tagging elsewhere on this site has to.

AS_PATH is only ever captured on the current latest snapshotper collector, not kept historically — so this shows the path as observed right now, never a history of how it changed. RIPE RIS doesn't currently produce path data at all (its most recent ingest predates path capture). This is a real capability gap relative to a live, multi-vantage-point system, not a bug — the same structural ceiling documented under Architecture applies here too.

Whois

The Whois tab is a live RDAP (Registration Data Access Protocol) lookup, not ingested/stored data — it queries a universal redirector that resolves to whichever RIR (ARIN, RIPE, APNIC, LACNIC, or AFRINIC) is actually authoritative for a given ASN, so no separate per-registry integration is needed. Shows AS handle, name, status, registration/update dates, source RIR, registrant organization and address, and contact handles. Raw contact emails are deliberately never shown, even though RDAP responses do include them — only handle/name/role. Results are cached for 24 hours; a slow or unreachable RDAP server degrades to "WHOIS data unavailable" rather than breaking the page.

Top ASNs

The Top ASNs page ranks the top 100 ASNs globally by one of three metrics: customer cone size, announced IPv4 address space, or announced IPv6 address space. Each metric is computed from whichever snapshot it actually depends on — cone from the latest CAIDA snapshot, address space from the latest RouteViews prefix snapshot — so switching metrics can shift which day's data is being ranked, not just the sort order. IPv4/IPv6 space is shown in /24- and /48-equivalent blocks respectively, the same normalization used on the Prefixes tab and the Weather Report's Pressure Trend, rather than a raw address count.

BGP Weather Report

The Weather Report is a daily, network-wide companion to the per-ASN drift feed above — a synoptic read on the whole routing table rather than a lookup for one AS. It's precomputed once a day by pipeline/build_weather_report.py (scheduled after the daily RouteViews ingest and confirm-deltas sweep) and stored as one row per day, so every past report stays browsable via the date picker rather than only ever showing "today." It deliberately does not reuse the significance/streak formula described above — an internal review found that formula doesn't separate real changes from noise on its current thresholds (see the flagged entry in this project's design log). Instead it relies on two different, independently-reasoned signals: raw statistical anomalies (labeled experimental) and confirmed-delta counts, the one signal that same review found actually trustworthy.

Condition banner

A one-word read on the day: Fair or Unsettled. This is a coarse heuristic, not a forecast — it flips to Unsettled if either the trailing week contains a confirmed-churn day flagged anomalous (see Fronts moving through, below) or the ASN count moved 2% or more across the trend window. Most days are Fair even when there's plenty of ASN-level activity — the point is to distinguish ordinary background churn from something genuinely unusual at the network-wide level.

Pressure trend

Independently-scaled step charts — announcing ASN count, IPv4/IPv6 prefix counts, and IPv4/IPv6 announced address space (in /24 and /48 equivalents) — over the trailing ~13 days. Split into separate charts rather than one shared axis for the same reason an AS page's own trend chart is split by magnitude group: these differ by orders of magnitude, and a shared linear axis would flatten the smaller series next to the larger ones' swings. Rendered as step lines, not smoothed curves — every metric here is a discrete count that changes at a point in time, not a continuously varying quantity. The window is calendar-bounded (the trailing N days), not "the last N snapshot rows" — the RouteViews history has a real gap while the historical backfill catches up, and a row-count window would silently bridge across it into a misleadingly smooth-looking multi-month trend. Address-space totals exclude default-route entries (0.0.0.0/0, ::/0) — a single such entry is a routing construct, not a claim to the entire address space, and would otherwise dominate the sum — and still double-count overlapping/more-specific prefixes across different ASes, so treat them as a trend indicator, not exact address accounting.

Fronts moving through

A diverging bar chart of confirmed relationship changes (added up, removed down) for each of the trailing 7 days — the most trustworthy churn signal the pipeline produces, since every bar only counts deltas that already survived the same persistence window described above. A day is automatically flagged and shown muted/greyed when its total is more than 3x the window's median — a generic outlier check, not a hardcoded date, so it catches the same shape again if a future sweep run ever needs to clear a backlog (as the very first production run of confirm_deltas did).

Storm watch

Ranks ASNs by how far their latest announced IPv4 address space deviates (in standard deviations, a z-score) from their own trailing 60-day average. This is explicitly labeled experimental in the UI — it's a fresh statistical read, not a validated signal like confirmed churn, and it needs at least 10 snapshots of history and a minimum absolute change (≥200 addresses) before an ASN is even eligible, to keep sub-/24 noise out. Both the z-score and the raw mean/latest values are always shown side by side, since a loud z-score against a thin historical baseline (a handful of addresses) can look more dramatic than it actually is — the two numbers together let you judge that yourself rather than trusting the ranking alone.

Most active systems

A leaderboard of the ASNs appearing most often on either side of a confirmed relationship change over the trailing 7 days, with a diverging mini-bar (adds right, removes left of center) and a net figure (adds minus removes). This surfaces which networks are actually driving the week's confirmed churn, separate from whether the network-wide picture above counts as Fair or Unsettled.

RPKI Anomalies

The Anomalies page is a network-wide, precomputed daily scan for prefixes with a MOAS conflict (2+ distinct origin ASNs announcing the same prefix in the currently-live RouteViews/RIPE RIS snapshots) where at least one origin is RPKI- invalid— a much stronger, more actionable signal than plain MOAS alone, most of which is benign multihoming or anycast. Same underlying logic as the per-ASN MOAS/RPKI checks on the Prefixes tab, but run network-wide instead of scoped to one ASN — confirmed against production that the live cross-reference takes ~17-20 seconds at that scope, far too slow for a page load, so it's precomputed once daily by pipeline/build_moas_rpki_conflicts.py and read as a flat table at request time — same architecture as the Weather Report.

Like every RPKI/MOAS check on this site, this is flagged, not adjudicated— a real conflict can mean legitimate multihoming, a misconfiguration, or an actual hijack, and Peer Drift doesn't distinguish which. One field from Cloudflare Radar's equivalent table is deliberately missing: Visibility%(the share of vantage points observing a given origin) needs concurrent multi-vantage- point data from many simultaneous collectors — Peer Drift's architecture, a handful of once-daily RIB snapshots, structurally can't produce that.

Architecture

Peer Drift is a batch pipeline, not a live system — every source below is fetched, parsed, and written to Postgres by a scheduled job, never streamed or queried on demand from an external provider. Nothing is held in memory between runs.

Data flow

Schedule

Each box below is a separate cron-triggered GitHub Actions run, not a job in one shared run — there's no way to enforce that routeviews finishes before weather_report starts, only a scheduling convention (staggered minute offsets). When that assumption broke for real (a same-day ordering miss silently dropped a Weather Report), the fix was making weather_report recompute the last 3 days every run instead of trusting the order — self-healing rather than strictly ordered.

Query model

Postgres is the only thing ever queried by the site — no in-memory route table, no cache layer. Cheap, bounded lookups (one ASN, a fixed top-N) query Postgres directly at request time. Anything requiring a full-table scan or cross-reference (the Weather Report's storm-watch anomaly scan, MOAS-vs-RPKI cross-referencing) is computed once a day by a pipeline job and read as a flat precomputed row — never computed live inside a request.

Retention

Every historical relationship change is permanent — deltas are never deleted, regardless of what happens to the raw snapshot data they were computed from. The raw snapshots themselves are pruned per collector to just the current and prior one, since only the prior is ever needed again (to diff the next snapshot against). Freshly-loaded snapshots get a 7-day grace period before becoming eligible for pruning, specifically so a historical backfill still in progress elsewhere in the same chain isn't deleted out from under it — added after a real incident where that race condition produced ~975K phantom delta rows in April 2026's backfilled data (found, fixed, and purged 2026-07-23; full trace in docs/design-considerations.md).

This sets a structural freshness floor of about 24 hours, regardless of what gets built on top — there is currently no path to sub-daily updates without a fundamentally different (streaming) architecture. For the full write-up, including a comparison against a real-time streaming BGP architecture, see docs/architecture.md in the repository.

Glossary

ASN (Autonomous System Number)

A unique number identifying a network that operates under one routing policy — an ISP, cloud provider, university, content delivery network, etc.

ASPA

Autonomous System Provider Authorization — a cryptographically signed RPKI record where an AS declares its actual upstream providers, independent of what's observable in BGP.

c2p (customer-to-provider)

A relationship where one AS pays another for transit — the customer gains reachability to everything the provider (and the provider's own providers) can reach.

Collector

The specific BGP data-collection point a RouteViews snapshot came from (e.g. route-views2, route-views6). Distinct from source, since RouteViews runs multiple independent collectors.

Confirmed / Provisional

A RouteViews or RIPE RIS change is confirmed once it has held for 3 consecutive snapshots of its own collector without reversing; until then, or if it reverses first, it's provisional. CAIDA changes are confirmed on arrival. See "Persistence window & confirmation."

Customer cone

The set of ASes transitively reachable from a given AS via customer relationships — its customers, their customers, and so on.

Delta

A single recorded change (one added or removed relationship) between two consecutive snapshots from the same source and collector.

Drift

This project's term for relationship change over time — the diff between snapshots, not a snapshot itself.

MOAS (Multiple Origin AS)

When more than one ASN originates the same prefix in the same snapshot. Peer Drift flags this on the Prefixes tab — it doesn't try to determine which origin is legitimate; MOAS can be benign (anycast, multihoming) or a sign of misconfiguration/hijack.

p2p (peer-to-peer)

A relationship where two ASes exchange traffic directly, typically without either paying the other.

Persistence window

The 3-snapshot period a RouteViews or RIPE RIS change must hold without reversing before it's marked confirmed. Calibrated against this project's own delta history: most reversals happen within 2 days.

Reclassification

When the same counterparty AS's relationship type flips between two consecutive snapshots (e.g. a peer becomes a customer) — shown as one event, not a contradictory add-and-remove pair.

RIB (Routing Information Base)

The full routing table a BGP router holds at a point in time. RouteViews publishes a daily RIB dump per collector, which Peer Drift parses to infer relationships.

ROA (Route Origin Authorization)

A cryptographically signed RPKI record where a prefix holder authorizes a specific ASN (and a maximum prefix length) to originate that prefix. Peer Drift ingests the public set of published ROAs daily to compute ROV status.

ROV (Route Origin Validation)

Checking an announced prefix/origin-ASN pair against published ROAs: valid (an authorizing ROA exists), invalid (a covering ROA exists but doesn't authorize this origin/length), or unknown (no covering ROA at all). Shown on the Prefixes tab — flagged, not adjudicated, since invalid can mean misconfiguration or a real hijack.

RPKI (Resource Public Key Infrastructure)

The certificate system tying IP prefixes and ASNs to their legitimate holders, underlying both ROAs and ASPAs.

Significance

Peer Drift's flag for churn that's large relative to an AS's prior size (at least 30%) and involves enough absolute changes (at least 3) to likely be a real event rather than routine noise.

Snapshot

One point-in-time capture of relationships (and, for RIB-derived sources, prefixes) for a given source and collector.

Source

Which dataset a snapshot came from: CAIDA or RouteViews. Never diffed against each other — see How drift is calculated.

Storm watch

The Weather Report's ranking of ASNs by z-score deviation in announced IPv4 address space from their own 60-day baseline. Experimental — distinct from, and not based on, the significance/streak formula.

Streak

How many consecutive transitions in a row an AS has been flagged significant — a high streak suggests a persistent classification quirk rather than a fresh event.

Unstable

A per-AS-page filter for counterparties that have changed at least twice in the recently fetched history — a direct "this relationship keeps flip-flopping" signal, independent of whether either individual change is confirmed yet.

Vantage point

The location/AS a BGP data collector observes routes from. RouteViews' single-vantage view differs structurally from CAIDA's multi-vantage synthesis.

Valley-free path

A BGP path shape assumption used in relationship inference (uphill through providers, across at most one peer link, downhill through customers). RouteViews' heuristic relies on this; CAIDA's algorithm deliberately does not.

Weather Report

A daily, network-wide digest (condition, pressure trend, confirmed-churn fronts, storm watch, most active systems) computed once a day and browsable by date, distinct from the per-ASN drift feed.

Z-score

How many standard deviations a value sits from a baseline average. Storm watch uses this to flag an ASN's address-space change as unusual relative to its own recent history — not an absolute size threshold.

Data sources & attribution

Peer Drift is built entirely on freely available public datasets. Per each provider's terms, this data is used for research and analysis, not resold or redistributed in raw form.

Both CAIDA datasets are governed by CAIDA's Acceptable Use Agreement. RouteViews data is licensed under CC BY 4.0. RPKI ROA data and RDAP responses are each redistributed by their own registries under standard public-registry terms — no separate license is layered on top by Peer Drift. ASPA data via Cloudflare Radar is licensed CC BY-NC 4.0 — non-commercial use only, the same open licensing question this project already tracks for CAIDA/PeeringDB, not a new one.

API reference

Seven read-only JSON endpoints, no API key required.

• Rate limit: 60 requests/minute per IP (sliding window). Over the limit returns 429 with a Retry-After header.
• Format: all responses are JSON, wrapped in a top-level data key where the endpoint returns a single resource.
• Errors: non-2xx responses are { error: string }.

$ curl https://peerdrift.com/api/asn/15169

{
  "data": {
    "asn": 15169,
    "name": "Google LLC",
    "country": "US",
    "providers": [{ "asn": 3356, "name": "Level 3 Parent, LLC" }],
    "customers": [{ "asn": 36040, "name": "Google LLC" }],
    "peers": [{ "asn": 2914, "name": "NTT America, Inc." }]
  },
  "snapshot_date": "2026-06-01"
}

$ curl https://peerdrift.com/api/asn/15169/history

{
  "data": {
    "asn": 15169,
    "name": "Google LLC",
    "country": "US",
    "deltas": [
      {
        "asn": 31027,
        "name": "GlobalConnect A/S",
        "relationship": "c2p",
        "role": "customer",
        "change": "added",
        "snapshot_date": "2026-07-03",
        "previous_snapshot_date": "2026-07-02"
      }
    ]
  }
}

$ curl -X POST https://peerdrift.com/api/asn/batch \
    -H "Content-Type: application/json" \
    -d '{"asns": [15169, 16509]}'

{
  "asns": [15169, 16509],
  "details": {
    "15169": { "name": "Google LLC", "country": "US" },
    "16509": { "name": "Amazon.com, Inc.", "country": "US" }
  },
  "truncated": false,
  "maxBatch": 500
}

$ curl "https://peerdrift.com/api/search?q=google"

{
  "results": [
    { "asn": 15169, "name": "Google LLC", "country": "US" }
  ]
}

$ curl https://peerdrift.com/api/asn/15169/prefixes

{
  "data": {
    "asn": 15169,
    "name": "Google LLC",
    "country": "US",
    "snapshot_date": "2026-07-18",
    "prefixes": [
      {
        "prefix": "8.8.8.0/24",
        "af": 4,
        "moas_other_asns": null,
        "rov_status": "valid",
        "as_path_length": 4
      }
    ]
  }
}

$ curl "https://peerdrift.com/api/top?metric=ipv4&limit=10"

{
  "metric": "ipv4",
  "results": [
    { "asn": 15169, "name": "Google LLC", "country": "US", "value": 45871104 }
  ]
}

$ curl https://peerdrift.com/api/weather

{
  "data": {
    "report_date": "2026-07-19",
    "generated_at": "2026-07-19T11:00:18Z",
    "trend": { "points": [ /* ... */ ] },
    "churn": { "days": [ /* ... */ ] },
    "top_churn": [ /* ... */ ],
    "storms": [ /* ... */ ],
    "headline": { "condition": "fair", /* ... */ }
  }
}