PeeringDB has introduced a change in its 2.82.0 release that may look small on a network’s registration form, but has direct consequences for the automation of interconnection services. The AS-SET field leaves behind its ambiguous format and now also identifies the source Internet Routing Registry (IRR) through a syntax such as RIPE::AS5405:AS-INTERDOTLINK. The goal is to let tools know exactly which set of routes to query without having to guess among several possible sources.
PeeringDB’s AS-SET Changes in 20 Seconds
- PeeringDB 2.82.0 was released on August 19, 2026, and introduces the AS-SET change.
- The new format adds the IRR before the name: RIR::AS-SET.
- The goal is to eliminate ambiguity when the same AS-SET appears in different IRR registries.
- PeeringDB is automatically fixing some unique names and notifying networks that need to update ambiguous ones.
- The change particularly affects systems that automate onboarding, service configuration, and routing policies.
The problem stems from a fairly common feature of the internet: much of the information network operators rely on comes from databases maintained by different organizations. An AS-SET is used to group autonomous systems (AS) and describe, among other things, which networks or prefixes can be found behind an operator.
Until now, PeeringDB allowed the AS-SET name to be entered as plain text without requiring the source IRR to be specified. Someone familiar with the network could often figure it out. An automated system could not necessarily do the same.
PeeringDB itself acknowledges this problem. Its documentation explains that some AS-SETs don’t use the AS number in their name and that certain sets can be published in more than one IRR. When that happens, an organization looking to automate service onboarding needs to manually determine which AS-SET is the correct one.
The Problem of a Name That Can Mean Several Things
An example helps illustrate this.
An operator might use an AS-SET called AS-GENERICISP. If that same name exists in different IRRs, an application that finds AS-GENERICISP in PeeringDB doesn’t have enough information to know which registry it should query.
The data looks valid, but it lacks enough context to safely automate a decision.
That’s the scenario described by Stefan Funke of Inter.link in his explanation of the change. The company uses PeeringDB information to automate part of its IP Transit service configuration. If the AS-SET doesn’t unambiguously identify its source, the system has to choose between different possibilities or ask for human intervention.
It’s the well-known garbage in, garbage out problem: if the input data doesn’t correctly identify the source, an automated system can process the information perfectly well and still produce an incorrect configuration.
This change isn’t meant to resolve whether an AS-SET is actually correct for a given network. The database continues to be maintained by its users. What changes is the ability to unambiguously express which IRR should be used.
The syntax chosen is:
IRR::AS-SET
So, an entry such as:
RIPE::AS5405:AS-INTERDOTLINK
indicates that the AS-SET should be looked up in RIPE’s IRR registry.
PeeringDB Starts Fixing Existing Records
Version 2.82.0 arrived on August 19, 2026, and specifically incorporated the work tied to issue #1973, titled “Force networks to publish as-sets unambiguously.” PeeringDB explains that the change includes a smart editor for AS-SET names and that it began proactively fixing sets whose names were already unambiguous.
The process isn’t simply a matter of adding text to every record.
PeeringDB has explained that when an AS-SET is already unique, it can automatically identify the corresponding IRR and add the prefix. When names are ambiguous, however, the organization needs to contact the networks’ owners so they can update their records.
A validation check has also been added to the editor to help confirm that the specified AS-SET exists in the selected IRR. This means the form no longer just captures a text string — it can verify that the combination entered actually makes sense.
The change follows other modifications related to data quality. In version 2.80.0, PeeringDB removed the alternative format that used a suffix such as AS64496@IRR and moved to favor the notation with the IRR as a prefix, for example IRR::AS64496.
The direction is clear: an application should be able to interpret the field without having to apply its own rules to guess what the operator meant.
Why It Matters for Networks That Automate Services
The most interesting consequence appears when PeeringDB is no longer queried by a person and instead feeds directly into a system.
The database gathers information from tens of thousands of organizations and is used as a reference for interconnection decisions. PeeringDB describes the platform as a community-maintained database that facilitates interconnection between networks at internet exchange points (IXPs), data centers, and other facilities.
For a company that configures each connection manually, ambiguity can be resolved by asking the customer or checking several records.
On an automated platform, that human step defeats the very purpose of automating.
This scenario can happen when onboarding an IP Transit customer. The customer provides its autonomous system number, the system queries PeeringDB, retrieves its AS-SET, and uses that information to build or validate the configuration related to its routes. If the AS-SET name exists in different IRRs, the application can’t determine on its own which one to use.
The new format provides a piece of information that could previously be missing.
It doesn’t turn PeeringDB into an infallible source. Nor does it guarantee that the content entered by each operator is correct. What it does is reduce a specific type of ambiguity that is especially problematic for automated tools.
And that difference matters at a time when operators are automating an increasing number of tasks related to BGP, customer onboarding, service configuration, and route validation.
The Change Is Small for Operators, but Significant for Machines
For a network that already has a correct, unique record, the update can be relatively simple. The operator needs to review its PeeringDB record and check that its AS-SET also identifies the corresponding IRR.
PeeringDB is notifying organizations whose names remain ambiguous so they can make that update. The organization itself acknowledges that the work doesn’t end with version 2.82.0 and that it will continue monitoring data quality.
The importance of this kind of change often goes unnoticed because it doesn’t directly affect a connection’s performance, doesn’t increase a port’s bandwidth, and doesn’t change the BGP protocol either.
But it does change something less visible: systems’ ability to automatically interpret internet information without human intervention.
That detail can make the difference when a platform aims to automate everything from customer onboarding to service configuration.
PeeringDB’s own recent history shows that data quality is becoming a priority for the project. The platform has more than 34,000 registered organizations and is introducing mechanisms to standardize and validate information that operators and external tools later rely on.
For operators, the recommendation is simple: review PeeringDB records and update AS-SETs to the new format when necessary.
For those building automation around PeeringDB, the change has further-reaching implications. A field that previously might have required heuristics or human intervention now starts to provide the information needed to deterministically select the data source.
In an increasingly automated internet infrastructure, the difference between “this looks like the right record” and “this is the record that should be queried” matters far more than it appears.
Frequently Asked Questions
What is an AS-SET?
An AS-SET is a set used to group autonomous systems and describe the networks associated with an operator. This information can be used to determine which prefixes should be accepted from its BGP neighbors.
What changes in PeeringDB 2.82.0?
PeeringDB introduces a format that also identifies the source IRR through a syntax such as RIR::AS-SET. Version 2.82.0 was released on August 19, 2026.
Why does specifying the IRR matter?
Because the same AS-SET name can exist in different IRRs. Without identifying the source, an automated application may not know which registry to query.
Do PeeringDB records need to be updated?
PeeringDB is automatically fixing some AS-SETs that are already unambiguous and is contacting networks whose names remain ambiguous. Operators should review their records and update cases as needed.
For related coverage of how internet exchanges keep the core of the internet running, see how the internet’s core works today at the major IXPs and how AMS-IX route servers recently crossed the half-million IPv4 routes mark.
