17
Dec
2025

All the new things – RouteViews in 2025

Posted by RouteViews Peering Coordinator

Nina Bargisen

As 2025 draws to a close, we want to share what we’ve been working on this year in the RouteViews team. New collectors, new tools, new ways to access our 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 BGP routing tables (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 Exchanges (IXPs) throughout the world. We collect the BGP data by peering with the networks that make up the Internet.

RouteViews data are 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 are being used. The data are freely available for everyone – peers as well as non-peers.

RouteViews is managed by the Network Startup Resource Center 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 here.

New Locations

We deployed 8 new collectors in 2025, with 1 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-routes 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 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 with 11.1 TB to 67 TB 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 sizes 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 5 years.

In contrast, we see the much more unpredictable pattern in the growth of storage consumption for UPDATES. Take a look at the graph below. The last bump is large 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.

Noisy Peers: last bump is large due to an increase in messages from a single ASN

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 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

– returns information about the peering sessions on the routeviews collectors.

/rib/adjacent_asns/ASN

— 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

— 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 to perform 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 at https://lg.routeviews.org/. 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 analyze routing behavior 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 at lg.routeviews.org — and let us know if your favorite 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 in particular 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 from 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, that 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.

Posted by Nina Bargisen in blog
20
May
2025

The RouteViews Looking Glass is here!

Posted by RouteViews Peering Coordinator

Nina Bargisen

Are you using the RouteViews collectors as remote looking glasses? If so, we are now making your life easier. https://lg.routeviews.org/ now provides you with a well-known web front end to all the RouteViews collectors. No need to log in to the individual collectors using telnet any more.

The looking glass provides you with the most common BGP commands and you can select any of the RouteViews collectors. You can view routing tables, BGP summaries, and specific prefix paths directly from each collector, making it easier to analyze routing behavior across different parts of the global Internet.

Why a web front end?

Why are we doing this? Many RouteViews users love the CLI, but over the years, more and more users are frowning at telnet for the lack of encryption and the general perception is that telnet is a legacy protocol with security issues. The looking glass is our first step towards removing the direct telnet access to all collectors.

A front end for users to access our collectors also gives us the ability to control the load on the collectors better – for the purpose of securing stability and consistency of the total platform. With the looking glass, we have introduced a bit of rate limiting. So there is a risk that you will encounter a “Sorry the collector is busy right now.” But fret not, it will most likely just be for a few seconds, so just take a sip of coffee and try again if it happens. We believe this to be a better experience than the occasionally laggy keys when the collector is busy.

How to use the RouteViews Looking Glass:

For example, we want to see who are the peers on the collector in Serbia:

  1. In the drop down list “Node” select “route-views.soxrs”
  2. Select BGP
  3. In the additional Parameter field type in “summary”
  4. Select IPv4 or IPv6 and hit the Submit button

Which results in:

And if you want to see the prefixes we learn from Cloudflare, the regexp option will show you:

Which results in: Note that the illustration is a sample of the much longer output

Conclusion

We are excited to launch this well-known tool. We hope the users of the RouteViews system will appreciate this new service and use it well. We have undoubtedly forgotten to implement your favorite CLI command, so please try it out and give us feedback on what is missing, any bugs or weird behaviours that you may see.

Posted by Nina Bargisen in blog
10
Jan
2025

RouteViews Peering Policy

Posted by RouteViews Peering Coordinator

Nina Bargisen

Most of us will know that the Internet, true to its name, is a network of networks. Each network, whether a local ISP or a global content provider, must connect with others to enable the worldwide flow of data we know as the Internet. We have two ways to interconnect: transit, where one network pays another for connectivity to the rest of the Internet, and peering, where networks agree to exchange traffic directly.

Peering Policies
As a network operator, your willingness to peer is stated in your peering policy. There are three types of policies:

  1. Open – the network peers with everyone,
  2. Selective – the network has defined a set of rules that describes who they peer with and how,
  3. Restrictive – these networks have very little interest in expanding their peering.

The set of rules is (also) called a peering policy and a set of rules that allows you to say “no” for the more open end of the spectrum, or a set of very hard requirements to meet for the more restrictive end. A common policy, often difficult to meet, is a requirement for balanced traffic exchange between the networks. This is popular among transit networks and removes the discussion with potential customers who want to be a peer instead.

Why say no to peering?
There are other valid reasons to want the ability to decline peering with a specific network, even when your business doesn’t sell Internet access to other networks. A wish or need to reduce operational overhead is one example; load on the edge routers is another. As every network and organisation running it is different, so are the specific reasons.

What we do at RouteViews
RouteViews exists to collect BGP routing tables and updates, archive them, and make the data available to the Internet operations and research communities. We can call this taking snapshots of the Internet. From that perspective, we have operated with an Open peering policy until now since more peering would give us more data.

However, the landscape of Internet routing data collection is evolving, as demonstrated by our sister project. The Routing Information Service (RIS) maintained by the Réseaux IP Européens Network Coordination Center (RIPE NCC), introduced a selective policy some years ago. Along with that came a proactive approach to ensure that collected data would still be useful.

RIS’s choice of metrics for the usefulness are:

  • The number of routes – do we have every prefix on earth?
  • Closeness to the origin of prefixes, grouped by countries – what is the local reach per country?

These are good metrics. And it looks like RIS is successful with their approach. With this context in mind, let’s understand why we’re making changes to our peering policy.

What is a snapshot of the Internet
Key aspects, of course, are which prefixes are announced by who, the messages that are sent between the peers. Another consideration used by peering coordinators and network planners is who is connected to who and how.

Why is this interesting? Folks in the peering community work hard every day to safeguard the resilience and security that densely connected networks have because it is widely accepted that this gives the best control of how your originated traffic reaches its destination and how the traffic into your network arrives the best possible way. When you want to analyze and evaluate a new potential peer, or even a new market for your services, information on how everyone is connected is in high demand.

The changing Internet landscape
In the old-fashioned Internet, where traffic flowed up and down in the “tier 1”, “tier 2” and “access network” hierarchy, it was easier to take a snapshot of the connections where the Internet traffic flows than now. Today the large traffic volumes flow on the edges of the Internet, to and from content delivery networks (CDNs) and clouds that are deployed close to consumers. This interconnectivity information does not propagate up in the old hierarchy but must be collected directly from the edge players and on the edge.

This is a simple example of the differences between the flat and the hierarchical Internet

In the traditional hierarchical Internet, RouteViews’ open peering policy captured the most relevant routing relationships. However, today’s flat Internet architecture requires us to be more strategic about where and with whom we peer to capture what is happening on the edge.

How RouteViews data are used by the community
RouteViews data are widely used by researchers, vendors and operators throughout the world. 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 are being used. The data are freely available for everyone – peers as well as non-peers.

Peering Policy

General requirements:

  • Peer must operate stable equipment – RouteViews will shutdown BGP sessions that disturb the stability of the RouteViews platform
  • Peer must have a routable ASN
  • Peer must not be a hobby network
  • Peer’s full view of the global routing table is preferred
  • Routes should be aggregated as much as possible ( no longer than /24 for IPv4 and /48 for IPv6)
  • Peer must be present with up-to-date information in PeeringDB – including the NOC email address
  • Peer must filter RFC6890 space
  • RouteViews does not accept addpath-RX or TX
  • Peers must not send default routes

IXP peering:

  • We happily accept everyone’s routes from the route servers.
  • We will set up bilateral sessions with anyone who meets the general requirements and will send us their full table.
  • We will peer at all mutual exchanges if requested.

Multihop peering:

  • We will accept multihop peers who are not on any mutual IXPs.
  • Peers must provide their full view of the Internet as they see it.
  • We accept two sessions for redundancy; more than two sessions can be set up if the feeds are sufficiently different.

Peering is ultimately at the discretion of the RouteViews peering coordinator. Policy and peering availability are subject to change without notice. The RouteViews peering coordinator may also decide in exceptional circumstances to agree to set up, for example, bilateral sessions with peers who will only send us peering routes at exchanges, or multihop sessions with peers who can only provide partial routes.

Key Considerations
We believe this policy will help us balance valuable data for the community and a stable and reliable platform. Let’s look at some key requirements that are specific to RouteViews and why they matter:

No hobby networks: We love that people run networks to learn and experiment. However, hobby networks often need extensive support and disproportionately impact collector stability. To maintain reliable service for everyone, we’re focusing on production networks.

Full tables: This is the requirement that lets us see more than the customer cones of transit networks and the originating prefixes of everyone else. (A customer cone is the customers and their downstreams of a transit network.) The full tables are a requirement in order to be able to derive who is connected to who and how, as the usual peering configuration does not show any peering connections.

If you can’t announce full tables and you are on the routeserver, we do not want to use resources on bilateral sessions since we are already getting all the information that you can provide. If you are not able to announce the full table and are not using the routeserver, but have an interesting set of routes, we will consider peering with you.

What makes a peer interesting?
“Interesting” can mean many things. It could be

  • Networks in regions where we have limited visibility
  • Networks demonstrating new interconnection patterns
  • Networks using innovative routing practices
  • Networks that help us understand emerging market dynamics

or maybe something we haven’t thought about yet.

How to get started with peering with RouteViews
If you want to support us by peering, please let us know by writing to help@routeviews.org.

What else is new?
Over the past year, we have hired more people for our team. Every aspect of the project is being  modernized and upgraded. We are working on the backend architecture, upgrading storage hardware, developing new ways to make the data available for our community using modern technologies, and expanding the collector network and our peering. So stay tuned; more news will come.

Posted by Nina Bargisen in blog

Alerts/Maintenance