Where can I get historical BGP routing data? Three decades, delivered as rows

"Where do I get it" is the wrong first question. Historical BGP routing data is not one archive, it is three different kinds of statement about the past, and they answer different questions.

Observation is what the routing system actually did. The RouteViews BGP Archive & API, run by the University of Oregon, holds terabytes of routing history recorded at roughly 20 collector vantage points peered with hundreds of networks at exchange points including AMS-IX, LINX, NAPAfrica, Equinix SG1/SYD1 and IX.br Sao Paulo, plus multi-hop sessions anchored in Oregon. Legacy archives reach back to the late 1990s, and a single well-connected view carries more than 900k IPv4 prefixes per peer.

Registration is what holders said they would do. The RIPE Database (WHOIS & Routing Registry) records route objects binding prefixes to origin ASNs across the RIPE region's 75 member countries, with object version history reaching the early 1990s.

A serious routing-history workflow uses all three. Datadory delivers them joined on one key.

Every sighting in the observation layer decomposes into the same small dictionary of fields, which is what makes three decades of it queryable at all:

• prefix - the address block observed in the routing table, e.g. 193.0.0.0/21
• origin_asn - the autonomous system that originated it, e.g. 3333
• as_path - the full hop-by-hop sequence the announcement travelled, e.g. 37497 3333
• communities - operator-tagged attributes attached in transit, e.g. 37497:4202
• rpki_state - the origin-validation verdict riding along: valid, invalid, or notfound
• peer and collector - which neighboring network at which exchange point saw it
• timestamp - when the sighting was captured

An archived row reads like this:

prefix          : 193.0.6.0/24          # resolved inside 193.0.0.0/21
origin_asn      : 3333                  # RIPE-NCC-AS
as_path         : 37497 3333
communities     : 37497:4202
rpki_state      : valid
peer_asn        : 37497                 collector : amsix.ams
captured        : 2026-08-11T17:35:57Z

That is the unit of evidence. Multiply it by hundreds of peers, twenty-odd vantage points and nearly thirty years, and you get the corpus - and the reason nobody sane keeps their own copy normalized. Request a sample and the first rows arrive already keyed on the prefixes or ASNs you name.

Depth depends entirely on which layer you are standing in, so check before building:

1. Archived observations - legacy RouteViews collectors reach the late 1990s, close to three decades of continuous routing-table history, and still the deepest public record in this industry slice.
2. Newer BMP-collector feeds - individual exchange points came online recently; one Amsterdam collector began recording in February 2024. Deep, but young.
3. Aggregated per-resource timelines - RIPEstat routing-history and related calls reach back years, and each documents its own coverage window rather than promising one fixed period, so the honest answer to "how far back" is per-call and written down.
4. Registration records - RIPE Database objects carry created and last-modified timestamps to the early 1990s, with per-object version history alongside.

Item four is where reconstruction projects go wrong. Registration history tells you who claimed a prefix and who was authorized to announce it - not what the wire actually carried. A hijack investigation needs both layers joined on prefix and origin ASN, which is exactly why the claim and the observation belong in one table rather than two teams' spreadsheets.

The observation layer ships two shapes of history, and picking wrong wastes weeks.

A table snapshot is complete state: everything the collector's peers held at one moment, refreshed on a fixed rhythm - roughly every two hours on classic vintages. Snapshots answer "what did the world believe prefix X's origin was on Tuesday afternoon" and give you clean before-and-after frames.

An announcement stream is causality at fifteen-minute resolution on the newer BMP-based collectors: every advertisement and withdrawal as it happened, with the AS path that carried it. Streams answer "who changed what, in which order, and through whom" - the difference between knowing a leak existed and being able to replay it announcement by announcement.

Forensic work wants both: the stream to establish sequence, the snapshots to prove what the rest of the internet held before and after. At full-table scale - 900k+ IPv4 prefixes per peer - the pair is heavy raw material, which is why it arrives pre-normalized, not as a hobby of maintaining your own copy.

Bulk history and per-resource aggregation trade places depending on the question. When your job is "what happened to this prefix," the RIPEstat Data API wins on shape: one resource-keyed lookup returns announced prefixes, routing history, routing status, ASN neighbours, RPKI validation with history, WHOIS lineage and BGPlay-style path visualization, all normalized across all five registries. Sixty-plus named calls sit behind one interface, and each documents its own methodology and availability window, so you know the depth before you commit.

When your job is "give me three decades of the global table," aggregation loses: these are per-resource lookups, not a corpus. Training a model, studying AS-path evolution, or running outage forensics across thousands of prefixes needs the archived observation layer underneath.

Datadory delivers both as one feed - aggregate calls for interactive questions, the deep corpus for batch work - with the same field names on each side of the join.

Yes - this is the flagship use case, and it is a triangulation, not a single lookup.

Pull the affected prefix's archived paths to see what was observed and when the divergence began; read the registered route objects to establish what should have been announced; then subtract prior verdicts. The Spamhaus DROP Lists (Don't Route Or Peer) contribute roughly 1,700 hijacked or criminally leased IPv4 netblocks, about 40 IPv6 prefixes and 438 ASNs, each entry traceable to its underlying abuse-desk record - space that has already been adjudicated, drawn from all five registries plus independent allocations.

The comparison is only as good as the clocks. Observations, registrations and reputation rosters each move on their own rhythm, and a verdict assembled from mixed ages is guesswork. On a Datadory feed every layer carries its own observation timestamp and shares one join key, so "when did this prefix first lie" is a filter, not a forensics project. The full verdict workflow is worked through on BGP hijack detection data.

API, files, or your warehouse. Daily, weekly, or hourly.

Name the prefixes or ASNs you care about and we send real historical rows in the production schema - observed origins beside registered truth, RPKI state, roster flags and timestamps. Get a sample cut to your scope before anything else; the ongoing arrangement follows once the rows validate.

Five records cover the ground in the Internet Services & Infrastructure pool, and they overlap less than they first appear. One observes, one aggregates, one registers, one curates reputation and one evidences what actually operates inside the space.

1. Deep corpus - the RouteViews BGP Archive & API, quality 9/10: snapshots and streams from ~20 collectors, late 1990s onward.
2. Per-resource aggregation - the RIPEstat Data API, quality 9/10: 60+ calls over 35+ underlying datasets, all five registries.
3. Intended policy - the RIPE Database (WHOIS & Routing Registry), quality 9/10: route objects and version history to the early 1990s across 75 member countries.
4. Prior verdicts - Spamhaus DROP Lists, quality 8/10: ~1,700 netblocks, 40 IPv6 prefixes, 438 ASNs.
5. Ground truth inside the range - Shodan, quality 8/10: service banners across every routable address, crawled roughly weekly - attack-surface evidence rather than routing evidence, and the contrast matters; the head-to-head continues on our RouteViews vs Shodan page.

The scorecard below compresses the choice.

Start wide: the internet services infrastructure data guide maps the full ten-record pool - eight primary datasets plus two cross-industry entries - and the internet-services-infrastructure data hub puts field dictionaries, sample rows and coverage chips for every record on one screen. Adjacent workflows pick up where this page stops: BGP hijack detection data works the full verdict pipeline end to end, and ASN to IP range mapping covers the netblock-to-network join that scopes any routing question.

When you're ready to build, request a sample cut to the prefixes, ASNs, regions and years your brief names. It arrives with the field dictionary attached - and the schema in the sample is the schema you ship against. Everything in the pool is delivered daily, weekly, or hourly - your call.