Cuando cambian los datos del registro, ¿por qué puede desaparecer una red que funciona?

Imagina que tu servicio sigue funcionando desde una conexión móvil, pero los clientes de otra red ya no pueden acceder a él. Los servidores funcionan correctamente. Los cables están conectados. Una posible explicación es que otra red haya dejado de aceptar la ruta hacia tus direcciones después de que cambiara un dato registral.

El eslabón que falta es la decisión entre el registro y el enrutador. Un cambio en una base de datos puede afectar a la conectividad cuando un sistema utiliza ese cambio para construir un filtro o evaluar un anuncio. Para entender el fallo, hay que seguir esa cadena. «El registro está mal» es solo el principio del diagnóstico.

Las conexiones físicas pueden seguir intactas cuando un cambio en los datos registrales afecta a la aceptación de rutas. Sigue las pruebas y la política de la red receptora.

Primero, pregunta qué dato cambió

Un prefijo IP es un bloque de direcciones. Un número de sistema autónomo, o ASN, identifica a una red que intercambia rutas con otras redes. BGP es el protocolo que utilizan esas redes para anunciar a qué destinos pueden llegar.

Junto a ese intercambio existen varios tipos de registros. Cada uno responde a preguntas diferentes:

• Datos de registro: qué organización figura asociada a un bloque de direcciones y con quién hay que ponerse en contacto. La documentación de la base de datos RIPE distingue entre el registro de recursos, la información de enrutamiento y los datos de contacto, aunque compartan una misma base de datos.
• Datos del Registro de Enrutamiento de Internet (IRR): información que los operadores pueden utilizar para elaborar listas de las rutas que aceptarán. Un registro describe el enrutamiento previsto; no anuncia por sí mismo una ruta.
• Datos de la Infraestructura de Clave Pública de Recursos (RPKI): incluyen autorizaciones firmadas de origen de ruta, denominadas ROA, a partir de las cuales los validadores generan datos para comprobar la red de origen y la longitud de prefijo permitida.

Una dirección de correo de contacto desactualizada no retira directamente una ruta BGP. Una ruta que falta en el filtro generado por un proveedor puede hacer que ese proveedor deje de aceptarla. Llamar a ambos casos «datos registrales no válidos» oculta la diferencia que importa.

Cómo un dato registral acaba convirtiéndose en una ruta rechazada

Pensemos en un proveedor que construye los filtros de sus clientes a partir de datos IRR. Esta es una posible secuencia de fallo:

1. Se elimina un registro de ruta o el conjunto de rutas del cliente deja de incluirlo.
2. La siguiente generación del filtro del proveedor omite esa ruta.
3. El nuevo filtro llega a los enrutadores del proveedor, que rechazan el anuncio del cliente.
4. Si no queda ninguna alternativa utilizable, las personas que dependen de ese camino pierden el acceso.

Para que se produzca esta cadena, los datos deben alimentar realmente ese filtro. La política sobre registros de enrutamiento publicada por NTT DATA ofrece un ejemplo concreto de filtros de clientes basados en IRR y actualizaciones automatizadas. También documenta el rechazo de rutas con estado RPKI Invalid y la exclusión de registros IRR en conflicto. Son mecanismos operativos identificables, no un interruptor universal en manos del registro.

Qué significa realmente «Invalid» en RPKI

Para validar el origen, la ruta anunciada se compara con datos de autorización validados. El RFC 6811 define tres resultados:

• Valid: al menos una autorización que cubre la ruta coincide con el ASN de origen y permite la longitud del prefijo anunciado.
• Invalid: existen datos de autorización que cubren la ruta, pero ninguno cumple ambas condiciones.
• NotFound: ningún dato de autorización cubre la ruta.

Por ejemplo, una ruta anunciada por la red A puede pasar al estado Invalid si desaparece la autorización correspondiente mientras permanece una autorización para la red B que cubre ese prefijo. Si no queda ninguna autorización que lo cubra, el resultado es NotFound. «Invalid» es aquí un resultado de validación del enrutamiento, no un veredicto sobre la titularidad o la legitimidad institucional. La validación del origen tampoco autentica todo el camino que una ruta afirma haber recorrido.

El siguiente paso depende de la política configurada por el operador. El RFC 8481 distingue entre establecer un estado de validación y actuar en función de él: el operador debe configurar la política. Una red configurada para rechazar rutas Invalid puede entonces rechazar este anuncio. Una modificación en el registro y un rechazo están conectados a través de ese mecanismo; no son el mismo hecho.

Por qué algunas personas pierden el acceso antes que otras

No todas las redes utilizan los mismos filtros, proveedores o datos al mismo tiempo. El RFC 7115 explica que las cachés RPKI pueden contener distintas vistas de los datos y que no existe un intervalo único garantizado para la llegada de las actualizaciones a los enrutadores.

En el ejemplo inicial, una red puede haber actuado ya sobre los datos modificados mientras otra sigue disponiendo de un camino aceptado. Eso hace posible una interrupción parcial. No demuestra que el registro haya causado una interrupción concreta: los ingenieros aún deben examinar la ruta afectada, los datos utilizados y la decisión que provocó su rechazo.

Encuentra el eslabón roto antes de cambiar más cosas

La pregunta útil para recuperar el servicio es concreta: ¿qué sistema dejó de aceptar qué anuncio y por qué? Un operador puede investigarlo junto con el proveedor:

1. Identificar el anuncio. Anotar el prefijo afectado y el ASN de origen, y comprobar si se sigue anunciando la ruta esperada.
2. Localizar el rechazo. Comparar el filtro instalado del proveedor y el resultado de validación con la ruta. Preguntar qué fuente de datos y qué actualización dieron lugar a esa decisión.
3. Conservar las pruebas. Guardar los datos pertinentes, las observaciones y las marcas de tiempo para poder distinguir una actualización errónea de un anuncio no autorizado.
4. Corregir y verificar. Coordinar la corrección exacta del dato o de la configuración, confirmar que ha llegado a los sistemas que la utilizan y probar el acceso desde las redes que fallaron.

Desactivar la validación en todas partes también eliminaría la protección frente a anuncios incorrectos. La tarea operativa consiste en restablecer las pruebas correctas y el enrutamiento previsto, y después verificar el resultado. Que una modificación en la base de datos se haya completado correctamente no demuestra, por sí solo, que los clientes puedan volver a conectarse.

El problema de fondo: las pruebas útiles pueden convertirse en poder concentrado

Aquí es donde la cadena técnica se encuentra con el argumento de Lu Heng. Un administrador no necesita reenviar los paquetes de nadie para influir en la accesibilidad de su red. Si otros sistemas dependen de datos que él controla, sus decisiones pueden imponer costes a operadores y clientes mucho más allá de su oficina.

En la Nota 65, Primacía del código en funcionamiento, Lu Heng sostiene que la coordinación debe estar limitada por las necesidades de las redes en funcionamiento. Una función de mantenimiento de registros no puede ampliarse por sí sola hasta convertirse en un mandato político permanente. Que un registro esté firmado responde a una pregunta técnica sobre la declaración que contiene; no establece un derecho a gobernar a todos los afectados por ella.

Su propuesta va más allá de mejorar el proceso de reclamaciones. Las reglas comunes deben proteger la unicidad, el control verificable y la interoperabilidad, mientras los participantes validan el estado localmente y deciden qué cambios compatibles adoptar. Un nuevo comité con un veto ilimitado reproduciría el problema con otro nombre.

La continuidad necesita una salida que otras redes puedan utilizar

Una alternativa utilizable debe preservar datos fiables, declaraciones de seguridad y relaciones operativas. Las demás redes deben poder verificar esos datos y utilizarlos. Copiar una base de datos no basta para que acepten una alternativa, y declarar la independencia no repara una ruta rechazada.

La Nota 72 explicita el resultado buscado: datos exactos, continuidad operativa y una capacidad real de abandonar a un coordinador que está fallando. El reto práctico es construir esa capacidad sin perder la unicidad compartida y la compatibilidad que permiten comunicarse a las redes independientes.

La guía sobre la exportación del estado del registro explora la parte de ese trabajo relacionada con trasladar los datos registrales. Es un componente de la transición, junto con la verificación, la adopción por parte de los operadores y las pruebas de continuidad.

Prepárate mientras el servicio sigue funcionando

Pide a tu equipo que siga el recorrido de un bloque de direcciones importante, desde sus datos registrales hasta los proveedores y clientes que dependen de él. ¿Quién puede modificar cada dato? ¿Quién lo utiliza? ¿Cómo se corregiría un error si el administrador actual no estuviera disponible o su autoridad estuviera en disputa?

Establecer esas respuestas entre organizaciones lleva tiempo. Encontrarlas antes de un fallo crea margen para actuar; descubrirlas durante una interrupción deja a los clientes asumiendo el coste. La urgencia consiste en construir una independencia efectiva mientras todavía se puede proteger la continuidad.

Continúa con la Nota 65: Primacía del código en funcionamiento para seguir el argumento completo de Lu Heng a favor de una coordinación basada en redes que funcionan, verificación local y adopción voluntaria.