Cisco: conmutación por error rápida y confiable de BGP al mezclar BGP NHT y BFD

Al ejecutar BFD en interfaces entre dos vecinos iBGP e IGP directamente conectados, ¿es más estable / confiable usar BFD para tiempos de reacción IGP rápidos y Seguimiento de salto de BGP siguiente para tiempos de reacción BGP más rápidos (en lugar de BFD para ambos)?

La razón por la que pregunto esto es que si se usa BFD para la notificación de falla de enlace IGP y BGP, una interfaz que se cae hace que la sesión BGP se rompa y el IGP ejecute SPF. Si el IGP ejecuta SPF y se completa en 200 ms, por ejemplo, utilizando una implementación de IGP sintonizada, la accesibilidad a ese vecino iBGP puede restaurarse y, por lo tanto, la sesión iBGP podría haber permanecido.

Estoy sugiriendo lo siguiente (porque así es como estoy interpelando los documentos de Cisco);

Si un enlace se cae, BFD señala esto al IGP y el IGP volverá a calcular una nueva ruta al vecino iBGP (suponiendo que no haya ECMP o Un-ECMP o IP Fast Re-Route debido a esos escenarios, una falla del enlace no interrumpirá la sesión de iBGP ¿Yo creo?). En este escenario, cuando el IGP calcula una nueva ruta, el emparejamiento iBGP continúa sin interrupción. Cuando no se puede calcular (no hay otra ruta disponible), establecer un valor de NHT más bajo como bgp nexthop trigger delay 1para que coincida con la convergencia rápida de IGP provocaría que la sesión de BGP se derribara ahora que definitivamente no hay una ruta al vecino iBGP. Entonces, ¿tiene sentido no usar BFD para los vecinos iBGP y usar BGP NHT en su lugar?

Bueno, en realidad, BGP NHT puede usar BFD para acelerar la detección de problemas de vecinos, y generalmente es el mejor mecanismo de escala, porque BFD a menudo se descarga en el hardware.

Ejecutar BFD para IGP y BGP puede ser una buena idea, dependiendo de las capacidades de escalado de su aceleración / descarga de equipo y hardware. Es la configuración la que tiene que tener sentido desde el punto de vista lógico.

Por lo tanto, su decisión se reduce a esto: si desea ajustar los protocolos IGP y EGP para intentar ejecutarlo al mismo tiempo ( bgp nexthop trigger delay 0y BGP BFD NHT), lo que puede provocar problemas, oscilaciones, etc. para enfocarse en lograr una rápida convergencia de IGP y con la presencia de múltiples rutas de reenvío, deje que BGP se demore un momento más solo para asegurarse de que su IGP converja ( bgp nexthop trigger delay 1con o sin BGP BFD NHT).

Ese último enfoque generalmente tiene más sentido, y es por eso que el retraso de NHT por defecto está configurado en 5 segundos. Si su IGP converge en 200 ms (o generalmente, menos de un segundo), puede tener sentido sintonizar BGP NHT a 1 segundo.