Executive Summary

  • RouteViews is a University of Oregon-hosted, Network Startup Resource Center-operated measurement project that receives BGP routes from volunteer networks, records Routing Information Base snapshots and update messages, and distributes the resulting data through MRT archives, live streams, an API and a web Looking Glass.
  • The project grew from a 1995 external-view experiment involving an early MAE-WEST feed supplied through Randy Bush and RAINET. David Meyer was a principal early architect at the University of Oregon, while systematic daily archiving began through NLANR/MOAT in November 1997.
  • RouteViews’ collectors observe the routing control plane but do not carry ordinary end-user traffic, originate a normal service-prefix portfolio or possess authority to withdraw, repair or enforce another network’s route. Their value is evidentiary: they make selected announcements, withdrawals and paths visible from contributed vantage points.
  • The January 2026 review of 2025 reported 883 full-route sessions from 277 unique autonomous systems, eight new collectors, 67 TB of RIB and update storage, expansion of the API and Looking Glass, refreshed Kafka infrastructure and deployment of the Bimper BMP processor. Those numbers describe different units and must not be treated as a single collector count.
  • RouteViews is indispensable partly because its archive cannot be recreated after the fact. It is also incomplete by design: BGP peers export policy-selected routes, usually best paths, and the volunteer vantage-point set contains geographic, topological and network-type bias, redundancy, session artefacts and operational noise.
  • The project’s long-term question is whether a freely accessible, institutionally hosted and partly donated observability layer can scale its storage, software, staffing, replication and governance as the routing table, commercial use and demand for near-real-time access continue to grow.

The internet cannot see itself from one place

The internet is often described as one global network, but it is operated as thousands of independently controlled networks. Each autonomous system manages its own routers, internal topology, interconnection agreements, export policies and operational objectives. Border Gateway Protocol allows those systems to exchange reachability information, but it does not create a universal control room. An operator can see the routes received by its own routers and the routes selected under its own policy.

It cannot automatically see how every distant network is propagating the prefixes it originates, which alternative routes were hidden by best-path selection or what another operator chose not to export.

This lack of a complete view is not a temporary failure waiting for a sufficiently powerful dashboard. It follows from the architecture. BGP distributes partial information across administrative boundaries. Networks reveal what their policies allow, and the resulting control-plane state is different at different locations. A route can be visible in one region, suppressed in another, preferred through one provider and replaced by a more specific announcement somewhere else. Even when two routers receive the same prefix, they may select different paths because their commercial relationships and local preferences differ.

RouteViews exists inside that structural gap. It does not attempt to become the authority that decides which route is correct for the world. It asks a narrower operational question: what routing information did a contributing network export to a particular collector at a particular time? By gathering many such answers, preserving them and making them reusable, RouteViews creates a public observation layer for a system that has no single owner and no comprehensive native memory.

The distinction between observation and control is the foundation of the project. A RouteViews collector participates in BGP sessions, but it does not behave like an ordinary transit provider. It receives routes from peers and records them. PeeringDB’s profile for AS6447 reports zero originated IPv4 and IPv6 prefixes, a low-traffic, mostly inbound pattern consistent with this passive role. RouteViews normally sends no ordinary routes back to the networks contributing data.

It therefore cannot redirect the internet by publishing a preferred path, repair a leak by editing another autonomous system’s policy or withdraw a hijacked route on behalf of the legitimate holder.

That limitation is what makes the project analytically honest. The evidence can show that an unexpected origin appeared, a path changed, a more-specific announcement spread or a route disappeared from multiple vantage points. The evidence does not itself prove the physical path taken by packets, the commercial contract between two networks or the intent behind the change. RouteViews makes routing behaviour more observable. Operators, researchers and security systems must still interpret that behaviour and combine it with local logs, RPKI data, data-plane measurement and direct communication.

This is a form of infrastructure whose output is knowledge rather than carriage. The collectors are attached to the live routing system, the archive records its changes and the access services distribute those records. The project matters because critical operational decisions depend on evidence about systems that no participant can inspect alone. Its contribution is not sovereign command over routing. It is a durable method for seeing selected parts of routing reality from outside the network that is trying to understand itself.

From one MAE-WEST view to a public utility

RouteViews began in 1995, when public web-based looking glasses were not yet a routine part of network operations. The original problem was practical. A network could originate a prefix and verify that its own routers were configured correctly while remaining uncertain about how providers elsewhere saw the announcement. Troubleshooting from inside the originating network could not answer the external question. The operator needed a view from beyond its own administrative boundary.

Historical project material places an early external feed at MAE-WEST, one of the important interconnection environments of the period. Randy Bush, through RAINET, supplied the view. David Meyer’s later first-person account describes receiving an eBGP multihop session at the University of Oregon and adding peers, researchers and systems as use expanded. The evidence supports describing Meyer as a principal early architect and operator. It does not support reducing the origin to one sole-founder story.

Bush’s feed, the University of Oregon’s Advanced Network Technology Center and the operators who volunteered additional views were all part of the system’s creation.

The original service hostname, route-views.oregon-ix.net, reflected its narrow initial purpose. Users could connect to a router and inspect externally learned BGP information without being granted configuration privileges or becoming transit customers. The value lay in a separation of roles: the contributing network supplied a view, the University of Oregon hosted access and the querying operator gained perspective. No central institution had to certify the route for the view to be useful.

Use generated a reinforcing cycle. Operators found the external perspective valuable. That encouraged more networks to contribute feeds. Additional feeds made the tool more useful because they exposed differences among providers and locations. Researchers then recognised that repeated observations could answer questions beyond immediate troubleshooting. A live table could show how one network saw the world at one moment; a sequence of tables could reveal growth, policy change, instability and the response to failures over time.

The project therefore moved from service to utility without a clean founding boundary. It was not launched as a complete global measurement platform with a defined product roadmap, dedicated staff and distributed architecture. It accumulated those properties because its users kept exposing the limits of the previous form. The history matters because it explains the institutional character that remains visible today. RouteViews is a production service, an academic dataset, an operator collaboration and a public infrastructure dependency at the same time.

That hybrid identity also explains why the project should not be described as a separately incorporated company. Current records place it inside the University of Oregon and operationally within the Network Startup Resource Center. Its public interfaces have names, an ASN, a DOI, software repositories and peering policies, but no separately verified legal personality, shareholders, revenue statement or independent board. The project’s authority comes from operating collectors, maintaining data and earning continued participation—not from corporate ownership of the routes it observes.

The founding story is consequently more instructive when treated as an infrastructure mechanism rather than a heroic biography. A network operator contributed a useful view. A university team exposed that view safely. More networks joined voluntarily. Users generated demand. Archiving transformed transient state into reusable evidence. Each step became real because people configured routers, ran systems and used the output. No declaration made RouteViews important in advance. Importance emerged from repeated operational reliance.

How a live looking glass became a historical archive

A live view can solve a current troubleshooting problem, but it cannot answer what the routing system looked like yesterday unless someone recorded it. NLANR/MOAT began systematic daily archiving of RouteViews output in November 1997. This act changed the nature of the project. The service was no longer only a place where an operator could inspect current state. It became a memory of the internet’s changing control plane.

The earliest archive consisted of daily command-output dumps. Those files were valuable because they preserved information that would otherwise disappear, but their cadence and format limited what could be reconstructed. A route could be announced, changed and withdrawn between two daily snapshots without appearing in either. Text scraped from a router command line was also less suitable for standardised programmatic analysis than a binary record designed to represent protocol state.

In March 2001, RouteViews increased table collection to a two-hour cadence. The interval remains associated with the project’s current Routing Information Base archives. A RIB snapshot answers a state question: which routes did this collector hold at the snapshot time? It does not by itself explain every change that occurred before or after the snapshot. For that, analysts need the update stream—the announcements, withdrawals and attribute changes observed between states.

The shift toward local MRT recording was therefore more important than a simple increase in file frequency. MRT provides a machine-readable structure for routing messages, peer information, state changes and RIB contents. A collector can record updates as they arrive and periodically export table state without relying on thousands of remote users to execute show commands. The resulting files can be parsed by tools such as BGPStream, BGPKIT, bgpdump and custom research software.

This architecture enabled a common analytical workflow. A researcher loads a RIB snapshot to establish initial state, then applies subsequent updates to reconstruct how that state changed. The method supports study of origin changes, path changes, withdrawals, deaggregation and event propagation. It also exposes the importance of data integrity. A missing update file, an interrupted session, a parser error or a collector outage can create a gap between reconstructed state and what the peer actually exported.

The long archive is one of RouteViews’ strongest assets because historical control-plane evidence is non-renewable. A new collector can begin observing tomorrow, but it cannot recreate a path announcement that was never recorded in 1998, 2008 or 2018. The archive allows researchers to examine table growth, IPv6 adoption, the appearance and disappearance of autonomous systems, changing path structure and the routing effects of major incidents across decades.

“Continuous since 1997” must nevertheless be interpreted as continuity of the programme, not a guarantee that every collector, peer and file has been present without interruption. Distributed systems experience maintenance, resets, network failures and missing intervals. The earliest archive also differs materially from current collection in format, frequency and geographic coverage. A responsible use of the data identifies the relevant collectors and time periods instead of treating the entire archive as one uniform instrument.

The archive’s value therefore comes from both depth and documented limitation. It is a record of observations, not a perfect historical truth. It preserves what participating routers exported to available collectors under the operational conditions of the time. That is enough to support major scientific and operational work, provided the user does not confuse a long record with an omniscient one.

Centralisation failed before distribution became a strategy

The original RouteViews model concentrated many feeds and users on a central router. By mid-2000, a Cisco 7200VXR was handling more than 50 multihop BGP sessions and roughly 5,000 interactive logins per day. The system had become useful enough to exceed the architecture that created it. CPU, memory, session stability and command-line access all competed on one operational surface.

The first response included new software. RouteViews launched route-views2 in October 2001 using Zebra BGPD on Linux. The move toward commodity systems and open-source routing was strategically significant because a collector does not need the complete forwarding hardware of a traffic-carrying core router. It needs a reliable BGP implementation, enough memory to hold routing tables and mechanisms to record state. Software routing offered lower cost and greater automation potential.

Early Zebra did not immediately solve the problem. Historical material records difficulty handling roughly 60 peers. The lesson is important for modern infrastructure analysis: replacing proprietary hardware with open software is not automatically a capacity upgrade. Production routing depends on implementation maturity, memory behaviour, protocol correctness, observability and failure recovery. RouteViews retained and improved hardware while the software path developed.

The more durable response was architectural separation. MRT recording reduced dependence on interactive CLI scraping. Multiple collectors reduced reliance on one system. Dedicated archive and processing layers separated user access from protocol collection. Each separation assigned a responsibility to a component designed for that workload rather than allowing one router to serve peers, archive data and satisfy thousands of human and automated queries simultaneously.

The central multihop model also had a conceptual weakness. A peer’s BGP session to a collector in Oregon could depend on the same public internet whose failure the project was trying to observe. If an event disrupted reachability between peer and collector, the session might disappear, leaving ambiguity about whether the route changed, the peer failed or the path to the measurement system broke. Geographic distance also limited visibility into local interconnection that might never propagate through a distant provider.

Distribution therefore emerged as both a scaling and measurement requirement. The project needed collectors closer to the networks supplying data, especially at internet exchanges where many autonomous systems could establish local BGP sessions. A regional collector could observe exchange route servers and bilateral peers without requiring every contribution to traverse a long multihop path to Oregon.

This transition is an early example of a recurring infrastructure pattern. A central tool becomes popular because it simplifies access. Growth then exposes a concentration of workload, failure and interpretation. The solution is not to deny the value of the centre but to divide collection, storage and access so that the centre coordinates a distributed system rather than pretending to embody the system itself.

Why the project moved onto internet-exchange fabrics

RouteViews began accepting IPv6 feeds in May 2003 and deployed its first documented internet-exchange collector at DIX-IE in Tokyo in July of that year with support from the WIDE Project. Collectors followed at ISC/PAIX in October 2003, LINX in London in March 2004 and Equinix Ashburn in May 2004. These deployments created the model that now defines much of the platform: a RouteViews collector attached directly to an exchange fabric and receiving local eBGP sessions from networks present there.

An IXP collector has several advantages. The BGP adjacency can be established over the shared local fabric rather than through a multihop session across the public internet. The collector can recruit multiple networks already concentrated at one site. It can receive a feed from the exchange route server, which may represent routes from many participants. It can also observe local or regional interconnection that is not visible through a global transit provider.

The advantage is informational rather than magical. A collector at an exchange still sees only what its peers export. A network may send a full table, selected customer routes, local routes or a more limited view. A route-server feed represents the policy and membership of that server, not every bilateral relationship at the exchange. Physical presence at an IXP does not make RouteViews the operator of the exchange or the owner of the connected networks.

The distributed model also depends on hosts. RouteViews typically asks an exchange or network to provide a virtual machine or server, an exchange port, transit or management connectivity, power, cooling and local assistance. The central team supplies configuration, automation, integration and operational support. This arrangement makes global deployment economically possible without RouteViews building a company-owned facility in every region.

The in-kind model creates a specific dependency. A collector can disappear if a host changes priorities, removes the port, stops providing transit or retires the virtual machine. Hardware, hypervisor and local network environments can vary. Central automation must therefore produce consistent behaviour across infrastructure that is not wholly owned or physically controlled by the University of Oregon.

Recent expansion shows why exchange placement remains strategically important. During 2025, RouteViews added collectors in Costa Rica, the Philippines, Hong Kong, Indonesia, Romania, Nigeria, Sweden and Denmark. The locations included CRIX, GetaFIX sites in Manila, Cebu and Davao, HKIX, IIX in Jakarta, InterLAN in Bucharest, IXPN in Lagos and Netnod sites in Stockholm and Copenhagen. NSRC reported a new collector at DE-CIX Frankfurt in February 2026.

These additions are not merely dots on a global map. They respond to a change in internet topology. Large content platforms, CDNs and regional networks increasingly exchange traffic locally. A collector that sees only hierarchical transit routes can miss relationships and policy that remain near the edge. RouteViews’ 2025 selective peering policy explicitly prioritises regions and networks that add distinctive visibility rather than treating every additional session as equally valuable.

The project continues to operate multihop collectors because not every useful peer shares an IXP with AS6447. The two models serve different purposes. Local IXP sessions improve regional and exchange visibility. Multihop sessions extend participation to major backbones, research networks or specialised operators elsewhere. A complete strategy needs both, while acknowledging the path dependency and interpretive limits of each.

What a RouteViews collector actually records

A RouteViews peer establishes a BGP session and exports routes according to its own policy and the project’s peering requirements. The collector receives those routes into a BGP routing information base. It records table state and changes, but it has no normal forwarding role for the routes. Packets from ordinary users are not sent through the collector merely because the collector learned a path.

The word “route” can hide several kinds of information. For a prefix, a BGP record may include the origin autonomous system, the AS path, next-hop information, communities and other attributes. An update records an announcement, withdrawal or change. The collector associates the message with a peer and time. Analysts can then compare what different peers exported and how visibility changed.

The record does not reveal every fact about the underlying infrastructure. An AS path is not a physical fibre map. It does not show every router inside each autonomous system or identify every facility crossed. It does not disclose link capacity, traffic volume or commercial contract terms. The path represents control-plane information used to choose reachability, and BGP attributes can be transformed by policy.

The distinction between full routes and all paths is especially important. RouteViews prefers peers that send a full routing view, meaning routes covering most globally reachable prefixes. Standard BGP export usually sends the selected best path for each prefix, not every alternative known internally. RouteViews does not accept Add-Path under its current policy. A full-route feed therefore improves prefix and topology coverage without exposing the peer’s complete internal decision set.

A route-server session introduces another layer. At an exchange, the route server receives routes from many participants and redistributes them under its policy. A single RouteViews session to that server can reveal local routes from many networks. Yet the session peer is the route server, while the represented paths originate elsewhere. Analysts must not interpret the presence of an ASN in the data as proof of a direct commercial relationship with RouteViews or even a bilateral peering agreement at the exchange.

This is why RouteViews’ modern internal tools distinguish bilateral and route-server observations. Under the selective policy, the project may decline a bilateral session that adds no meaningful information beyond an existing route-server feed. The objective is not the largest possible adjacency count. It is a useful set of perspectives with enough diversity, stability and regional value to justify their operational cost.

The collector’s passivity also defines the security boundary. RouteViews can show that a route with an unexpected origin was visible from a peer. It can expose a more-specific announcement or the spread of an invalid route when combined with RPKI data. It cannot decide that the route must be removed from another network. Enforcement remains local to operators that apply filters, route-origin validation, prefix limits and incident procedures.

The resulting dataset is powerful because it is close to running reality while remaining carefully bounded. It records protocol messages from production networks. It is not a registry of contractual truth, a packet trace of user traffic or a central routing oracle. Every valid analysis begins by respecting that boundary.

Collectors, sessions, autonomous systems and vantage points are not interchangeable

RouteViews’ current scale is often expressed through several numbers that answer different questions. The January 2026 operational review reported 883 sessions receiving full routes from 277 unique autonomous systems. A February 2026 presentation described a network of more than 40 collectors, although some slides carried a May 2025 update date. PeeringDB listed 26 public exchange connections for AS6447 as of 29 July 2026. These figures can all be true because they describe different layers of the platform.

A collector is a router or routing software instance receiving BGP sessions. A session is one adjacency between a peer address and a collector. One autonomous system can provide multiple sessions at multiple locations, over IPv4 and IPv6, or through both route-server and bilateral relationships. A vantage point is the observational perspective generated by a session or contributing router. An exchange connection is AS6447’s presence on a particular fabric. None of these units maps one-to-one onto the others.

The distinction matters for analytical independence. Two sessions from the same ASN at different exchanges may reveal genuinely different policies and paths. They may also be highly redundant. A route-server session may expose hundreds of participant origins but still represent one exchange-policy context. A collector with many peers can produce a broad local picture while a collector with one unusual peer may contribute more unique information for a specific research question.

RouteViews’ reported 20% growth in full-route sessions during 2025 therefore should not be translated into a 20% improvement in global visibility. More than 50 existing peers changed their export policy to send full routes, and 28 new full-route peers were added. This increases the amount of usable table data, but the incremental value depends on where the peers sit, what they export and which paths are already visible elsewhere.

Research on the “most valuable points” problem makes this task dependency explicit. A vantage point that improves hijack detection may not be the same one that contributes most to AS-relationship inference. Randomly removing or sampling peers can reduce accuracy in uneven ways. The project’s selective policy is therefore a move from counting feeds to evaluating what each feed adds.

An exact date-aligned current collector inventory was not found in the public record. The more-than-40 figure, the eight additions and the 26 PeeringDB exchange connections should not be combined into a fabricated total. This is not a minor reporting issue. A public inventory with operational status, location, session type and archive continuity would allow users to understand which perspectives were available for a given analysis.

The scale figures are still meaningful when used correctly. They show that RouteViews is no longer a single university router. It is a distributed system with hundreds of full-route sessions, hundreds of contributing ASNs, dozens of collectors and exchange presences across regions. The analytical discipline is to preserve the unit attached to every number.

RIB snapshots, update streams and the reconstruction of routing state

RouteViews’ archive is built around two complementary forms of evidence. RIB snapshots record the routes held by a collector at a particular time. Update files record announcements and withdrawals observed between snapshots. Current documentation describes a two-hour RIB cadence and update files grouped into 15-minute intervals.

The intervals are packaging conventions, not guarantees that all events occur at those boundaries. BGP updates arrive continuously. The collector groups them for distribution. A RIB export can also take time to produce, especially as tables grow. Analysts need to understand timestamps, collector behaviour and file completeness rather than treating each file name as a perfect instantaneous sample.

Reconstructing state usually begins with a RIB and applies later updates in order. This allows an analyst to ask whether a prefix’s origin changed, how an announcement propagated or how long a withdrawal remained visible. The method also reveals how collector events can be mistaken for internet events.

A BGP session reset is the classic example. When a session re-establishes, the peer may transfer its table again. The resulting burst of updates can look like widespread routing change even though the underlying global topology did not change in the same way. Research on identifying routing-table transfers has developed methods for distinguishing these patterns when explicit session logs are incomplete.

A peer that silently stops sending data presents a different problem. The collector may continue operating while one vantage point becomes stale or absent. A file can exist and still contain less information than expected. Conversely, a peer can produce an extreme volume of updates through flapping, attribute changes, deaggregation, software defects or repeated table retransfers.

These behaviours create the unresolved choice between fidelity and filtering. Preserving every observed message retains evidence of instability and misconfiguration. It also increases storage, processing load and the risk that naive analyses count repetitive noise as meaningful internet-wide change. Filtering noise can improve usability while deleting the very evidence that another researcher wants to study.

RouteViews’ 2025 review described monitoring per-peer impact and the ability to disable sessions that threaten platform stability. That is a necessary operational control, but it introduces a governance and documentation question: when does a feed stop being valuable evidence and become unacceptable infrastructure risk? No universal public rule can eliminate the judgement because the answer depends on volume, cause, analytical value and service health.

The project’s value therefore depends on more than collecting messages. It depends on recording enough metadata, monitoring session health, preserving files, documenting changes and helping users distinguish routing events from measurement artefacts. The archive is an instrument. Like any instrument, it must be calibrated and interpreted.

The modern backend: FRRouting, BMP, Bimper and Kafka

RouteViews’ historical identity is tied to MRT files and direct router access, but its current platform includes a broader software and streaming architecture. Presentations in 2026 described Ubuntu Server 24.04 as the standard collector operating system and FRRouting 10.5 on software collectors, with one Cisco ASR1004 retained while the project continued moving from physical appliances toward virtual machines.

The shift to software collectors changes the operating model. A standard virtual machine can be hosted by an exchange or network with less specialised hardware, and configuration can be automated across sites. RouteViews’ published host specification calls for at least 16 GB of memory, preferably 32 GB, four virtual CPUs, 100 GB of storage, a management or transit interface and an exchange-facing interface. These requirements describe the collection node, not the central archive or stream-processing estate.

Collectors produce MRT files for the historical archive and can also export BGP state through the BGP Monitoring Protocol. BMP is designed to expose routing information from a router to monitoring systems without making those systems participants in route selection. In RouteViews’ architecture, Bimper receives BMP records from collectors, forwards compatible raw messages into Kafka and exports operational metrics through Prometheus. The bimperctl tool allows staff to inspect connections and service status.

Bimper was developed because OpenBMPd encountered stability problems under RouteViews’ load. This detail is important because it shows RouteViews as a software infrastructure operator, not merely a user of existing tools. The project had a production bottleneck in the live-data path and built a component intended to handle its own scale and observability requirements.

Kafka provides a distribution layer between collection and consumers. Without such a layer, every downstream system might query collectors directly or maintain separate session-processing logic. A stream platform can handle fan-out, backpressure and consumer independence more efficiently, although it creates its own reliability, ordering, retention and operational dependencies.

The archive and live stream serve different needs. Historical research values completeness, reproducibility and the ability to reprocess a period with new methods. Live monitoring values low latency and continuous delivery. A stream can reconnect and resume imperfectly; an archive can arrive later but preserve a stable file. RouteViews needs both because operational users and researchers ask different questions of the same underlying observations.

This backend also increases the importance of monitoring. A collector may be healthy while its BMP connection fails. Kafka may accept data while a consumer falls behind. MRT files may be written while a live stream is delayed. Prometheus metrics and service-control tools make these internal states visible to the operators who must maintain the platform. The project’s core product is observability, and its own infrastructure must therefore be observable as well.

The API and Looking Glass separate users from the collectors

Direct telnet access was appropriate when RouteViews served a manageable population of human operators. Over time, automated scripts began issuing thousands of commands against collector interfaces. A router designed to maintain BGP sessions and record routes became an unbounded query engine. The result repeated the original central-router problem at the access layer: useful openness created load that threatened the system providing the data.

RouteViews responded by building a browser-based Looking Glass and a structured API. The Looking Glass launched in May 2025 and supports common prefix, path-expression, summary and RPKI-oriented queries from selected nodes. At launch, its backend still translated web requests into commands executed through the telnet interface. The intended direction was to move more queries onto the API as coverage expanded.

The API currently covers ten collectors: AMS-IX in Amsterdam, LINX in London, NAPAfrica in Johannesburg, Equinix SG1 in Singapore, Equinix SYD1 in Sydney, IX.br in São Paulo and four multihop collectors at the University of Oregon. It exposes collector metadata, RIB information, peer information, adjacent-AS information and prefixes learned from specified sessions. Metadata is refreshed every two minutes.

The API is explicitly designed for current data rather than deep historical research. That separation prevents a common product mistake. A current query service and a multi-decade bulk archive have different indexing, storage and cost structures. Trying to make one interface perform both roles can degrade each. RouteViews directs longitudinal analysis toward MRT files while offering structured access for frequent current-state questions.

The API also supports internal operations. RouteViews has developed tools that compare a prospective peer’s originated prefixes, existing bilateral and route-server observations, regional contribution and collector coverage. Some tools can generate or modify collector configuration. This reduces manual effort and error, but it creates a new dependency on accurate PeeringDB records and safe automation.

The Looking Glass and API constrain workload in ways that direct CLI access cannot. They can limit query types, cache repeated responses, apply authentication or rate controls and return structured results. They also make access easier for users who do not want to parse MRT files or learn router command syntax.

The transition was incomplete at the July 2026 cutoff. API coverage represented a subset of the platform, and the Looking Glass still depended partly on the legacy interface. Retiring telnet too quickly could break scripts and workflows built over decades. Retaining it indefinitely could preserve the load and security problems modernisation is intended to solve.

The important strategic point is that RouteViews is moving from router-centred access toward service-centred access without abandoning the archive. The collector should collect. The archive should preserve. The API should answer structured current queries. The Looking Glass should support human diagnosis. Kafka should distribute live data. Separating those functions is the project’s current form of scale management.

Building a global view from voluntary peers

RouteViews does not compel any autonomous system to contribute. Its coverage emerges from voluntary BGP sessions, host relationships and the willingness of networks to expose routing information. This produces a public good through local decisions: each peer chooses what to export, each host chooses what infrastructure to provide and each user chooses how to consume the data.

The model has low central capital requirements compared with owning every collector location, but its success depends on social and operational relationships. RouteViews staff must recruit peers, verify technical readiness, coordinate exchange connections, troubleshoot sessions and maintain trust. NSRC’s global relationships with operators, research and education networks and exchange communities provide an institutional environment suited to that work.

The 2025 peering policy formalised a shift from broad intake to selective growth. Preferred peers provide stable full tables, useful regional or edge visibility, distinctive paths and production-quality operations. Applicants are expected to maintain current PeeringDB information, use public address space and a public ASN, filter special-purpose routes, avoid sending a default route and support IPv4 and IPv6 where possible. RouteViews does not accept Add-Path.

Selectivity is an acknowledgement of cost. Every session consumes memory, processing, monitoring and staff attention. Every update enters storage and possibly the live stream. A feed that duplicates an existing route-server view may add little information. A noisy or unstable peer can affect the entire platform disproportionately.

Selectivity also creates discretion. The peering coordinator evaluates whether a network is stable, regionally valuable or sufficiently non-redundant. The public policy allows exceptions, including possible acceptance of experimental networks, but no formal appeal or external review process was found. The flexibility is operationally useful; the governance surface should still be visible because selection shapes the dataset used by researchers and security systems.

Current sources also contain a role-title ambiguity. Nina Bargisen is identified as RouteViews Peering Coordinator in the January 2026 operational review and the 2025 policy publication. University of Oregon records identify Owen Conway as RouteViews Network Engineer and Peering Coordinator. The evidence does not establish whether the roles are complementary, reflect a transition or arise from different employment relationships. A responsible profile names both without manufacturing a resolution.

The broader team identified in a 2026 presentation included Hans Kuhn, Nina Bargisen, Owen Conway, Philip Smith, Philip Paeps and Anton Berezin. University records list Steve Huter as NSRC Director and Hans Kuhn as Senior Director for Research Infrastructure. An April 2026 RouteViews infrastructure-engineer vacancy described responsibilities spanning collector maintenance, tool development, industry relationships, data integrity, routing security and research support.

These records show that the platform depends on specialised people as much as donated machines. Global BGP collection requires peering judgement, routing operations, automation, distributed systems, storage management and user support. A small specialist team creates efficiency and continuity, but it also creates key-person and recruitment risk.

Routing security uses RouteViews evidence but remains outside RouteViews control

Route leaks and hijacks often become visible as unexpected routing changes. A prefix may appear with a new origin ASN, a more-specific route may spread, the AS path may change abruptly or the previous route may be withdrawn. RouteViews provides the observations from which monitoring systems and incident analysts can detect or reconstruct those patterns.

The project does not guarantee automatic detection. An event must propagate to at least one relevant vantage point, the peer must export it and the collection path must remain healthy. A localised incident can be invisible if no contributing network sees or reports it. A widespread event may be visible quickly from many sessions but still require context to distinguish malicious action from misconfiguration or legitimate policy change.

RPKI adds an external validation layer. Route Origin Authorisations can be compared with observed origin announcements to classify them as valid, invalid or not found. RouteViews’ Looking Glass supports RPKI-oriented checks. RouteViews itself does not issue ROAs, decide which networks must enforce Route Origin Validation or remove invalid routes from the global table.

The distinction between evidence and enforcement is operationally important. A security platform can alert on RouteViews data. An operator can configure filters or ROV. A registry and resource holder can manage ROAs. A response team can contact networks. RouteViews supplies a shared observation stream that helps those actors coordinate, but it does not absorb their authority or responsibility.

The same data supports topology and relationship research. AS paths provide evidence from which researchers infer provider-customer relationships, peering, customer cones and transit dependencies. CAIDA uses RouteViews data in prefix-to-AS mappings, AS Rank and related products. These outputs are derived through methodology. They are not direct contractual records or proof that every adjacency represents a specific business arrangement.

Prefix-to-origin mapping is similarly temporal and observational. It associates addresses with the origin AS visible in routing data at a time. It is useful for security, performance and policy research, but it is not a legal ownership registry. A more-specific route, anycast deployment, temporary event or multi-origin arrangement can complicate the mapping.

RouteViews’ relevance to security therefore comes from infrastructure position and historical continuity. It records control-plane signals from many networks and makes them available to systems that need external perspective. Its limitation is equally structural: it sees only the routes sent to it and cannot convert observation into universal compliance.

Research dependence and the relationship with CAIDA

RouteViews data became a foundation for internet measurement because it is public, long-running and expressed in widely supported formats. Researchers use it to study routing-table growth, AS topology, path change, prefix deaggregation, resilience, hijacks, leaks and the adoption of security mechanisms. A 2019 presentation cited approximately 500 publications, but no current independently deduplicated total was verified. The safe conclusion is extensive research use, not a precise current paper count.

CAIDA is one of the most important downstream institutions. It derives prefix-to-AS mappings and AS-level products from RouteViews observations and provides tools such as BGPStream that help researchers process RouteViews and RIPE RIS data. CAIDA, MIT CSAIL and UO NSRC also collaborated on the Global Measurement Infrastructure for Internet Security project from October 2021 to September 2025.

The ILANDS project, led by CAIDA and scheduled through March 2027, addresses scaling and long-term network-data infrastructure, including routing and storage challenges. These collaborations show RouteViews embedded in a broader measurement ecosystem rather than operating as an isolated university service. Grant values and objectives must nevertheless be allocated carefully: CAIDA-led or NSRC-wide awards are not RouteViews-only budgets.

The relationship with RIPE RIS is complementary. RIS operates its own distributed Remote Route Collectors and public routing services through RIPE NCC. It also uses active routing beacons, a feature distinct from RouteViews’ generally passive collector identity. The two platforms coordinate to improve redundancy and global visibility while remaining separate systems with different vantage points and interfaces.

Researchers commonly combine RouteViews and RIS because no single platform is complete. The overlap allows cross-checking and improves resilience. The differences reveal how measurement results depend on collector selection. Isolario and other platforms add further perspectives, while commercial monitors enrich public data with proprietary vantage points, alerts and support.

The existence of alternatives does not reduce RouteViews’ value. It clarifies the correct use. A robust analysis selects sources according to the question, documents the vantage points and tests whether conclusions survive changes in the dataset. RouteViews is not universally superior to every peer platform. Its distinctive strengths are archive depth, operator familiarity, public MRT data, the combination of IXP and multihop collectors and its institutional continuity at the University of Oregon.

The project’s DOI, 10.7264/1y7v-2d90, provides a citation mechanism intended to make academic use more visible and reproducible. Citation is part of sustainability because it allows the infrastructure contribution to be recognised. It does not by itself reveal how many products, papers or operational systems depend on the data.

Bias, redundancy and the limits of a volunteered view

RouteViews peers are not a random sample of the internet. They are networks willing and able to establish BGP sessions under the project’s policy, often at exchanges where RouteViews has a collector or through multihop arrangements. Collector placement depends partly on donated hosting. The resulting vantage-point set reflects operator relationships, interconnection maturity and strategic selection.

Geographic bias can arise because regions with large, well-organised IXPs are easier to observe. Network-type bias can arise because transit providers, research networks and technically engaged operators may be more willing to contribute than closed access networks or enterprises. Topological bias can arise because some parts of the AS graph have many vantage points while others have none.

These biases do not invalidate the data. They define the population the data can represent. A study of global routing that uses RouteViews should identify which collectors and peers were selected and avoid treating absence from the archive as proof that a route did not exist anywhere.

Redundancy is the corresponding cost of broad collection. Many peers export identical or closely related best paths. Redundancy improves resilience and can reveal disagreement, but it increases storage and computation. The marginal value of a new feed depends on the task. A path redundant for global prefix coverage may still be valuable for a regional incident.

Route-server feeds complicate interpretation because one session can expose many exchange participants. Bilateral feeds may duplicate those routes. A route server may alter path representation according to its design. Analysts need metadata that distinguishes the source relationship and avoids treating every represented ASN as a direct peer.

Best-path export creates another blind spot. A peer may know multiple paths but send RouteViews only the selected route. Hidden alternatives can become visible only when policy or reachability changes. The archive therefore reveals the paths used or exported, not the full option set available inside each network.

Physical topology is also hidden. Two AS paths that appear disjoint can share fibre, facilities, power or an upstream organisation. Routing data is essential for understanding control-plane diversity, but it cannot prove physical independence without additional evidence.

The disciplined conclusion is that RouteViews is a measurement instrument with known sampling properties, not a failed attempt at omniscience. More collectors can improve coverage, but no finite volunteer set removes every bias. The scientific obligation is to describe the instrument and bound the inference.

Noisy peers, storage growth and the economics of preserving everything

RouteViews reported that storage allocated to RIBs and updates grew from 11.1 TB to 67 TB during 2025. The same review described the largest full-route peers as supplying approximately 1.1 million IPv4 prefixes and 253,000 IPv6 prefixes. A separate presentation referred to around 50 TB compressed, probably reflecting an older date or a different storage definition.

The growth is partly expected. Routing tables expand, more peers send full routes and more collectors create parallel views. RIB size can be modelled reasonably from prefix counts and collection frequency. Update volume is harder because it depends on behaviour.

One unstable peer can generate a very large number of messages. Route flapping, repeated attribute changes, session resets, software defects and deaggregation can produce update bursts that dominate storage. Some of that noise is operationally meaningful. A researcher studying instability may value exactly the messages another user wants filtered.

The storage problem is therefore not solved by deleting duplicates indiscriminately. The archive’s purpose is to preserve evidence. Any filtering policy changes the instrument. At the same time, preserving every repeated message can make access slower, increase cloud and replication cost and encourage misleading analyses based on raw message counts.

The modern backend gives RouteViews more tools to manage the tension. Bimper and Prometheus can identify high-impact peers. Kafka can isolate consumers. Configuration policy can disable a session threatening stability. Cloud storage and BigQuery work may provide additional distribution and analytical capacity.

The RouteViews-Google repository describes synchronisation, checksums, gRPC transfer, storage in Google Cloud and conversion toward analytical tables. Development activity continued in July 2026. The public repository does not establish complete production coverage, archive parity, retention policy, cost allocation or service guarantees. It is evidence of active implementation, not proof that a cloud mirror has replaced the University of Oregon archive.

Long-term preservation requires more than adding disks. Files need checksums, replication, disaster recovery, metadata and accessible formats. A multi-decade archive also accumulates heterogeneous historical structures that must remain interpretable. Cloud distribution can reduce the burden on one delivery system and lower the barrier to large-scale analysis, but it can also introduce provider dependency and recurring cost.

The central economic question is which observations are worth preserving and who pays for their continued availability. RouteViews’ answer has historically favoured openness and breadth. The sustainability challenge is making that answer operationally affordable without silently changing the meaning of the archive.

The institutional model: University hosting, NSRC operations and community support

RouteViews is hosted by the University of Oregon and managed through the Network Startup Resource Center. Current university records place NSRC within UO Libraries. Steve Huter is listed as NSRC Director, Hans Kuhn as Senior Director for Research Infrastructure and Owen Conway as RouteViews Network Engineer and Peering Coordinator. The project’s operational review and presentation identify additional team members and Nina Bargisen’s peering role.

This institutional home gives RouteViews legal, employment, grant and administrative support without creating a standalone corporate entity. The arrangement also means RouteViews’ financial position cannot be reconstructed from project revenue and accounts because no separate audited budget, payroll, reserves or balance sheet is published.

The funding model combines university and grant support, direct contributions, in-kind hosting, technical collaboration and volunteer peers. Historical support included NSF award 0323769 for the Oregon Route-Views project, a DARPA NETPATH subaward, the University of Oregon, Cisco, Juniper and Sprint. The 2025 supporter list included Amazon, Catchpoint, Google, ICANN, Internet Society, Internet Society Foundation, MaxMind, NSF, Verisign, foundations and individual donors.

The amounts and restrictions of those contributions are not public in a RouteViews-only form. NSRC states that Google has provided substantial funding and hardware support, and the University of Oregon announced a $3,732,343 NSF award to NSRC. Those figures support the wider institutional environment and must not be presented as direct RouteViews revenue.

In-kind hosting is economically significant even when it does not appear in a cash budget. A collector host can supply a virtual machine, port, transit, power, cooling and staff time. Volunteer peers supply the data on which the service depends. The platform’s true resource base is therefore distributed across institutions and networks.

The model maximises public access. RouteViews says its data is freely available, and the site displays a CC BY 4.0 licence. Dataset-specific terms and historical artefacts should still be checked rather than assuming one footer governs every access path. API capacity controls and attribution expectations can coexist with free access.

Commercial products reportedly use RouteViews data. Project presentations name examples in network monitoring and intelligence. Open commercial reuse demonstrates impact and can improve routing operations, but it creates a free-rider problem. A company can build revenue-generating services on a public archive without a mandatory licence fee proportional to its use.

RouteViews has responded by asking successful commercial users to acknowledge and support the project. No compulsory commercial pricing or support contract was identified. This preserves openness while leaving sustainability dependent on voluntary contributions, grants and institutional commitment.

The governance surface is correspondingly informal in public. No dedicated RouteViews board, standalone advisory committee, service-level objective, peer-removal appeal process, published retention policy or succession plan was found. Governance appears to run through University and NSRC management, grant obligations, staff judgement and relationships with peers and hosts.

This can work well when the institution is trusted and the team is stable. It also creates questions as dependence grows. Commercial users, researchers and operators may rely on RouteViews as infrastructure without having a formal role in setting retention, access or resilience priorities. The absence of a separate corporation avoids one kind of bureaucracy; it does not eliminate the need for transparent stewardship of a shared service.

RouteViews’ impact mechanism

RouteViews’ influence can be traced as a chain rather than a claim of authority. First, an autonomous system voluntarily exports BGP routes to a collector. Second, the collector records the selected control-plane view as RIB state and updates. Third, RouteViews preserves and distributes the data through files, streams and services. Fourth, operators, researchers and vendors analyse the observations. Fifth, those users may change monitoring, incident response, filtering, topology models, policy or investment.

Every link has a separate decision-maker. The contributing network controls export. RouteViews controls collection and publication within its systems. The downstream user controls analysis. An operator controls whether to change routing policy. A security team controls whether to alert. A researcher controls methodology. The project’s impact emerges from interoperability among these decisions.

This division is a strength because no central approval is required for the data to become useful. A network contributes because it chooses to. A researcher downloads because the archive is open. A vendor integrates because the format is reusable. An operator acts because the evidence is persuasive in its own context.

It is also a limit on causal claims. RouteViews can supply evidence used during a hijack investigation without being the organisation that detected the incident first or corrected it. CAIDA can build a derived dataset from RouteViews without making RouteViews responsible for the methodology. A commercial product can depend on the archive without disclosing how much of its output comes from RouteViews.

The project’s strongest form of power is epistemic. It shapes what can be known about inter-domain routing and what historical questions can be asked. That is consequential because infrastructure decisions are constrained by available evidence. A route that was never observed is harder to investigate; a long archive can reveal patterns invisible in one operator’s logs.

Epistemic power should not be confused with factual completeness. The instrument selects reality through peer participation, policy export, collector placement and storage decisions. RouteViews deserves trust when those boundaries are documented, not when they are hidden behind a claim of a global view.

Lu Heng’s editorial framework is useful here as a discipline rather than a factual source about RouteViews. The relevant separation is between running state and institutional assertion. RouteViews’ value is demonstrated by collectors that receive routes, archives that preserve records and users that rely on them. The project does not need to claim ownership of routing truth. Its credibility comes from remaining a replaceable, inspectable and bounded observation layer.

Why BTW tracks RouteViews

BTW tracks RouteViews because routing observability is infrastructure. The routers that carry traffic are only one part of an operational internet. Operators also need systems that show how reachability is being represented beyond their own networks, preserve evidence during incidents and allow long-term comparison.

RouteViews is especially important because it combines production attachment to BGP with a historical archive extending back to 1997. That depth makes the project useful for questions that commercial dashboards built later cannot answer. It is also globally distributed enough to expose regional differences while remaining transparent about the impossibility of complete coverage.

The project illustrates a broader infrastructure principle: shared visibility can be created without centralising operational control. RouteViews does not decide routes for its peers. It records what they choose to reveal. The resulting dataset can support coordination among independent actors while preserving their authority to accept, reject and interpret locally.

Its weaknesses are equally instructive. Voluntary participation creates bias. Open access creates funding pressure. Donated hosting creates dependency. Legacy interfaces create technical debt. A small specialist team creates continuity risk. Storage growth creates an unresolved preservation problem. Increasing commercial reliance can outpace governance and contribution.

RouteViews should therefore be neither romanticised as a complete map of the internet nor dismissed as an academic archive. It is a production measurement system whose outputs have become embedded in research, monitoring and security. Its importance lies in the middle position: close enough to live routing to provide operational evidence, limited enough that every user must understand what the evidence does not contain.

Principal evidence and unresolved questions

The principal evidence for this profile is the supplied RouteViews deep-research pack, which in turn draws on RouteViews’ January 2026 review of 2025, the official peering policy and API documentation, University of Oregon and NSRC records, historical APNIC and NANOG presentations, PeeringDB, IETF specifications, RIPE RIS documentation, CAIDA project and resource pages, academic work on vantage-point value and measurement bias, and the project’s public repositories.

The record supports the 1995 origin, Randy Bush’s early MAE-WEST contribution, David Meyer’s principal early role, the November 1997 archive, the 2001 two-hour cadence, the 2003 IXP collector model, IPv6 collection, current University and NSRC hosting, AS6447, the current archive intervals, the January 2026 session and storage figures, the API, Looking Glass, Kafka and Bimper architecture and the 2025 collector expansion.

Several important facts remain unresolved. No exact date-aligned active collector count was found. The 50 TB and 67 TB archive figures use different dates or definitions. Nina Bargisen and Owen Conway are both publicly associated with peering coordination. PeeringDB’s route-server metadata conflicts with the official policy that accepts route-server routes. The completeness and production parity of the Google Cloud archive are not established. RouteViews publishes no standalone budget, staff count, commercial-user register, formal uptime history or archive-completeness dashboard.

The article therefore avoids several claims. RouteViews is not treated as a carrier, an internet exchange, a separately incorporated company, a complete view of global routing, an automatic hijack-enforcement service or the owner of every collector. Full routes are not described as all paths. Session counts are not converted into collector counts. Grant totals for NSRC or CAIDA collaborations are not assigned wholly to RouteViews.

The sources most directly supporting the profile include:

The central unresolved question is not whether RouteViews has value. The archive, collector network and downstream use establish that. The question is whether the project can preserve its historical openness and methodological honesty while becoming a larger, faster and more service-oriented data platform. That outcome will depend on storage, replication, API coverage, staff continuity, host relationships, transparent metadata and a funding model that reflects the commercial as well as academic value extracted from the system.