Resumen

  • En RFC 5286, una alternativa libre de bucle no es una propiedad permanente del vecino. Es el resultado de una desigualdad estricta para un destino, una base de topología y un fallo previstos.
  • El cambio que vuelve elegible a una ruta debe producir un nuevo recibo: operandos, época, clase de protección, selección e instalación. El indicador global «LFA habilitado» no contiene esa información.

El día en que 20 pasó a 19

Imaginemos un router S, un destino D y un vecino candidato N. En una instantánea, la distancia óptima de N a D es 20. La distancia de N a S es 7 y la de S a D es 13. La condición básica de RFC 5286 es:

Distance_opt(N,D) < Distance_opt(N,S) + Distance_opt(S,D)

La comparación resulta 20 < 20. Es falsa. El estándar emplea una desigualdad estricta porque S necesita descartar que la mejor trayectoria de N a D regrese por S. La igualdad no aporta esa garantía.

Después cambia una métrica. La distancia de N a D baja a 19 y la prueba se convierte en 19 < 20. Ahora pasa. El ejemplo es abstracto y no describe una red real, pero revela una propiedad importante: el permiso depende de la versión del grafo. Guardar «N es LFA» sin conservar la instantánea y los operandos transforma una derivación reproducible en una etiqueta sin fecha.

Esta frontera también funciona en sentido contrario. Un vecino hoy válido puede dejar de serlo tras una nueva adyacencia, un ajuste de coste o un cambio en el origen del prefijo. La supervisión no debe limitarse a descubrir alternativas nuevas; tiene que registrar cuáles se perdieron y por qué.

El cálculo vive junto al destino

RFC 5286 prepara próximos saltos de respaldo para reducir pérdida durante la convergencia. Al detectar el fallo del próximo salto primario, S puede emplear temporalmente la alternativa hasta instalar el nuevo SPF. La ruta primaria no se reescribe durante el cálculo del LFA.

La alternativa se calcula por destino. Ese detalle invalida muchos resúmenes ejecutivos. Un vecino puede cumplir la desigualdad para una red y no para la siguiente. Un cálculo agregado por próximo salto puede ocultar el prefijo excepcional. Un cálculo por prefijo ofrece mayor precisión, aunque exige más estado y capacidad de explicación. RFC 7916 sitúa esa elección de granularidad junto a la simulación, la política de selección y la monitorización de cobertura.

Los prefijos con varios orígenes muestran por qué importan los datos completos. RFC 8518 actualiza la parte de RFC 5286 dedicada a prefijos multihomed: hay que considerar origen, coste anunciado y, en OSPF externo, reglas de tipo de ruta y selección de ASBR. No basta con una matriz de distancias entre routers si la decisión real incluye el coste de llegar al prefijo desde cada origen.

Por eso una cobertura útil no es «LFA sí/no» por caja. Es una relación entre destino, fallo protegido y candidato. Su denominador puede ser prefijos, enlaces, nodos, próximos saltos o clases de tráfico, pero debe nombrarse. Sin denominador, dos porcentajes iguales pueden asignar riesgo a poblaciones completamente distintas.

Tres adjetivos que no son sinónimos

«Loop-free», «downstream» y «node-protecting» describen pruebas diferentes.

La condición base acredita que el candidato no devolverá el tráfico a S en el caso de enlace modelado. La condición downstream exige además:

Distance_opt(N,D) < Distance_opt(S,D)

Así, el vecino está más cerca de D que el propio S. Esta restricción puede reducir microbucles cuando el fallo real resulta más amplio, pero disminuye la cobertura. A veces el resultado prudente es no tener reparación y descartar paquetes, no aprovechar una trayectoria cuya seguridad no puede justificarse.

La protección de nodo requiere que el camino del candidato evite al vecino primario E. Si N dispone de rutas de igual coste y una atraviesa E, S no puede imponer la otra. RFC 5286 evita atribuir protección de nodo cuando sólo existe una posibilidad favorable. La prueba conserva una visión pesimista porque el plano de control de S no gobierna la elección interna de N.

En medios broadcast o NBMA, el pseudonodo del IGP añade otro límite. Evitar a E no garantiza evitar el segmento que falló. Los grupos de riesgo compartido locales agregan dependencias físicas o lógicas que tampoco aparecen en el simple nombre del vecino. Una salida de auditoría debería mostrar qué pruebas aprobó y cuáles no.

El fallo también forma parte del contrato. Un respaldo calculado para un enlace no hereda validez automática frente a la pérdida del nodo o dos fallos simultáneos. RFC 5286 reconoce microbucles cuando la realidad excede el conjunto previsto. La frase «teníamos un LFA» está incompleta sin «para este destino y este fallo».

De la fórmula al plano de reenvío

El resultado matemático es sólo uno de varios recibos. La secuencia operativa es:

habilitado -> elegible -> seleccionado -> instalado -> activado -> reenviado -> convergido

Habilitado: la política permite el cálculo. Elegible: el vecino pasó las desigualdades para la topología indicada. Seleccionado: ganó frente a otros candidatos según la política. Instalado: el hardware o plano de reenvío confirma el próximo salto de respaldo. Activado: un evento de detección produjo la transición. Reenviado: contadores o una traza muestran paquetes en la ruta de reparación. Convergido: la red salió del estado excepcional.

BFD puede aportar evidencia de detección rápida, pero no responde a las preguntas anteriores. Del mismo modo, un candidato calculado no demuestra que hubiera espacio en la FIB, que la programación terminara ni que el tráfico lo usara.

El registro debe incluir router calculador, área o nivel, hash o versión de la LSDB, hora, destino, tipo de ruta, orígenes, próximo salto primario, recurso protegido, vecino candidato y todos los operandos. Debe conservar los resultados de las pruebas de enlace, nodo, downstream, pseudonodo y SRLG, además de los candidatos rechazados. Sin los rechazos, una ausencia posterior puede parecer un error arbitrario.

La ausencia puede ser el resultado correcto

La aplicabilidad de LFA depende de la topología. RFC 6571 estudia esa variación. RFC 7490 propone LFA remoto para ampliar cobertura allí donde ningún vecino físico resulta adecuado, como ocurre a menudo en anillos. Los mecanismos posteriores TI-LFA y Segment Routing crean otras posibilidades, con otros requisitos.

Nada de eso convierte la falta de un LFA ordinario en defecto. Puede ser el resultado correcto. Tampoco permite asumir que existe un mecanismo posterior si no se ha observado su configuración y estado. El inventario profesional debe poder decir «sin alternativa elegible» sin degradar esa respuesta a un amarillo ambiguo.

Esta pieza no repite la pregunta de si una reparación TI-LFA restaura el servicio. Su unidad de análisis es previa y más pequeña: ¿qué datos autorizaron a este vecino ordinario para este destino en esta época topológica?