¿Hay alguna razón para no usar BFD?

Al tratar de implementar la detección de reenvío bidireccional (BFD), parece ser muy flexible en términos de ajuste del temporizador, el peso ligero con respecto a cualquier sobrecarga y su flexibilidad en términos de aplicación general parece muy impresionante.

Así que si por ejemplo se puede aplicar para detectar fallo de enlace a través de Ethernet, MPLS a través de múltiples saltos, en el borde de la red, para la convergencia IGP, por túneles, etc, etc - ¿por qué sería no utilizar en ciertos escenarios tal vez y si existen otras alternativas emergentes a tener en cuenta?

Solo conozco directamente un problema con BFD, que es la demanda de CPU. Actualmente estoy investigando un problema con un Cisco 7301 que, cuando genera más tráfico durante nuestras horas pico, en comparación con el resto del día, BFD a veces se desconecta y enruta los viajes al siguiente enlace.

Parece que bajo altos volúmenes de tráfico, el uso de CPU del enrutador está aumentando (lo cual no es inusual), pero alrededor del 40-50% de los paquetes de CPU BFD no reciben suficientes recursos.

Sin embargo, he encontrado la siguiente información que sugiere problemas adicionales con BFD (de esta presentación de NANOG, hay más en la presentación, es buena, ¡dale una lectura!)

¿Cuáles son las advertencias?

• Dos principales:
  1. BFD puede tener altas demandas de recursos dependiendo de su escala.
  2. BFD no es visible para los protocolos de agrupación de capa 2. (LAG de Ethernet o paquetes POS)

Demandas de recursos de BFD

• El número de sesiones de BFD en cada tarjeta de línea o enrutador puede afectar qué tan bien BFD escala para usted. -Cada plataforma única tiene sus propios límites.
• Se han visto interfaces agrupadas que admiten un tx / rx mínimo de 250 ms o 2 segundos.
• En algunos casos, las instancias de BFD en un enrutador pueden necesitar ser operadas en el procesador de ruta dependiendo de la implementación (sesiones de BFD no basadas en adyacencia).
• Pruebe su plataforma primero antes de implementar BFD. Intente cargar la CPU RP o LC con sus ajustes configurados. Esto puede hacerse por:
• Ejecutando comandos pesados ​​de CPU
• Los paquetes de inundación a TTL caducan en el destino

Demandas de recursos de BFD (continuación)

• ¿Qué valores son seguros de probar?
• Basado en hablar con varios operadores, 300ms con un multiplicador de 3 (detección de 900ms) parece ser un valor seguro que funciona bastante bien en la mayoría de los equipos.
• Esta es una mejora significativa sobre algunas de las alternativas.

BFD y L2 agrupación de enlaces

• BFD no tiene conocimiento de los miembros del paquete de enlaces L2 subyacentes.
• Un paquete 4x10GigE L2 (802.3ad) aparecería como una sola adyacencia L3. Los paquetes BFD se transmitirían en un enlace de un solo miembro, en lugar de los 4 enlaces.
• Un fallo del enlace con BFD en él daría lugar a un error completo de adyacencia L3.
• Sin embargo, en algunos escenarios, el enlace de miembro fallido puede provocar que solo se descarte un paquete BFD. Los paquetes posteriores pueden enrutarse a través de enlaces de miembros activos.

He visto dos razones por las que BFD no se ha implementado:

1. La ignorancia de esto (fui culpable de esto por algún tiempo).

2. Costo, si eres una tienda de Cisco. Aunque posiblemente sea insignificante dependiendo del tamaño de su organización, ahora hay un costo de licencia asociado para implementar BFD.

A partir del período de tiempo de ISR G2 / ASR, BFD ya no está en el paquete de licencia "Base IP". Debe actualizar al menos al nivel de licencia "Datos" para desbloquear BFD. Vea este documento técnico de Cisco.

Es posible que este requisito de licencia no sea un problema, ya que es posible que ya esté comprando un nivel de licencia más alto para otras funciones, pero es algo a tener en cuenta.

Algunas cosas para completar la respuesta de javano:

• Recuerde que 40g y 100g ethernet pueden considerarse paquetes, aunque no es lo mismo que LACP, pero 4x10, 4x25 y 10x10
• En algunos equipos (algunos de los Juniper de gama alta, por ejemplo), el BFD se maneja en la tarjeta de línea, lo que puede ser un beneficio (sin pérdida bajo una carga de RE alta) o un déficit (sin pérdida inmediata si el RE muere)
• Ejecutar BFD sobre un enlace / ruta que ya es un SPOF (por ejemplo, un solo paquete de fibra) puede ser peor que simplemente aumentar el retraso del operador

BFD es una característica que se inventó para detectar problemas de conectividad L2 cuando hay algún dispositivo intermediario entre dos pares. Entonces BFD es una función de detección de fallas.

Por lo general, necesitamos BFD si tenemos 2 enrutadores interconectados a través del conmutador L2 9 o cualquier otra nube L2). En este caso, si un solo enrutador deja de funcionar, el estado del enlace no se reflejará en otro enrutador, ya que el interruptor mantendría el enlace activo. Si solo se tratara de un enlace P2P (cable único) entre los enrutadores, la interfaz se caería justo en caso de falla de un par y el IGP se volvería a unir en un intervalo de segundos.

Por lo tanto, la razón para no usar BFD es: - BFD no es compatible con las cajas; - BFD no es necesario, ya que no tiene un dispositivo intermedio (use udld y carrier-delay en su lugar).