Resumen

  • La evidencia disponible identifica fuentes para probar visibilidad BGP, rutas anunciadas, vecinos, sondas y relaciones de interconexión, pero no establece un apagón concreto ni una recuperación atribuible.
  • Una conclusión sobre continuidad exigiría unir una retirada y reanuncio con marca temporal, una señal independiente de alcance o sondeo, cambios de camino observados y evidencia contemporánea del operador o de terceros.

La primera distinción es entre visibilidad de enrutamiento y disponibilidad del servicio. RIPEstat puede mostrar durante qué intervalos los prefijos originados por AS210860 fueron visibles para los colectores participantes. Una pérdida sincronizada de visibilidad, seguida por un nuevo periodo de anuncios, sería compatible con una secuencia de retirada y reanuncio. No identificaría por sí sola la causa: podría tratarse de mantenimiento, una sesión BGP caída, una falla de tránsito, filtrado, una modificación deliberada o una limitación de los colectores. La propia historia de enrutamiento debe leerse con esa cautela (historial de enrutamiento de RIPEstat).

El segundo nivel son las actualizaciones BGP. Una consulta acotada a un intervalo podría revelar si las retiradas precedieron a anuncios nuevos y si el retorno pasó por los mismos sistemas autónomos vecinos. Las marcas temporales no son una hora global del incidente: cada colector y cada vecino puede observar el cambio en momentos distintos. Además, el retorno de una ruta al plano de control no demuestra que las aplicaciones recuperaran conectividad. Las actualizaciones BGP son, por tanto, una prueba de cambio de estado de la ruta, no una medición completa de experiencia de usuario (actualizaciones BGP de RIPEstat).

El tercer nivel es la señal de alcance. IODA podría ayudar a comprobar si una caída de visibilidad coincidió con una pérdida de señales de BGP, sondeo activo u otras mediciones de interrupción. Una disminución de BGP sin una disminución equivalente en sondeos podría indicar un cambio de observación o de camino, no una pérdida total de accesibilidad. A la inversa, una caída coincidente en varias señales sería más consistente con un problema de alcance, aunque tampoco identificaría automáticamente al responsable de la reparación (señales de IODA para AS210860).

Antes de interpretar una interrupción hay que saber qué se estaba anunciando. El inventario de prefijos de RIPEstat permitiría separar una desaparición completa del sistema autónomo de la retirada de un único prefijo. Un prefijo visto por un colector puede estar ausente en otro; un estado de última observación no equivale a disponibilidad actual. La pregunta relevante es si el evento afecta a toda la superficie anunciada o solo a una ruta concreta (prefijos anunciados por AS210860).

La continuidad también depende de la diversidad de caminos. Los vecinos observados de AS210860 pueden indicar más de una vía externa. Si los anuncios reaparecieran mediante un vecino distinto después de una pérdida sincronizada, eso sería compatible con una interpretación de conmutación por error. Pero un vecino BGP observado no es necesariamente un proveedor contractual, y las inferencias pueden mezclar tránsito, peering, servidores de rutas o visibilidad parcial. La topología describe una posibilidad de resiliencia; no prueba que el mecanismo haya funcionado durante un incidente (vecinos ASN de RIPEstat).

Las sondas de RIPE Atlas aportarían una capa distinta: datos del plano de datos separados de los colectores BGP. Una desconexión y reconexión de una sonda asociada con AS210860 podría corroborar una pérdida y recuperación, pero solo después de descartar que la propia sonda hubiera perdido energía o conectividad local. La ausencia de una sonda no demuestra la ausencia de monitorización ni de servicio. Las consultas IPv4 e IPv6 deben tratarse como pruebas potenciales, no como evidencia de que existió una sonda operativa (sondas IPv4 de RIPE Atlas; sondas IPv6 de RIPE Atlas).

PeeringDB puede aportar otra pieza: nombre de red autopublicado, política de peering, instalaciones, intercambios, contactos o un sitio operativo. Varias instalaciones o conexiones declaradas podrían documentar un diseño previsto de resiliencia. No demuestran que esas conexiones estuvieran activas durante una interrupción ni que la entidad registral controlara la recuperación. Su valor principal en esta investigación es conducir hacia una posible notificación de mantenimiento, página de estado, informe de incidente o contacto operativo que pueda contrastarse con las mediciones (registro de PeeringDB para AS210860).

Los registros de RIPE ayudan a definir la atribución, pero no la completan. El objeto aut-num puede mostrar la asociación de nombre, el identificador de organización, los mantenedores y políticas declaradas de importación o exportación. Esas políticas describen una intención administrativa y pueden estar desactualizadas o incompletas. No prueban que una persona o empresa concreta operara una sesión BGP durante un evento, ni que detectara o reparara una falla (objeto aut-num de RIPE).

Los objetos route y route6 pueden mostrar prefijos autorizados, mantenedores y fechas de modificación. Una modificación cercana a un cambio observado podría ser relevante, pero solo después de demostrar que ambos hechos pertenecen a la misma ruta y al mismo intervalo. Una modificación de base de datos también puede ser mantenimiento rutinario. La autorización IRR no demuestra que el prefijo fuera anunciado ni quién tomó una decisión operativa (búsqueda de objetos route y route6).

Los agregadores de BGP, CAIDA y las páginas públicas de AS210860 pueden servir para contrastar prefijos, relaciones y estado RPKI. La coincidencia entre varias fuentes reduciría el riesgo de atribuir a un solo colector una señal espuria. Sin embargo, una instantánea actual no reconstruye la secuencia de un incidente anterior; tampoco convierte el estado RPKI en prueba de disponibilidad. RPKI puede ayudar a proteger la autorización del origen, pero no crea automáticamente rutas alternativas ni garantiza recuperación (bgp.tools; CAIDA AS Rank; BGP Toolkit de Hurricane Electric).

Por eso, el resultado de esta revisión es deliberadamente limitado. La evidencia disponible permite diseñar una prueba de continuidad, no afirmar que DFINFRA controle la continuidad de AS210860. Para cerrar esa brecha habría que observar, dentro de un intervalo definido, una retirada relevante y un reanuncio; confirmar una señal independiente de alcance; identificar cambios de camino y vecinos; y encontrar una evidencia contemporánea del operador, un postmortem, una notificación de mantenimiento o un informe independiente.

Sin esa combinación, el registro de DFINFRA sigue siendo un punto de partida investigativo, no una atribución de operación.

Qué debe observarse después

La próxima comprobación debería comenzar con el inventario de prefijos y sus intervalos visibles. Después habría que consultar actualizaciones BGP en una ventana estrecha, comparar colectores y vecinos, y alinear los resultados con señales de IODA o RIPE Atlas. Solo entonces tendría sentido buscar una explicación operacional en PeeringDB, en los objetos de RIPE o en comunicaciones del operador. El orden importa: empezar por el nombre registrado invierte la cadena causal y puede convertir una pista administrativa en una conclusión técnica que las fuentes no sostienen.

La continuidad tiene además una dimensión de recuperación. Un sistema puede conservar rutas visibles mientras pierde capacidad de entrega; puede recuperar anuncios mediante un camino alternativo sin demostrar que la misma organización controla ese camino; o puede mantener autorizaciones RPKI válidas durante una interrupción total. Cada capa responde a una pregunta distinta: quién aparece en el registro, qué rutas se observan, qué origen está autorizado, qué camino existe, si hay respuesta desde el plano de datos y quién puede cambiar el estado. El artículo no encuentra todavía un actor que reúna todas esas capacidades.