As 2026 gets underway, it’s a good moment to look back at what the RouteViews team delivered over the past year. New collectors, new tools, new ways to access data, and a lot of behind-the-scenes work to make the platform more stable, sustainable, and useful for everyone.
What we do at RouteViews
RouteViews exists to collect Border Gateway Protocol (BGP) routing tables (Routing Information Bases (RIBs)) and updates, archive them, and make the data available to the Internet operations and research communities. We do this by operating a platform of route collectors connected to Internet Exchange Points (IXPs) throughout the world. We collect the BGP data by peering with the networks that make up the Internet.
RouteViews data is widely used by researchers, vendors and operators. Debugging routing issues, monitoring prefixes to discover and mitigate hijacks, understanding the evolution of the Internet, the deployment of new protocols and security technologies and the evolution of the topology of the Internet are just some of the ways our data is being used. The data is freely available for everyone – peers as well as non-peers.
RouteViews is managed by the Network Startup Resource Center (NSRC) at the University of Oregon. We work with colleagues at the RIPE Routing Information Service (RIS) in Europe to coordinate what we learn about real-world Internet routing with the objective of creating data redundancy, resiliency, and maximizing visibility of the Internet’s global routing table.
Peering policy
We started the year by finalizing and publishing our selective peering policy. Calling it ‘selective’ is mostly a matter of semantics — we still actively seek new peers. But the policy gives us clear reasons to decline requests for operational and capacity reasons. There is no value in collecting the same routes from both route servers and bilateral sessions, or in dealing with instability from experimental networks.
More importantly, the policy articulates why we peer and what we are looking for — full routes from networks that are well connected in their region, so we can capture what is actually happening on the Internet. Both at the edges of the Internet and at the global hubs.
You can read the full policy on the RouteViews website.
New locations
We deployed eight new collectors in 2025, with one more on the way. This means we are now present at:
- CRIX, San Jose, Costa Rica
- GetaFIX Manila, Cebu and Davao — Philippines
- HKIX, Hong Kong
- IIX, Jakarta, Indonesia
- Interlan, Bucharest, Romania
- IXPN, Lagos, Nigeria
- Netnod, Stockholm, Sweden, and Copenhagen, Denmark
Most of these are in locations where we had no presence before. Only route-views8 is a capacity upgrade for our existing multi-hop setup — the rest are expanding our view into new parts of the Internet, in line with our policy focus on edge visibility.
The more full-route peers we have from a region, the more vantage points we have for our data, and the better our snapshots of the Internet become.
At the time of writing, we have 883 sessions receiving full routes from 277 unique Autonomous System Numbers (ASNs). That’s an increase of around 20% over the year, with more than 50 existing peers agreeing to change their routing policy to send us full routes, and 28 entirely new peers with full routes. We have also formed partnerships with some global content providers and Content Delivery Networks (CDNs) that now share their diverse views from local ecosystems within their markets. We will continue this work in 2026.
Our storage space for RIBs and updates grew from 11.1TB to 67TB in total. This growth is partly due to the higher number of peers and full routes peers, but is also driven by the growth of the size of the global routing table. The largest RIBs we see from full route peers are 1.1 million prefixes for IPv4 and 253 thousand prefixes for IPv6. Unfortunately, we have a second driver for the growth — noisy peers.
Noisy peers
RIB sizes have grown fairly steadily as a direct consequence of adding/losing peers over time, IPv6 growth, and IPv4 /24 fragmentation. This is generally something we can predict for, and in fact, we have done simple linear regression to predict growth over the next five years.
In contrast, we see a much more unpredictable pattern in the growth of storage consumption for updates. Take a look at Figure 1. The last bump is largely due to an increase in messages from a single ASN. These events are hard to predict and are often due to configuration errors, software bugs, or instability inside the operator’s network.
We’ve done several things behind the scenes to improve monitoring and visualization of these noisy peer events when they happen. However, we’re still navigating the decision-making between the philosophies of ‘recording everything we see’ and ‘this noise will fill our disks, and future researchers will be annoyed at us’.
Internal tooling
Implementing a new peering policy turns out to be an excellent driver for building tools. When you need to evaluate peering requests, you need to quickly get an overview of the data that informs the decision — do we already see this network’s prefixes? From where? Via route servers or bilateral sessions?
Our internal RouteViews toolset has grown considerably this year. We now have tools that show a requesting ASN’s BGP information (originated prefixes, existing sessions, route server sessions), tools that auto-generate session configuration or amend existing configuration and tools that can help us decide which ASNs we want to ask for full sessions, and which IXPs would be the best to connect to, to gain the best insight into a region’s Internet ecosystem. One major change in our internal tooling is that we now use the RouteViews API whenever we need data related to BGP, whether it is related to ASNs on the Internet or peering sessions and more, instead of logging into the individual collectors or downloading Multi-Threaded Routing Toolkit (MRT files)/
All this means we can respond to peering requests faster and make better-informed decisions about where to deploy collectors and who to reach out to for peering.
API improvements
During the year, we have been preparing the RouteViews API to scale to include all our collectors. At the same time, we added several new endpoints, mostly driven by our own internal tooling.
The new endpoints include:
/rib/peers
- Which returns information about the peering sessions on the routeviews collectors.
/rib/adjacent_asns/ASN
- Which returns sessions where at least one of the announced routes starts with the query ASN. This is useful for identifying route server sessions, and was built specifically because we needed a fast way to see if we already receive a requester’s prefixes via route servers.
/rib/prefixes-from-peer/PEER-ASN/PEER-IP
- Which returns the prefixes learned from a specific BGP session, with support for regexp and community filtering.
Some of the new endpoints enable us to perform some of the common BGP queries programmatically using API data instead of logging into a collector and performing those queries over data from more than one collector. If you ‘only’ need to do a few one-off queries, we built another tool for you.
The RouteViews Looking Glass
In May, we launched the RouteViews Looking Glass. The Looking Glass provides the most common BGP commands through a web interface, and you can select any of our collectors. You can view routing tables, BGP summaries, and specific prefix paths directly, making it easier to analyse routing behaviour across different parts of the global Internet. Currently, the Looking Glass runs the commands on the collectors using telnet, but eventually it will use our API instead. If you haven’t tried the looking glass yet, try it out and let us know if your favourite command is missing. If you’re building tools on top of our data or API, we’d love to hear what you’re doing with it.
Backend infrastructure and Bimper
The new API endpoints pull their data from our Kafka streaming infrastructure — the same feed that powers stream.routeviews.org.
We refreshed the Kafka streaming cluster with new hardware, and we developed a replacement for OpenBMPd, the software we use to receive BGP Monitoring Protocol data from our collectors and forward it to Kafka for downstream analysis and storage.
OpenBMPd had stability issues under our load, so we wrote our own. We call it Bimper. It is a specialized high-performance BMP message processor with Prometheus metrics integration for operational visibility. It comes with bimperctl, a control utility for managing and monitoring bimper instances. The messages bimper produces are compatible with the ‘raw BMP’ format that OpenBMPd used, so existing downstream tools continue to work.
Bimper is a monitoring powerhouse, particularly in our work with noisy peers. We collect metrics that help us assess the impact of a noisy peer, particularly on our live streaming infrastructure. The data also helps when we engage with noisy peers — we can point them to the live stream so they can see what we see and help solve the problem.
Research
RouteViews now has a Digital Object Identifier (DOI), so you can cite the project properly in your research papers and publications. For citations, our DOI is 10.7264/1y7v-2d90.
We are thrilled to see that the long list of papers and projects using our data continued to grow in 2025. While operational needs drive the day-to-day use of RouteViews, we are excited to follow the new knowledge presented by those who study and measure Internet routing.
If you use RouteViews data for research projects and publications, please acknowledge the value of this information for your research activities.
Supporters
None of the work we do would be possible without the support of our funders, sponsors, hosts of collectors and collaborators in general. RouteViews is a project rooted in the operator and the research communities. We work to collect and preserve data valuable for both and collaborate widely to make sure we support the communities in the best possible way.
In 2025, RouteViews received valuable financial contributions from:
- Amazon, Catchpoint, Google, Internet Corporation for Assigned Names and Numbers, Internet Society, Internet Society Foundation, Jim and Joan Forster, MaxMind, National Science Foundation, Silicon Valley Foundation, Verisign, and Vint and Sigrid Cerf.
We want to thank all our supporters for the help that enables us to extend and preserve the oldest and most comprehensive BGP data archive, which documents the Internet’s evolution, second by second, in continuous time.
Questions, feedback, or peering requests — help@routeviews.org is always open and happy to hear from the community.
Nina Bargisen is the RouteViews Peering Coordinator.
This post is adapted from the original at RouteViews Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.