PeeringDB a introduit dans sa version 2.82.0 une modification qui peut sembler mineure dans le formulaire d’une réseau, mais qui a des conséquences directes pour l’automatisation des services d’interconnexion. Le champ AS-SET abandonne le format ambigu et indique désormais également l’enregistrement de l’Internet Routing Registry (IRR) d’origine, avec une syntaxe comme RIPE::AS5405:AS-INTERDOTLINK. Ce changement vise à permettre aux outils de savoir avec précision quel ensemble de routes consulter, sans devoir deviner parmi plusieurs sources possibles.

Les clés des AS-SET de PeeringDB en 20 secondes

• PeeringDB 2.82.0 a été publié le 19 août 2026 et inclut la mise à jour concernant les AS-SET.
• Le nouveau format ajoute le RIR devant le nom : RIR::AS-SET.
• L’objectif est d’éliminer les ambiguïtés lorsque le même AS-SET apparaît dans différents IRR.
• PeeringDB corrige automatiquement certains noms identifiés comme uniques et avertit les réseaux qui doivent modifier ceux qui sont ambigus.
• Ce changement concerne particulièrement les systèmes automatisant les inscriptions, la configuration de services et les politiques de routage.

Le problème trouve son origine dans une caractéristique répandue d’Internet : une grande partie des informations utilisées par les opérateurs provient de bases de données maintenues par différentes organisations. Un AS-SET sert à regrouper des systèmes autonomes (AS) et à décrire, entre autres, quelles réseaux ou préfixes peuvent être trouvés derrière un opérateur.

Jusqu’à présent, PeeringDB permettait d’inscrire le nom d’un AS-SET sous forme de texte sans obliger à indiquer la source IRR. Pour une personne connaissant le réseau, il était souvent possible de l’identifier. Pour un système automatisé, ce n’était pas toujours le cas.

PeeringDB est conscient de cette problématique. Sa documentation explique que certains AS-SET ne portent pas le numéro de l’AS dans leur nom, et que certains ensembles peuvent être publiés dans plusieurs IRR. Lorsqu’un nom ambigu existe, une organisation souhaitant automatiser la création d’un service doit déterminer manuellement quel AS-SET est le bon.

Un nom qui peut signifier plusieurs choses

Illustrons cela avec un exemple.

Un opérateur peut utiliser un AS-SET appelé AS-GENERICISP. Si ce même nom apparaît dans différents IRR, un logiciel rencontrant AS-GENERICISP dans PeeringDB n’a pas assez d’informations pour savoir dans quel enregistrement il doit puiser.

Le contexte semble correct, mais il manque des précisions pour permettre une automatisation fiable.

C’est cette problématique que décrit Stefan Funke, d’Inter.link, dans sa présentation du changement. La société utilise les informations de PeeringDB pour automatiser une partie de la configuration des services de transit IP. Si le AS-SET ne désigne pas avec précision sa source, le système doit choisir parmi plusieurs options ou demander une intervention humaine.

C’est le fameux problème du garbage in, garbage out : si la donnée d’entrée ne désigne pas correctement la provenance, une automatisation peut traiter la donnée parfaitement, mais produire une configuration erronée.

Ce que peeringDB ne prétend pas changer, c’est de garantir qu’un AS-SET est réellement adapté à une certaine réseau. La base de données reste maintenue par ses utilisateurs. La nouveauté consiste à pouvoir exprimer de façon non équivoque quelle source IRR doit être utilisée.

La syntaxe choisie est :

IRR::AS-SET

Par exemple, un enregistrement comme :

RIPE::AS5405:AS-INTERDOTLINK

indique que le AS-SET doit être recherché dans la base IRR de RIPE.

PeeringDB commence à corriger les enregistrements existants

La version 2.82.0 a été déployée le 19 août 2026 et inclut notamment le traitement associé au ticket #1973, intitulé « Forcer les réseaux à publier des AS-SET de façon non ambiguë ». PeeringDB précise que cette mise à jour intègre un éditeur intelligent pour les noms d’AS-SET, et qu’elle a commencé à corriger de façon proactive ceux dont le nom est déjà univoque.

Ce processus ne consiste pas simplement à ajouter du texte à tous les enregistrements.

PeeringDB explique que, lorsqu’un AS-SET est déjà unique, il peut identifier automatiquement le bon IRR et ajouter le préfixe. En revanche, pour les noms ambigus, l’organisation doit contacter les responsables des réseaux pour qu’ils mettent à jour leurs données.

Une validation intégrée dans l’éditeur vérifie aussi que le AS-SET indiqué existe bien dans l’IRR choisi. Ainsi, le formulaire ne se contente pas d’une chaîne de caractères, il valide la cohérence entre le nom et la source.

Ce changement fait suite à d’autres améliorations visant la qualité des données. En version 2.80.0, PeeringDB a abandonné le format alternatif avec un suffixe comme AS64496@IRR au profit de la notation avec le IRR en préfixe, par exemple IRR::AS64496.

L’objectif est clair : que les outils puissent interpréter le contenu du champ sans avoir à appliquer leurs propres règles pour déterminer l’intention de l’opérateur.

Pourquoi cette évolution est essentielle pour l’automatisation des réseaux

L’impact devient évident lorsque PeeringDB cesse d’être consulté par un humain et sert directement un système automatisé.

La base de données rassemble des informations de dizaines de milliers d’organisations, qui servent de référence pour les décisions d’interconnexion. PeeringDB est présenté comme une plateforme communautaire, facilitant l’interconnexion dans des points d’échange Internet (IXP), des centres de données et autres installations.

Pour une entreprise configurant manuellement chaque connexion, une ambiguïté peut être levée en demandant directement au client ou en consultant plusieurs enregistrements.

Dans un processus automatisé, cette étape humaine compromet le gain d’efficacité recherché.

Ce scénario peut se produire lors de l’intégration d’un client de transit IP. Le client fournit son numéro ASN, le système consulte PeeringDB, récupère son AS-SET et l’utilise pour construire ou vérifier sa configuration routière. Si le nom de l’AS-SET apparaît dans plusieurs IRR, le logiciel ne peut pas choisir seul le registre à utiliser.

Le nouveau format apporte donc une information qui manquait auparavant.

Il ne transforme pas PeeringDB en une source infaillible, ni ne garantit la correction des données par chaque opérateur. Mais il permet de réduire une classe spécifique d’ambiguïtés, particulièrement problématiques pour les outils automatiques.

Et cette évolution est essentielle à une époque où les opérateurs automatisent de plus en plus les tâches liées au BGP, à l’admission de clients, à la configuration de services et à la validation de routes.

Une petite modification pour l’opérateur, mais une grande différence pour les machines

Pour un réseau où le registre est déjà correct et unique, la mise à jour peut être simple. L’opérateur doit vérifier le registre dans PeeringDB et s’assurer que son AS-SET identifie aussi la source IRR.

PeeringDB informe ses membres dont les noms restent ambigus qu’ils doivent faire cette mise à jour. L’organisation elle-même reconnait que la tâche ne s’arrête pas à la version 2.82.0 et qu’elle continuera à surveiller la qualité des données.

L’importance de ce changement est souvent peu visible, car il n’impacte pas directement la performance d’une connexion, ne nécessite pas d’augmentation de bande passante, et ne modifie pas le protocole BGP.

Mais il modifie un aspect moins visible : la capacité des systèmes à interpréter automatiquement les informations d’Internet sans intervention humaine.

Ce détail peut faire la différence lorsqu’une plateforme cherche à automatiser tout, depuis la création d’un client jusqu’à la configuration de son service.

D’ailleurs, l’historique récent de PeeringDB montre que la qualité des données devient une priorité du projet. La plateforme compte plus de 34 000 organisations enregistrées et met en place des mécanismes pour normaliser et valider les données utilisées par les opérateurs et outils externes.

Pour les opérateurs, la recommandation est simple : vérifier les enregistrements de PeeringDB et mettre à jour les AS-SET vers le nouveau format si nécessaire.

Pour ceux qui construisent des automatisations autour de PeeringDB, cette évolution ouvre davantage de possibilités. Un champ qui nécessitait auparavant heuristiques ou intervention humaine commence à fournir les éléments pour faire une sélection déterministe de la source de données.

Dans une infrastructure Internet de plus en plus automatisée, la différence entre “il semble que ce registre” et “voici le registre à consulter” est bien plus significative qu’il n’y paraît.

Questions fréquentes

Qu’est-ce qu’un AS-SET ?

Un AS-SET est un ensemble utilisé pour regrouper des systèmes autonomes et décrire les réseaux d’un opérateur. Ces informations permettent notamment de déterminer quels préfixes accepter de ses voisins BGP.

Que change dans PeeringDB 2.82.0 ?

PeeringDB introduit un format qui identifie aussi l’IRR d’origine, avec une syntaxe comme RIR::AS-SET. La version 2.82.0 a été publiée le 19 août 2026.

Pourquoi est-il important d’indiquer la source IRR ?

Parce qu’un même nom d’AS-SET peut apparaître dans plusieurs IRR. Sans identifier la source, une application automatisée peut ne pas savoir quel enregistrement consulter.

Faut-il mettre à jour les enregistrements dans PeeringDB ?

PeeringDB corrige automatiquement certains AS-SET déjà univoques et contacte les réseaux dont les noms restent ambigus. Les opérateurs sont invités à vérifier leurs enregistrements et à faire les mises à jour nécessaires.