Resumen

  • RIPE NCC registró a las 15:55:39 CET del 3 de noviembre que investigaba acceso intermitente a información de recursos en el LIR Portal y a las 16:50:45 marcó el caso resuelto. El intervalo entre avisos ronda 55 minutos.
  • A las 17:17 publicó la causa operativa: la conmutación del balanceador afectó a aplicaciones que usan la base de datos; limpiar conexiones caducadas mitigó el problema. Revisará la configuración del conjunto de conexiones y mejorará su vigilancia.

Una ruta de respaldo puede existir y aun así no llevar a nadie a destino. El parte de RIPE NCC cuenta una avería de esa clase. Tras una conmutación del balanceador de carga, aplicaciones que utilizaban la base de datos seguían con conexiones obsoletas. El equipo las limpió para restablecer el acceso a información de recursos desde el portal. El detalle decisivo no es que hubiera un segundo camino, sino que la aplicación continuaba mirando al anterior.

Las marcas de tiempo públicas fijan la secuencia. El registro de la API sitúa la investigación a las 15:55:39.649 y la resolución a las 16:50:45.437, hora central europea. Entre ambas hay 55 minutos y casi seis segundos. RIPE NCC no publicó una serie de errores por solicitud. Por ello, esos 55 minutos describen el tramo entre dos comunicaciones, no cuánto tiempo estuvo sin acceso cada miembro.

¿Por qué importa una pantalla de recursos? Porque desde el LIR Portal los miembros consultan sus bloques IPv4 e IPv6 y sus números de sistema autónomo. RIPE NCC explicó en octubre que prepara una vista My Resources con jerarquías, datos de registro, utilización, objetos de la base RIPE e información de encaminamiento. Esa nueva experiencia seguía en desarrollo y pruebas. La explicación de su propósito basta para mostrar el peso del acceso actual: quien administra direcciones necesita verlas y entender cómo están registradas.

El incidente expone dos capas de responsabilidad. Una institución puede conservar el registro y, durante un fallo de la vía de consulta, impedir que su miembro lo lea. En el relato oficial, la avería está en el enlace entre la conmutación y las conexiones que mantiene la aplicación. Limpiar las conexiones resolvió lo inmediato; una etiqueta verde en el balanceador por sí sola no habría respondido la pregunta del usuario. La redundancia se compra como continuidad del servicio, no como fotografía de dos máquinas.

RIPE NCC anunció dos tareas distintas. Ajustar la configuración de las conexiones agrupadas busca que la aplicación descarte sesiones que ya no llegan a la base. Vigilar mejor su uso busca detectar cuándo sigue intentándolo. Una cambia la conducta; la otra permite comprobarla. Faltan el motivo de la conmutación, el número de miembros y solicitudes afectados y una prueba posterior desde el portal. Esos datos permitirían medir el alcance y verificar el arreglo.

El parte deja una conclusión concreta: el acceso volvió tras retirar conexiones caducadas. La próxima conmutación dirá si el problema quedó resuelto en la arquitectura o si solo se despejó manualmente una tarde.

Fuentes originales de RIPE NCC