PeeringDB ha introducido en su versión 2.82.0 un cambio que puede parecer pequeño en el formulario de una red, pero que tiene consecuencias directas para la automatización de servicios de interconexión. El campo AS-SET deja atrás el formato ambiguo y pasa a identificar también el registro de Internet Routing Registry (IRR) de origen mediante una sintaxis como RIPE::AS5405:AS-INTERDOTLINK. El cambio busca que las herramientas puedan saber exactamente qué conjunto de rutas deben consultar sin tener que adivinar entre varias fuentes posibles.

Las claves de los AS-SET de PeeringDB en 20 segundos

• PeeringDB 2.82.0 se publicó el 19 de agosto de 2026 e incorpora el cambio en los AS-SET.
• El nuevo formato añade el IRR delante del nombre: RIR::AS-SET.
• El objetivo es eliminar ambigüedades cuando un mismo AS-SET aparece en diferentes registros IRR.
• PeeringDB está corrigiendo automáticamente algunos nombres únicos y avisando a las redes que deben modificar los ambiguos.
• El cambio afecta especialmente a sistemas que automatizan altas, configuración de servicios y políticas de enrutamiento.

El problema tiene su origen en una característica bastante habitual de Internet: buena parte de la información que utilizan los operadores de red procede de bases de datos mantenidas por diferentes organizaciones. Un AS-SET sirve para agrupar sistemas autónomos (AS) y describir, entre otras cosas, qué redes o prefijos pueden encontrarse detrás de un operador.

Hasta ahora, PeeringDB permitía introducir el nombre del AS-SET como texto sin obligar a indicar de qué IRR procedía. Para una persona con conocimiento de la red, muchas veces era posible identificarlo. Para un sistema automatizado, no necesariamente.

PeeringDB reconoce precisamente este problema. En su documentación explica que algunos AS-SET no utilizan el número de AS en su nombre y que determinados conjuntos pueden estar publicados en más de un IRR. Cuando sucede, una organización que quiera automatizar el alta de un servicio necesita determinar manualmente qué AS-SET es el correcto.

El problema de un nombre que puede significar varias cosas

Un ejemplo ayuda a entenderlo.

Un operador puede utilizar un AS-SET denominado AS-GENERICISP. Si ese mismo nombre existe en diferentes IRR, una aplicación que encuentre AS-GENERICISP en PeeringDB no tiene suficiente información para saber qué registro debe consultar.

El dato parece válido, pero carece de contexto suficiente para automatizar una decisión con seguridad.

Ese es el escenario que describe Stefan Funke, de Inter.link, en su explicación sobre el cambio. La compañía utiliza información de PeeringDB para automatizar parte de la configuración de servicios de IP Transit. Si el AS-SET no identifica de forma inequívoca su fuente, el sistema tiene que elegir entre distintas posibilidades o pedir intervención humana.

Es el conocido problema de garbage in, garbage out: si el dato de entrada no identifica correctamente el origen, una automatización puede procesar perfectamente la información y aun así producir una configuración incorrecta.

PeeringDB no pretende resolver con este cambio si un AS-SET es realmente correcto para una determinada red. La base de datos continúa siendo mantenida por sus usuarios. Lo que cambia es la posibilidad de expresar de forma inequívoca qué IRR debe utilizarse.

La sintaxis elegida es:

IRR::AS-SET

Así, un registro como:

RIPE::AS5405:AS-INTERDOTLINK

indica que el AS-SET debe buscarse en el registro IRR de RIPE.

PeeringDB empieza a corregir los registros existentes

La versión 2.82.0 llegó el 19 de agosto de 2026 e incorporó específicamente el trabajo asociado al issue #1973, denominado “Force networks to publish as-sets unambiguously”. PeeringDB explica que el cambio incluye un editor inteligente para los nombres de AS-SET y que comenzó a corregir de forma proactiva aquellos conjuntos cuyo nombre era inequívoco.

El proceso no consiste simplemente en añadir texto a todos los registros.

PeeringDB ha explicado que, cuando un AS-SET ya es único, puede identificar automáticamente el IRR correspondiente y añadir el prefijo. En cambio, cuando existen nombres ambiguos, la organización necesita contactar con los responsables de las redes para que actualicen sus registros.

También se ha incorporado una validación en el editor para ayudar a comprobar que el AS-SET indicado existe en el IRR seleccionado. De esta manera, el formulario no solo recoge una cadena de texto, sino que puede comprobar que la combinación introducida tiene sentido.

El cambio llega después de otras modificaciones relacionadas con la calidad de estos datos. En la versión 2.80.0, PeeringDB eliminó el formato alternativo que utilizaba un sufijo como AS64496@IRR y pasó a favorecer la notación con el IRR como prefijo, por ejemplo IRR::AS64496.

La dirección es clara: que una aplicación pueda interpretar el campo sin tener que aplicar reglas propias para intentar descubrir qué quiso decir el operador.

Por qué importa para las redes que automatizan servicios

La consecuencia más interesante aparece cuando PeeringDB deja de ser consultado por una persona y pasa a alimentar directamente un sistema.

La base de datos reúne información de decenas de miles de organizaciones y se utiliza como referencia para decisiones de interconexión. PeeringDB describe la plataforma como una base de datos mantenida por la comunidad que facilita la interconexión entre redes en puntos neutros de intercambio de Internet (IXP), centros de datos y otras instalaciones.

Para una compañía que configura manualmente cada conexión, una ambigüedad puede resolverse preguntando al cliente o comprobando varios registros.

En una plataforma automatizada, ese paso humano rompe precisamente la ventaja de automatizar.

El escenario puede producirse durante el alta de un cliente de IP Transit. El cliente proporciona su número de sistema autónomo, el sistema consulta PeeringDB, recupera su AS-SET y utiliza esa información para construir o validar la configuración relacionada con sus rutas. Si el nombre del AS-SET existe en diferentes IRR, la aplicación no puede determinar por sí misma cuál debe utilizar.

El nuevo formato aporta una pieza de información que antes podía faltar.

No convierte PeeringDB en una fuente infalible. Tampoco garantiza que el contenido introducido por cada operador sea correcto. Lo que hace es reducir una clase concreta de ambigüedad que resulta especialmente problemática para las herramientas automáticas.

Y esa diferencia es importante en un momento en el que los operadores están automatizando cada vez más tareas relacionadas con BGP, altas de clientes, configuración de servicios y validación de rutas.

El cambio es pequeño para el operador, pero importante para las máquinas

Para una red que ya tiene un registro correcto y único, la modificación puede ser relativamente sencilla. El operador debe revisar el registro de PeeringDB y comprobar que su AS-SET identifica también el IRR correspondiente.

PeeringDB está notificando a las organizaciones cuyos nombres siguen siendo ambiguos para que realicen esa actualización. La propia organización reconoce que el trabajo no termina con la versión 2.82.0 y que seguirá supervisando la calidad de los datos.

La importancia de este tipo de cambios suele pasar desapercibida porque no afecta directamente al rendimiento de una conexión, no aumenta el ancho de banda de un puerto y tampoco cambia el protocolo BGP.

Pero sí modifica algo menos visible: la capacidad de los sistemas para interpretar automáticamente la información de Internet sin intervención humana.

Ese detalle puede marcar la diferencia cuando una plataforma pretende automatizar desde el alta de un cliente hasta la configuración de su servicio.

El propio historial reciente de PeeringDB muestra que la calidad de los datos se está convirtiendo en una prioridad del proyecto. La plataforma cuenta con más de 34.000 organizaciones registradas y está introduciendo mecanismos para normalizar y validar información que posteriormente utilizan operadores y herramientas externas.

Para los operadores, la recomendación es sencilla: revisar los registros de PeeringDB y actualizar los AS-SET al nuevo formato cuando sea necesario.

Para quienes construyen automatizaciones alrededor de PeeringDB, el cambio tiene más recorrido. Un campo que antes podía requerir heurísticas o intervención humana empieza a proporcionar la información necesaria para seleccionar de forma determinista la fuente de datos.

En una infraestructura de Internet cada vez más automatizada, esa diferencia entre “parece ser este registro” y “este es el registro que debe consultarse” es mucho más importante de lo que aparenta.

Preguntas frecuentes

¿Qué es un AS-SET?

Un AS-SET es un conjunto utilizado para agrupar sistemas autónomos y describir las redes asociadas a un operador. Esta información puede utilizarse para determinar qué prefijos deberían aceptarse de sus vecinos BGP.

¿Qué cambia en PeeringDB 2.82.0?

PeeringDB introduce un formato que identifica también el IRR de origen mediante una sintaxis como RIR::AS-SET. La versión 2.82.0 se publicó el 19 de agosto de 2026.

¿Por qué importa indicar el IRR?

Porque un mismo nombre de AS-SET puede existir en diferentes IRR. Sin identificar la fuente, una aplicación automatizada puede no saber qué registro debe consultar.

¿Hay que actualizar los registros de PeeringDB?

PeeringDB está corrigiendo automáticamente algunos AS-SET que ya son inequívocos y está contactando con las redes cuyos nombres siguen siendo ambiguos. Los operadores deberían revisar sus registros y actualizar los casos que correspondan.