Resumen

  • El AC-Flag 0x10 de RFC 9983 comunica una intención: que el prefijo sea anunciado por múltiples nodos.
  • La intención en el plano de control no sustituye la evidencia de una FIB instalada, la elección de flujo, la salud de la réplica ni el efecto de la aplicación.

En una revisión de continuidad, la frase «el anycast está bien» puede nacer de una captura impecable: hay anuncios repetidos, aparece un 0x10, y BGP-LS lo reproduce en el inventario. La captura prueba algo. No prueba todo lo que la frase promete.

RFC 9983, publicada por el IETF como Standards Track en mayo de 2026, incorpora la OSPFv2 Anycast Property Advertisement. Reserva 0x10 como Anycast Flag del Extended Prefix TLV. El documento define una sola semántica: el prefijo está destinado a anunciarse desde varios nodos. Una configuración anycast debe fijar la marca y una configuración que no es anycast debe limpiarla.

La aportación resuelve una ambigüedad legítima. La multiplicidad de anuncios, por sí sola, puede ser diseño, transición o error. El flag permite que routers y herramientas distingan una intención explícita. Cuando una LSA Opaque de prefijo extendido se vuelve a anunciar hacia otra área, el flag debe preservarse; la propiedad no debe desaparecer en la frontera de área.

La conservación de esa propiedad no selecciona un servidor.

El salto que no puede hacerse en un tablero

Hay una secuencia de hechos, no una única verdad anycast. Primero existe la configuración declarada. Después está la LSA originada y recibida. Luego cada router calcula rutas bajo su propia topología, coste, filtros y política, y quizá instala una ruta en la FIB. Más tarde un flujo real se somete a ECMP, recursión, hash y condiciones de retorno. Finalmente la instancia alcanzada puede o no estar sana y autorizada para producir el resultado que espera el usuario.

Un fallo en cualquiera de esas uniones deja intacta la verdad anterior. El AC-Flag puede ser correcto mientras una LSA no llega al área relevante. La ruta puede existir en RIB y no instalarse por una política local. La FIB puede seleccionar una réplica que responde a ICMP pero está drenada, saturada o no dispone del estado de aplicación. Una sonda TCP puede ser verde aunque una operación autenticada fracase.

El RFC no oculta esta distancia. De hecho, indica que quien se apoye en el flag para decisiones de encaminamiento o seguridad debe considerar errores de configuración e implementaciones inconsistentes. El error organizativo consiste en convertir ese aviso en una casilla de conformidad y suprimir el resto de la cadena.

La propuesta de Heng Lu sobre una especificación inicial mínima permite leer el alcance con precisión. Lo común debe ser lo que necesita ser común: en este caso, una etiqueta interoperable para una intención de prefijo compartido. La detección de salud, el reparto de carga, la definición de servicio y la aceptación de una acción pertenecen a contextos locales. Son verificables con pruebas locales, no por una bandera global.

El conflicto AC/N debe conservarse como evidencia

RFC 9983 impone una frontera semántica concreta: el AC-Flag y el N-flag de RFC 7684 no pueden estar ambos activos. Si se reciben los dos, hay una anomalía de configuración; el router debe ignorar el N-flag y debería registrar el conflicto con limitación de frecuencia.

No es un detalle que pueda esconder un normalizador. Si un proceso de observabilidad reduce las banderas a «metadatos aceptados», hace desaparecer precisamente la contradicción que el estándar pide tratar. Tampoco autoriza a declarar caída una aplicación: el RFC no asigna ese efecto. La acción responsable es impedir que el estado conflictivo se use como confirmación positiva, identificar los originadores y corregir la configuración bajo control de cambios.

La visibilidad BGP-LS no es autoridad operacional

El texto también establece que un prefijo anunciado por varios routers se considera anycast si al menos uno lleva AC-Flag; un prefijo anunciado por uno solo sin flag es específico de nodo. Recomienda gestionar esos prefijos de forma coherente y vigilar estrictamente configuraciones antiguas, porque el flag prevalece al identificar la propiedad.

La extensión BGP-LS de RFC 9085 puede transportar las banderas de prefijo correspondientes. Un recolector obtiene así una excelente vista de la declaración. No obtiene por ello la autoridad para afirmar qué cálculo hizo cada ingreso, qué ruta se instaló, qué miembro de ECMP recibió el flujo o si ese miembro completó una operación. Multiplicar una misma declaración a través de tres sistemas no crea tres testigos independientes.

RFC 9983 además añade el dato escribible anycast-flag a los modelos YANG de OSPF y gestión de rutas, RFC 9129 y RFC 8349. El plano de gestión puede alterar una afirmación que otros sistemas tomarán como señal. Por eso el documento pide transporte seguro, autenticación mutua y control de acceso con NACM. La pregunta de gobierno es sencilla: ¿quién puede emitir este hecho y cómo se conserva la prueba de esa autorización?

Un registro que no confunda capas

Para cada prefijo sensible, conviene enlazar seis clases de registro: la aprobación de configuración y su identidad de gestión; LSAs por área y sus conflictos; RIB/FIB en ingresos relevantes; evidencia de selección de datos; salud y capacidad de cada réplica; y una comprobación de resultado aplicable al servicio. No se trata de retrasar la respuesta hasta tener todo. Se trata de no llamar «salud de servicio» a una observación que sólo dice «AC-Flag presente».

La diferencia es decisiva después de un incidente. Si el único indicador corporativo es un booleano anycast, los equipos pueden reparar el símbolo o el anuncio y seguir sin ver la decisión local que falló. La realidad de ejecución está en los puntos donde se calculó, seleccionó, admitió y realizó la acción, no en la etiqueta que permitió describir el prefijo.