Cómo crear failover automático en dual-WAN con BGP local

Por qué el failover tradicional falla en entornos críticos

Cuando una empresa depende de conexiones de internet ininterrumpidas, confiar solo en el balanceo básico de carga o en scripts simples de ping suele generar dolores de cabeza. En la práctica, esto significa que si el operador principal pierde la conexión con el resto del mundo, pero el cable sigue conectado a su router, una prueba ciega de cable conectado puede asumir que todo va bien y seguir enviando tráfico a un agujero negro. Para resolver esto en redes corporativas exigentes, debemos recurrir a protocolos de enrutamiento dinámico que conversan directamente con la infraestructura del operador o gestionan políticas locales estrictas.

El BGP (Border Gateway Protocol, el protocolo que gestiona cómo viajan los datos entre diferentes redes en internet) suele asociarse únicamente a grandes proveedores de tránsito. Sin embargo, usarlo de forma local en los routers de borde de su propia empresa cambia por completo el panorama de resiliencia. Antes de profundizar en la configuración, vale recordar que gestionar cuellos de botella de infraestructura no se limita a la red, exigiendo atención también a otros subsistemas, como detallamos en nuestro artículo sobre cómo diagnosticar cuellos de botella de IOPS en Linux para mantener el almacenamiento estable bajo estrés operativo.

Cómo funciona el BGP local en el borde de la red

El BGP local actúa como un mensajero inteligente entre su router principal y los módems o routers de borde proporcionados por sus dos operadores de internet. En lugar de enviar ciegamente todo el tráfico a una puerta de enlace predeterminada fija, el router conversa vía BGP con cada operador para descubrir qué rutas están realmente activas y eficientes en ese momento. En la práctica, si el circuito del Operador A presenta lentitud extrema o pérdida severa de paquetes, el protocolo percibe el cambio de estado y desvía el flujo de datos al Operador B en cuestión de segundos, sin que los usuarios noten la oscilación.

Para levantar esta arquitectura, el equipo de borde debe soportar sesiones eBGP (External BGP) con los routers de borde de cada ISP. Cada operador proporciona un número de AS (Autonomous System, el identificador numérico único que cada red usa en internet) privado para la sesión local. El gran secreto de este enfoque es que la decisión de conmutación por error deja de depender de un script frágil ejecutándose en el sistema operativo y pasa a ser una decisión nativa y determinista del plano de control del router.

Configurando la redundancia y los atributos de ruta

La configuración práctica exige definir qué enlace será el preferencial y cuál actuará estrictamente como respaldo. Para lograr esto en BGP, utilizamos atributos de ruta, siendo el AS-Path Prepend el mecanismo más común y accesible. En la práctica, inyectar repeticiones de su propio número de AS en el anuncio enviado al operador secundario hace que ese camino parezca más largo y menos atractivo para el tráfico que regresa, garantizando que el Operador A sea siempre la vía principal mientras esté saludable.

Además de ajustar la salida, debemos monitorear la entrada de forma rigurosa. Si ya domina la estructuración de tráfico interno, vale la pena revisar también cómo configurar VLANs y enrutamiento inter-VLAN en un switch para aislar correctamente el tráfico del borde antes de que llegue al núcleo de la red. A continuación, vea un ejemplo simplificado de configuración en un router de borde usando sintaxis tipo FRRouting o routers basados en Linux:

router bgp 65000
  bgp router-id 192.168.100.1
  neighbor 203.0.113.1 remote-as 65001
  neighbor 198.51.100.1 remote-as 65002
  !
  address-family ipv4 unicast
    network 192.0.2.0/24
    neighbor 203.0.113.1 activate
    neighbor 203.0.113.1 route-map PREFER-ISP1 in
    neighbor 198.51.100.1 activate
    neighbor 198.51.100.1 route-map BACKUP-ISP2 in
  exit-address-family
!
ip prefix-list PL-LOCAL permit 192.0.2.0/24
route-map PREFER-ISP1 permit 10
  set local-preference 200
route-map BACKUP-ISP2 permit 10
  set local-preference 100
  set as-path prepend 65000 65000

Validando la convergencia y probando el failover en la práctica

Tras aplicar la configuración, el momento más importante es simular el fallo real para asegurar que el sistema reacciona exactamente como se planeó. Desconectar el cable físico del operador principal es la prueba de fuego definitiva. En la práctica, debe observar cuánto tiempo tarda el router en derribar la sesión BGP por falta de Keepalives y asumir por completo el enlace secundario. Si este tiempo supera los treinta segundos, los usuarios de servicios en tiempo real, como llamadas de video o VoIP, notarán caídas molestas.

Para mitigar retrasos en la detección de fallos donde el cable sigue conectado pero el operador pierde conectividad upstream, habilitamos BFD (Bidirectional Forwarding Detection). BFD dispara paquetes ultrarrápidos de prueba de enlace cada milisegundo, avisando al BGP inmediatamente de cualquier anomalía física o lógica. De este modo, la transición entre enlaces deja de ser un evento tardado y pasa a ser imperceptible para las aplicaciones corporativas alojadas localmente.

Consideraciones finales sobre la resiliencia en el borde

Crear una arquitectura de alta disponibilidad con dual-WAN y BGP local transforma la estabilidad de una operación que antes sufría con caídas repentinas de enlaces. Aunque exige equipos con mayor capacidad de procesamiento y conocimiento técnico refinado en el equipo de infraestructura, los beneficios operativos compensan el esfuerzo inicial. Mantener redundancias activas y probadas regularmente asegura que el negocio siga operando sin interrupciones no deseadas, protegiendo a la empresa contra fallas imprevisibles de las telecomunicaciones.