Convergencia rápida en BGP: Implementando BFD

jogofus
hace 5 días
3 Min. de lectura

Desde que Internet nació ha existido la necesidad de conocer cómo llegar del sitio A al sitio B y por qué zonas pasar. Sería como saber que tengo que ir de Valencia a Madrid pero necesito saber cuales son las carreteras por las que tengo que transitar.

Y no hace falta que nos vayamos directamente a Internet: en nuestras propias empresas y homelabs nos pasa. El pc de sobremesa ha de saber llegar al servidor que tenemos ubicado en el datacenter a 400km de distancia.

Al principio puede ser sencillo: tienes unas pocas redes y puedes crear rutas estáticas manualmente.

Pero, ¿y cuando esa red escala y pasas de tener 6 redes a tener 60 y muchos, muchos routers intermedios? Se hace inviable gestionar tantas rutas estáticas, además de que un pequeño error en una de las configuraciones y te puedes pasar un buen rato buscando el error.

Es por ese motivo que nacieron los protocolos de enrutamiento dinámico, entre los que se encuentran RIP, OSPF, IS-IS y BGP.

BGP es sobre lo que está construido todo Internet.

OSPF simplifica mucho el escenario en redes internas, aunque deberemos contar con la abundancia de paquetes multicast de los que hace uso este protocolo.

Enrutamiento dinámico, ¿problemas?

Como todo en este mundo, tiene su cara B.

En OSPF, por ejemplo, la convergencia es bastante más rápida que en BGP y, hasta cierto punto, tolerable.

Pero en BGP podemos hablar de hasta 90 segundos de convergencia o más.

¿Te imaginas tener un aplicativo sensible a la latencia o una BBDD escribiendo constantemente y perder la conexión durante más de 2 minutos? En muchas ocasiones esto no supone un problema. En otras, puede significar pérdidas bastante grandes.

Una forma de evitar este tiempo de convergencia es que seamos nosotros los que le digamos cómo debe actuar en caso de pérdida de conexión a través del enlace.

BFD: Detección de reenvío bidireccional

Debemos comprender como funciona BGP y cómo detecta la caída de un enlace:

BGP mantiene las sesiones vivas mediante mensajes keepalive, que por defecto se envían cada 60 segundos y tiene un hold timer de 180 segundos.

Generalmente, estos timers se suelen reducir, aunque bajarlos demasiado aumenta la carga en los routers.

Además, BGP opera a nivel de sesión TCP. Si el enlace físico cae pero la sesión TCP no se cierra limpiamente, BGP no se entera hasta que expira el hold timer. BGP simplemente espera.

BFD, cuyas siglas significan Bidirectional Forwarding Detection, funciona completamente diferente, enviando paquetes de control de forma continua entre los dos extremos con intervalos que generalmente se configuran en milisegundos. En cuanto deja de recibir esos paquetes durante un número determinado de intervalos declarado por nosotros, declara el fallo de forma inmediata y notifica a BGP para que actúe.

Cabe aclarar que para que BFD funcione debe estar habilitado en ambos extremos para que se genere la adyacencia (como haría BGP).

Esquema comparativo de BGP y BFD frente a caídas

Probando BFD en nuestro laboratorio

Para el siguiente laboratorio voy a utilizar todo routers y switches Cisco, por unificar tecnologías.

La topología será la siguiente:

Las configuraciones internas de cada red las doy por supuestas.

Una vez configurado BGP, que dejaré la configuración un poco más abajo, configuraremos BFD y le diremos al protocolo que debe hacer uso del mismo.

Para configurarlo deberemos ir a cada interfaz con la que hay establecida una sesión BGP y le decimos lo siguiente:

R1:

interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.252 
 duplex auto
 bfd interval 300 min_rx 300 multiplier 3
!
interface Ethernet0/1
 ip address 10.0.1.1 255.255.255.252
 duplex auto
 bfd interval 300 min_rx 300 multiplier 3
!

El comando clave aquí es el siguiente:

bfd interval 300 min_rx 300 multiplier 3

Le estamos diciendo que habilite bfd en esta interfaz, que envíe un keepalive cada 300 ms y que el tiempo mínimo de espera de recepción ha de ser de 300 ms. Con multiplier 3 le decimos que si no recibe 3 paquetes BFD de por caída la interfaz.

En total, estaríamos hablando de 300ms x 3 paquetes = 900ms. La diferencia frente a los 90s mínimos en BGP es bastante notable.

Procedemos a comprobar las tablas de enrutamiento y las adyacencias BGP.

Aquí vemos que la ruta por defecto, aprendida por BGP para el resto de redes, es a través de 10.0.0.2 (esto se debe a que yo he forzado mediante el atributo weight que haga uso de esta ruta)