Resumen

  • Un mensaje de la lista AfNOG publicado el 20 de julio a las 10:48 UTC aportó una orden que deja a la vista los duplicados de as-TelOneZW.
  • Una consulta nueva a AFRINIC confirmó 24 líneas members: y 21 ASN únicos: AS37183 aparece tres veces y AS37123, dos.
  • Según la semántica de conjuntos de RPSL, esas repeticiones no añaden miembros distintos. Tampoco prueban una caída, una fuga de rutas ni el rechazo de un prefijo.
  • AFRINIC explica que proveedores de tránsito y redes aguas arriba consultan los IRR para actualizar filtros; por eso la redundancia es una señal de mantenimiento, aunque no sea un incidente.

La lista creció en tres líneas. La política no ganó tres redes.

Esa diferencia resume el mensaje que S. Moonesamy publicó el lunes en la lista del African Network Operators Group. El autor consultó el WHOIS de AFRINIC, ordenó los miembros de as-TelOneZW y colocó primero los valores repetidos. AS37183 salió tres veces; AS37123, dos.

No atribuyó una causa. De hecho, escribió que probablemente habría una explicación plausible, sin decir cuál. Una verificación de BTW posterior al mensaje reprodujo el estado vivo: 24 declaraciones para 21 números de AS distintos. El objeto se describe como “TelOne ASNs”, está asociado al mantenedor AS8668-MAINTAINER y declara AFRINIC como fuente.

No es una noticia sobre indisponibilidad. Es un ejemplo concreto de un registro de política que contiene más texto que miembros efectivos.

Una repetición textual no crea otro miembro

El RFC 2622 define un as-set como un conjunto cuyo atributo members enumera números de AS u otros conjuntos. Dentro de esa lógica, tres apariciones de AS37183 siguen representando un solo sistema autónomo. Lo mismo ocurre con las dos de AS37123. El resultado único permanece en 21.

Por tanto, la conclusión inmediata debe ser contenida. Ni el correo de AfNOG ni el registro actual documentan rutas descartadas, orígenes incorrectos, cambios de tráfico o configuraciones rotas. Una expansión que respete la semántica de conjunto no debería obtener un ASN nuevo de una copia redundante.

Eso no autoriza a suponer que todos los programas conservan la misma representación. Algunos normalizarán los miembros antes de generar una configuración; otros podrán arrastrar las filas crudas a archivos intermedios, diferencias, informes o paneles. La prueba demuestra redundancia en la entrada, no el comportamiento de todos los analizadores.

Además, los dos ASN corresponden a entidades diferentes. Los registros de AFRINIC identifican AS37183 con Utande Internet Services (Pvt) Ltd y AS37123 con Telecontract Pvt Ltd, ambas en Zimbabue. Estar dentro de un conjunto rotulado con TelOne no demuestra por sí solo propiedad, filialidad ni la relación comercial vigente. Un AS-set expresa alcance de política de rutas, no estructura societaria.

El valor está en lo que la anomalía permite preguntar

Los objetos de un Internet Routing Registry se encuentran en la frontera entre una declaración operativa y los sistemas capaces de convertirla en controles. RPSL nació para describir políticas a nivel de AS con detalle suficiente para contribuir a configuraciones de routers. La guía pública de AFRINIC añade que proveedores aguas arriba y de tránsito consultan los registros para actualizar filtros y mantener consistencia en la información BGP.

El duplicado no demuestra que esos filtros estén equivocados. Sí demuestra que su materia prima puede degradarse sin modificar el resultado matemático.

Una anomalía tan pequeña puede ser un buen indicador precisamente porque suele ser inocua. Una copia extra puede sugerir un proceso que añade sin reconciliar, dos vías administrativas que tocaron el mismo objeto o la ausencia de una validación final. Nada de eso está probado aquí: el mensaje no aporta historial de cambios ni análisis de causa.

La pregunta correcta no es si las repeticiones derribaron Internet. Es qué otra equivocación podría atravesar el mismo proceso. Un ASN válido repetido es tolerante. Un miembro obsoleto, una ausencia o un conjunto anidado accidental no tendrían por qué serlo.

Limpiar exige verificar primero la intención

El mantenedor debería comenzar por confirmar si los 21 miembros únicos siguen dentro del alcance previsto. Después puede identificar cómo entraron las tres líneas redundantes y publicar una versión limpia si corresponde. Borrar copias sin comprobar el conjunto pretendido mejora la apariencia, pero no valida la política.

También conviene separar dos controles: el de la representación y el de la expansión. El primero compara líneas crudas con miembros directos únicos. El segundo expande conjuntos anidados, registra cambios y distingue alertas por duplicados, objetos ausentes, adiciones inesperadas o fallos de resolución. La documentación de RIPE sobre consultas de miembros muestra por qué la recursividad necesita una prueba propia: el resultado completo puede depender de objetos que no aparecen en la ficha inicial.

Por último, una red que genere filtros desde un IRR debería conservar la procedencia del artefacto: registro consultado, momento, método de expansión y estado de revisión. Esa información no convierte el IRR en una autoridad infalible, pero permite rastrear una entrada defectuosa.

El mensaje de AfNOG ofrece así una comprobación barata y útil. Las tres líneas de más dejan intactos los 21 miembros. A cambio, revelan si el mantenimiento de la política reconcilia, revisa y observa sus datos antes de que aparezca un error con consecuencias menos benignas.

Fuentes