Resumen

  • El registro routing-status de RIPEstat para AS211386, con query_time 2026-10-17T16:00:00, indica que 0 de 328 pares IPv4 del RIS y 0 de 318 pares IPv6 ven el número de AS, con 0 prefijos IPv4 e IPv6 anunciados y 0 vecinos observados.
  • La capa de identidad sí devuelve algo: una cadena de titular LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. y un registro de red en PeeringDB con id 26805 y org_id 791 bajo el nombre LINX MAPS.
  • El objeto aut-num, su representación RDAP y una consulta de objetos de ruta no devolvieron texto el 2026-10-18, así que esos registros están sin leer, no vacíos.

Un número con dos nombres encima

La llamada AS-overview de RIPEstat para AS211386 devuelve un único campo de atribución, holder, que dice LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. (registro AS-overview). PeeringDB, consultado por separado sobre el mismo número, devuelve un objeto de red con id 26805, org_id 791, name LINX MAPS, asn 211386 y status ok (consulta de red en PeeringDB). Esa segunda respuesta llegó truncada, con puntos suspensivos en lugar de campos que este artículo no usa; los cinco valores citados aquí son todo lo que aporta el registro.

Dos catálogos, un número, nombres que apuntan ambos a London Internet Exchange y uno de los cuales añade Azure. Esa es toda la base sobre la que el número puede describirse como ligado a un operador de punto de intercambio y a una plataforma de nube. Una cadena de titular es una atribución dentro de un producto de datos; no es una descripción de servicio, ni un documento de estructura societaria, ni la afirmación de que una función esté operando. Ningún documento obtenido para este artículo describe una relación entre London Internet Exchange y Microsoft, y aquí no se afirma ninguna. La ficha de directorio AZURE London Internet Exchange Ltd. repite el nombre; la repetición entre catálogos no corrobora la operación.

Lo que midieron los colectores

El registro routing-status de RIPEstat para AS211386 lleva query_time 2026-10-17T16:00:00 (registro routing-status). Informa de 0 de 328 pares IPv4 del RIS que ven el número de AS y 0 de 318 pares IPv6. El espacio anunciado es de 0 prefijos IPv4 y 0 direcciones IPv4, 0 prefijos IPv6 y 0 /48 IPv6. Los objetos first_seen y last_seen están vacíos, y observed_neighbours es 0. Un objeto first_seen vacío significa que el sistema RIS no tiene ninguna primera observación de este origen; eso es una afirmación sobre el archivo del colector, no sobre el mundo.

La llamada announced-prefixes para el mismo número devuelve una lista vacía para la ventana 2026-10-03T16:00:00 a 2026-10-17T16:00:00, con latest_time 2026-10-17T16:00:00 y un earliest_time de archivo de 2000-08-01T00:00:00 (registro announced-prefixes). Esa respuesta lleva su propio límite en el cuerpo: los resultados excluyen rutas de visibilidad muy baja, definidas como vistas por menos de 10 pares RIS de feed completo. La lista vacía está por tanto acotada dos veces, por una ventana de dos semanas y por un umbral de visibilidad, y no puede leerse como prueba de que nunca se anunció nada. Lo que sí establece es más estrecho y sigue siendo útil: sobre una red de colectores de 328 puntos de vista IPv4 y 318 IPv6, dentro de la ventana registrada, ningún prefijo originado por AS211386 superó ese umbral.

La adyacencia confirma la misma forma. La llamada asn-neighbours de RIPEstat devuelve neighbour_counts de left 0, right 0, unique 0 y uncertain 0, con un arreglo neighbours vacío (registro asn-neighbours). Un hablante sin vecinos observados no tiene rutas observadas en ningún sentido; no participa en la topología que los colectores pueden ver.

Dónde se detiene la lectura

Tres lecturas de registro fallaron el 2026-10-18, y su fallo forma parte del hallazgo, no de una nota al pie. La petición REST de la base de datos RIPE para el aut-num AS211386 no devolvió texto de objeto (petición aut-num), así que el estado del objeto, su organización patrocinadora, su mantenedor y sus atributos de creación y última modificación siguen sin establecerse. La representación RDAP del mismo objeto era inaccesible en el momento de la consulta (petición RDAP). La consulta REST de objetos de ruta con origen AS211386 devolvió un fallo de acceso (consulta de objetos de ruta). La existencia de objetos route o route6 bajo este origen queda por tanto sin verificar, y este artículo no afirma ni su presencia ni su ausencia.

Otras dos ausencias pertenecen a este apartado. No se obtuvo ningún certificado de recursos RPKI ni ROA que cubra AS211386, y no se obtuvo ningún as-set de IRR, texto de política de aut-num ni entrada de política de peering, así que nada se dice sobre las intenciones de seguridad de enrutamiento o de política asociadas al número. Tampoco se obtuvo ningún documento publicado por London Internet Exchange o por Microsoft que describa un servidor de rutas operado dentro de Azure; la función que implica la cadena de titular sigue sin confirmarse. Son huecos de esta lectura, fechados el 2026-10-18, no hallazgos sobre los registros subyacentes.

Qué cambia el hueco

La consecuencia práctica se refiere a qué pregunta responde un registro. Una inscripción aut-num dice quién está facultado para actuar por un número; no dice que exista tráfico. Para un operador que aplica filtros de prefijos basados en IRR o validación RPKI, son entradas distintas con modos de fallo distintos, y un número que aparece en un registro sin anunciar nada es un caso corriente, no una contradicción.

La distinción solo resulta cara cuando un proceso de compra o de diligencia trata la presencia de un registro como prueba de una superficie operativa —una presencia en un punto de intercambio, una conexión a nube, un servidor de rutas— y se detiene ahí.

Para AS211386 los dos registros discrepan de forma concreta y medible: la capa de identidad devuelve un nombre y una entrada en PeeringDB, y la capa de observación devuelve ceros con denominadores adjuntos. Nada de lo obtenido muestra el número transportando tráfico a 2026-10-17T16:00:00, y nada de lo obtenido muestra que nunca lo hiciera.

Qué cambiaría esta lectura

La lectura es refutable por medios ordinarios, que es la propiedad útil de una medición. Una lista announced-prefixes no vacía, un ris_peers_seeing distinto de cero, un first_seen o un last_seen poblado, o un recuento de vecinos distinto de cero romperían cada uno la conclusión, y cualquiera de ellos podría aparecer en la próxima ventana sin contradecir nada de lo observado aquí. Lo que no la cambiaría es otra entrada de catálogo: una segunda ficha de directorio, una descripción en una base de terceros o un nombre que se lea como un despliegue. Eso añade nombres, no rutas.

Por ahora el número es una inscripción con una atribución, un registro en PeeringDB y ninguna ruta observada a 2026-10-17T16:00:00. La pregunta que el registro no puede responder es la que un comprador suele querer resuelta —si la cosa nombrada en el campo holder ha operado alguna vez— y la forma honesta de la respuesta es que la lectura se detuvo en tres consultas fallidas el 2026-10-18 y en un umbral de visibilidad de 10 pares de feed completo.