Resumen

  • A las 09:19 CEST del 7 de septiembre, RIPE NCC dio por resuelto el incidente de RRC18 después de reiniciar dos servicios de backend, aunque indicó que la causa seguía sin aclararse y que continuaría investigando.
  • A las 09:33 CEST abrió el caso de RRC24: la publicación de archivos update y bview se había detenido, el síntoma se parecía al de RRC18, se sospechaba una raíz común no identificada y no se podían excluir otros RRC.

Entre ambos mensajes transcurrieron 801 segundos. La precisión seduce, pero también puede inducir a una historia que los datos no sostienen. No sabemos si RRC24 empezó a fallar después del cierre público de RRC18, ni si el reinicio tuvo relación con el segundo incidente. Las horas pertenecen a publicaciones del servicio de estado. Son una secuencia institucional verificable, no un cronómetro técnico de las averías.

La secuencia basta para plantear una cuestión más concreta. RIPE NCC utilizó «resuelto» para describir un servicio restaurado mientras, en la misma nota, dejaba abierta la causa. Catorce minutos después, otro aviso trasladó esa incertidumbre a un colector diferente y advirtió que el perímetro podía crecer.

Lo que dice el expediente de RRC18

El aviso inicial de RRC18 apareció el 4 de septiembre a las 18:14 CEST. RIPE NCC informó de que no se publicaban archivos RIS update ni bview. Señaló como último update updates.20260904.1335.gz y como último bview bview.20260904.0800.gz. Son marcas de los últimos objetos mencionados, no prueba del momento de detección, del número total de archivos afectados o de la situación de todos los accesos a RIS.

El 5 de septiembre la organización dijo que, pese a un análisis exhaustivo del procesamiento de mensajes de RRC18, no había identificado la raíz. Horas más tarde comunicó que se habían publicado los updates y bviews que faltaban, que el flujo de RRC18 estaba restablecido y que pasaba a vigilarlo. La resolución del día 7 añadió que dos servicios de backend se habían reiniciado. También mantuvo una reserva explícita: la causa seguía sin estar clara.

Así, el expediente contiene dos estados que el color final no distingue. El acceso a los objetos volvió. La explicación y la contención causal no habían terminado.

Un mismo síntoma en colectores distintos

Según la documentación oficial, RRC18 es un colector conectado a CATNIX en Barcelona, España. RRC24 es un colector multihop alojado en LACNIC, en Montevideo, Uruguay, y cubre un ámbito regional. Esas diferencias no prueban una causa compartida. Sí hacen que la hipótesis tenga valor operativo: si dos trayectorias visibles distintas dejan de publicar los mismos tipos de archivo, conviene identificar qué dependencia, despliegue o cohorte de conmutación comparten.

RIPE NCC fue prudente. El aviso de RRC24 afirmó que el problema «refleja» el de RRC18 y que se «sospecha» una raíz común todavía desconocida. También señaló que no podía descartar otros RRC durante las horas o días siguientes. La captura seguía marcada como investigación. No nombra los dos servicios reiniciados, una versión de software, un cambio de configuración ni una conmutación como causa.

Tampoco autoriza a hablar de rutas perdidas. RIS publica datos MRT por colector. Su documentación explica que los bviews representan un estado de encaminamiento y se generan cada ocho horas, mientras los updates recogen cambios cada cinco minutos. Que su publicación se detenga es relevante para quienes usan esos objetos como evidencia. No demuestra que BGP dejara de funcionar, que la captura se perdiera, que los archivos estuvieran corruptos o que todas las interfaces fallaran.

La defensa operativa más sólida

Recuperar primero e investigar después puede ser la decisión correcta. Mantener una publicación detenida mientras se busca una causa perfecta perjudicaría a los usuarios sin mejorar la evidencia. RIPE NCC repuso los archivos de RRC18, restauró su flujo, describió la acción tomada, reconoció que no conocía la causa, continuó el diagnóstico y comunicó tanto la posible relación con RRC24 como la posibilidad de un alcance mayor.

Además, dejar RRC18 en estado de incidente activo cuando el servicio ya funcionaba habría hecho menos preciso el panel. Una herramienta centrada en disponibilidad necesita poder decir que el servicio volvió. El problema aparece cuando esa es la única dimensión disponible: el verde de la operación puede ocultar que la investigación causal sigue abierta.

Por eso, la crítica proporcionada no es «no reinicie» ni «no cierre». Es «no use el mismo cierre para dos obligaciones distintas». El mensaje de RRC18 conservó la incertidumbre en una frase, pero sin un estado separado esa frase pierde visibilidad en cuanto la página se archiva.

Un recibo del dominio de fallo

La solución no exige revelar topología, nombres de máquinas ni configuraciones. RIPE NCC podría publicar un recibo mínimo unido al identificador del incidente y al colector. Incluiría la clase de síntoma, la acción de recuperación, la hora de restauración y un estado causal independiente.

Ese estado podría recorrer valores prudentes: no identificado, hipótesis abierta, respaldada, rechazada o confirmada. Si varios incidentes parecen conectados, un token estable y no sensible podría indicar una misma cohorte de despliegue, dependencia o failover. El recibo también fijaría el ámbito y el vencimiento de la vigilancia de recurrencias, el responsable, la fecha de cierre causal y las correcciones posteriores.

El objetivo no es etiquetar prematuramente. Es poder mantener simultáneamente dos afirmaciones: RRC18 volvió a publicar; la causa que podía conectar su síntoma con RRC24 aún no estaba resuelta. Si la investigación separa ambos casos, el historial puede rechazar la hipótesis. Si encuentra una capa común, puede vincularlos sin alterar los avisos originales.

Un incidente distinto del 25 de agosto indicó que unos bviews se habían generado pero no publicado por una mala configuración tras un failover, y reconoció una carencia de monitorización. Ese caso ya plantea la diferencia entre generación y entrega. No demuestra la causa de los episodios de septiembre y este artículo no adopta su remedio de control por archivo. La cuestión actual es otra: después de recuperar el servicio, ¿dónde queda visible la obligación de entender el dominio de fallo?

Fuentes