PeeringDB Shows that Automation Drives Network Interconnection Growth
In short:
- Over the last decade, PeeringDB has shown that interconnection has become important to organizations whose networks don’t sell network services, such as enterprises and governments.
- Around 44% of all networks curate their own connectivity through PeeringDB.
- Recent PeeringDB requests focus on automation features and data quality for analysis.
Web retailers introduced subscriptions so customers could automate the purchase and delivery of products they need on a regular basis. PeeringDB drives automation in interconnection through APIs. It's one element in an industry drive to remove manual steps from provisioning and configuration management.
Over the last decade, PeeringDB has shown that interconnection has become important to organizations whose networks don’t sell network services, such as enterprises and governments.
What is PeeringDB?
PeeringDB is a freely available, user-maintained database of networks and interconnection data. It's used to facilitate interconnection opportunity analysis and to help network operators introduce themselves to each other through its OAuth service. Some network operators won’t peer with networks not listed in PeeringDB.
You can use PeeringDB’s website or its API to make queries and updates. And networks can delegate responsibility for some updates to the exchanges, also known as IXPs, where they connect with other networks.
And some networks allow others to request peering using their PeeringDB credentials. This simplifies the introduction problem. There's less friction to interconnection when there's no need to create and manage new accounts.
Of course, networks and exchanges need to place their equipment somewhere. PeeringDB also lists:
- Interconnection facilities (data centers)
- Internet Exchange Points (IXPs), where networks meet to exchange traffic
- The carriers that connect facilities with high-capacity links.
Growing numbers
The number of networks in PeeringDB has grown fivefold over the last 10 years: from just under 6,500 networks in 2016 to almost 35,000 today. The number of exchanges has more than doubled over that period to over 1,300, and the number of facilities has almost tripled to almost 6,000.
Geoff Huston's CIDR Report listed 78,837 networks in the inter-domain routing system in June 2026. That means about 44 percent of all networks care about curating their own connectivity today, rather than outsourcing everything to transit networks.
A decade earlier, this was just under 12 percent. The fourfold growth in networks listing themselves on PeeringDB matches the fourfold growth in connections at exchanges and facilities—as listed on PeeringDB—over that period.
Automation
In 2016, PeeringDB didn't support exchanges automatically reporting connections by network. Then Euro-IX developed the IX-F JSON format.
By 2019, PeeringDB had provisional support for it, and by August 2020, over 3,300 networks enabled IX-F updates. In other words, many networks were happy to have the manual task of recording their connections at exchanges automated by the exchange's management software.
Over 4,000 networks were accepting automated updates about their presence at IXPs in 2021. That number is almost 8,300 today. Just over 2,000 of those networks don’t (yet?) peer anywhere, though.
Who cares?
Larger and smaller networks approach automation differently.
The largest and most heavily connected networks often rely on automated configuration derived from an internal source of truth. Updating their internal source of truth will produce and push the appropriate configurations to equipment anywhere on their network. It can also push updates to PeeringDB through our API.
Sometimes, smaller networks haven’t automated everything. Giving an exchange permission to automate PeeringDB updates relevant to that exchange, such as IP address assignments, is often welcome.
In June 2026, almost 770 networks have 10 or more connections at exchanges, and more than 50 networks have 50 or more connections. And we see something similar with presence in facilities. Over 1,100 networks are present in 10 or more facilities, with 85 present in 50 or more.
Exchanges are often present in multiple facilities to improve resilience and reach. It makes sense for networks to match that pattern. This is probably why networks connect at more facilities than exchanges.
In June 2026, over 700 networks that categorized themselves as enterprises, often alongside another category, enabled IX-F updates. This means that automation isn’t just important to massively interconnected network service providers; it's important to organizations that want or need to interconnect their network with others.
The rest of those organizations embracing the automation provided by the IX-F standard include:
- Over 4,000 subscriber access providers (cable/DSL, etc)
- Over 1,100 Network Services Providers
- Over 700 content networks
- Over 600 education or research institutions
Nonetheless, almost 60 percent of the most interconnected networks—those with 10 or more IXP connections—haven't enabled this feature.
In fact, it’s enabled by about a third of networks across most categories. But almost half of the subscriber access providers enable it.
The future?
Recent requests for PeeringDB enhancements have often focused on things that help automation. Some of these are simple automation features, like an API for managing your users in PeeringDB. Others focus on data quality, which is vital for analysis, whether performed by humans or silicon.
We’ve been improving the quality of location data and developing new processes to ensure references to set objects in IRRs are unambiguous and correct.
We’ve also added some granularity to the controls for accepting inputs via the IX-F JSON submitted by IXPs. It’s now possible to accept only IP address information and reject information such as port speed and whether a network peers with the route server. We hope that giving people more control over what they accept from IXPs will increase the overall accuracy of data published in PeeringDB.
If we see more of the most interconnected networks allowing updates from exchanges, we'll know this change has been useful.
We’ve also required new IXPs to provide an IX-F JSON file when registering. We anticipate that this will reduce the number of ordinary networks registering with an IXP rather than connecting to it. It should also encourage newer IXPs to use software that generates the IX-F JSON for them – although it’s simple enough to handcraft a file for a small exchange.
Leo Vegoda provides bespoke services to Internet infrastructure organizations. He is PeeringDB's Product Manager and Product Managed IXPDB.
Contributor: Arnold Nipper.
The views expressed by the authors of this blog post are their own and do not necessarily reflect the views of the Internet Society.
by Alex Knight on Unsplash