Cuando la puerta de enlace predeterminada se vuelve inestable, toda la subred lo nota de inmediato: las sesiones se cortan, las entradas ARP hacen flapping y el troubleshooting se convierte en una tarea continua. Para HA für Core‑Router VRRP (Virtual Router Redundancy Protocol), HSRP (Hot Standby Router Protocol) y GLBP (Gateway Load Balancing Protocol) son las herramientas habituales. Este artículo explica de forma práctica cómo diseñar, configurar y operar estos protocolos para evitar escenarios de split‑brain —es decir, situaciones en las que varios routers creen estar activos al mismo tiempo.
HA für Core-Router: Rolle von VRRP, HSRP und GLBP
VRRP, HSRP y GLBP proporcionan una puerta de enlace predeterminada virtual (VIP). Un router responde por esa dirección y reenvía el tráfico; otro permanece en standby. Aviso importante: FHRP (First Hop Redundancy Protocol) solo cubre el primer salto; la redundancia de enrutamiento en el backbone, rutas L2 estables y políticas limpias de control‑plane son prerrequisitos necesarios.
¿Cuándo usar cada protocolo?
- VRRP está estandarizado (RFC) y suele ser la primera opción en entornos multivendedor.
- HSRP es propietario de Cisco y ofrece integración estrecha con el tracking/monitoring de Cisco.
- GLBP distribuye la carga del gateway mediante varias MAC virtuales, aunque incrementa la complejidad (comportamiento ARP, integración de seguridad).
En qué consiste realmente el split‑brain y cómo se manifiesta
El split‑brain en FHRP generalmente no es una anomalía pura del protocolo, sino el resultado de señalización mal dirigida, particiones L2 o temporizaciones inadecuadas. Síntomas en operación:
- ARP/MAC‑flapping: las MAC virtuales saltan entre puertos.
- Enrutamiento asimétrico: los paquetes salen por un camino pero regresan por otro distinto.
- Pérdida intermitente de paquetes o tiempos de establecimiento de conexión prolongados tras un failover.
Causas típicas
- Los paquetes de control son bloqueados por ACLs, storm‑control o límites de multicast.
- Particiones L2 o configuraciones inconsistentes de trunk/VLAN.
- Preemption sin retraso durante la convergencia del enrutamiento.
- Tracking que solo comprueba Link‑Up/Down, pero no detecta el reenvío real (blackholing).
Requisitos de topología: base para un failover estable
Antes de afinar temporizadores y prioridades, asegure los cimientos:
- Los participantes FHRP deben estar en el mismo VLAN/subred (SVI/interfaz L3).
- Trunks/port‑channels consistentes y listas permitidas de VLAN entre Core y Access.
- Plan STP‑Root: establecer deliberadamente Root Bridges y puertos Edge (PortFast/Edge para dispositivos finales).
- Ruta separada de management/keepalive como canal secundario de liveness, cuando sea posible.
Principios de configuración: prioridad, preemption, temporizadores, tracking
La estabilidad se consigue con reglas claras. Tres elementos clave:
1. Prioridades inequívocas
Evite empates. Defina por VLAN un master preferido y priorice el backup sensiblemente más bajo. Esto reduce las condiciones de carrera.
2. Preemption con retraso
La preemption (el router de mayor prioridad retoma al volver) es útil, pero solo con demora. Si no, se producen flaps en los reinicios mientras no converjan enrutamiento/port‑channels. Un preempt‑delay da al sistema tiempo para estabilizar adyacencias IGP, BGP y LACP.
3. Tracking de accesibilidad real
El seguimiento de interfaces es la base; amplíelo con seguimiento de rutas (ruta por defecto/vecino IGP) y IP SLA (medición activa) hacia un siguiente salto estable. Importante: los objetivos de seguimiento no deben depender ellos mismos del FHRP que se está verificando — de lo contrario se genera una retroalimentación y un posible desencadenante de split‑brain.
Ejemplos de configuración práctica (orientativos)
Los comandos dependen del proveedor; aquí ejemplos estructurados en sintaxis Cisco que muestran cómo combinar Preempt Delay, Priority y Tracking.
VRRP – Preempt‑Delay y Tracking (ejemplo)
interface Vlan10
ip address 10.10.10.2 255.255.255.0
vrrp 10 ip 10.10.10.1
vrrp 10 priority 120
vrrp 10 preempt delay minimum 60
vrrp 10 track interface Port-Channel1 decrement 40
vrrp 10 track route 0.0.0.0/0 decrement 30HSRP – Active/Standby con seguimiento por IP SLA (ejemplo)
ip sla 10
icmp-echo 8.8.8.8 source-ip 10.10.10.2
frequency 10
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability
interface Vlan10
ip address 10.10.10.3 255.255.255.0
standby 10 ip 10.10.10.1
standby 10 priority 110
standby 10 preempt delay minimum 60
standby 10 track 10 decrement 30GLBP – solo si se requiere balanceo de gateways
interface Vlan10
ip address 10.10.10.4 255.255.255.0
glbp 10 ip 10.10.10.1
glbp 10 priority 120
glbp 10 preempt delay minimum 60
glbp 10 load-balancing round-robin
glbp 10 track Port-Channel1 decrement 30IP SLA, BFD y aceleración del failover
Los temporizadores FHRP por sí solos a menudo no son el ajuste correcto para lograr failovers rápidos y seguros. Dos mecanismos complementarios son muy efectivos en la práctica:
IP SLA (comprobación activa de disponibilidad)
IP SLA realiza mediciones activas (ICMP/TCP/UDP) contra un host objetivo estable. Use IP SLA como objeto de seguimiento para FHRP: así no decide un link‑down, sino la alcanzabilidad real del upstream. Preste atención a la selección del objetivo: utilice un siguiente salto en la red del operador o un peer en la nube que no atraviese el gateway que se está probando.
BFD (Bidirectional Forwarding Detection)
BFD es un mecanismo de detección de disponibilidad muy rápido que funciona entre peers de enrutamiento o sobre túneles. BFD detecta fallos de reenvío en milisegundos y puede resolver adyacencias IGP más rápidamente; como consecuencia, el seguimiento FHRP debería incluir estado de ruta/IGP en lugar de basarse solo en el estado del interfaz.
! Beispiel für einfache BFD Template und Interface‑Aktivierung
bfd-template single-hop BFD_FAST
interval 50 min_rx 50 multiplier 3
!
interface GigabitEthernet0/0
ip address 192.0.2.2 255.255.255.252
bfd interval 50 min_rx 50 multiplier 3FHRP sobre VPNs, MPLS o sitios remotos
Implementar FHRP sobre redes WAN/proveedor es una fuente frecuente de fallos. FHRP está pensado para redundancia en segmentos LAN; sobre redes L3 es fácil que surjan situaciones de split‑brain, porque los paquetes de control y las rutas de datos pueden separarse.
Buenas prácticas para entornos multi‑sitio
- Aplicar FHRP solo de forma local; para redundancia entre sitios utilizar enrutamiento (BGP/OSPF) y Anycast.
- Si FHRP se implementa sobre un L2 compartido (p. ej., L2‑MPLS), asegúrese de que los paquetes de control sigan el mismo camino que el tráfico cliente.
- En túneles IPsec/GRE: evite que los destinos IP‑SLA o los objetivos de seguimiento dependan del gateway que se está monitorizando.
Práctica de diagnóstico: orden de comprobación en caso de fallos
Una cadena de comprobación fija evita pérdida de tiempo. Objetivo: aclarar primero si FHRP es causa o síntoma. Complementario a las comprobaciones básicas de la versión base, aquí comprobaciones ampliadas y ejemplos de captura de paquetes.
Paso 1 – Comprobar el estado de FHRP
show vrrp brief
show standby brief
show glbp brief
show logging | include VRRP|HSRP|GLBP|STATE|TRACKPaso 2 – Vista MAC/ARP
show mac address-table vlan 10 | include 0000.5e00
show mac address-table move update
show ip arp | include 10.10.10.1Paso 3 – Comprobar tráfico de control y ACLs
show interface Vlan10 counters
show ip igmp snooping groups vlan 10
show access-lists | include 112|HSRP|GLBPAsegúrese de que los paquetes de control de FHRP no sean descartados por ACLs, QoS o Storm‑Control. Para VRRP se usa el protocolo IP 112; tcpdump puede ayudar a ver los paquetes de control.
# Beispiel: VRRP‑Pakete mit tcpdump auffangen
tcpdump -nni eth0 'ip[9] == 112' -vvPaso 4 – Comprobar routing/forwarding
show ip route 0.0.0.0/0
show ip ospf neighbor
show bgp summary
ping <upstream-next-hop> source <SVI-IP>Un Master puede reportar estado Up, pero upstream puede estar haciendo blackholing: eso indica que el tracking es insuficiente.
Paso 5 – Perspectiva del cliente
En los clientes, compruebe la entrada ARP, el traceroute (primer salto) y la persistencia de sesiones. Firewalls y uRPF pueden cortar conexiones en casos de enrutamiento asimétrico.
Casos de prueba para cambios controlados
Realice pruebas de failover en pasos controlados y documente comportamiento y métricas. Casos de prueba recomendados:
- Fallo de uplink simulado en el Master (Link‑Down en el uplink).
- Shutdown de interfaz en el Master (comprueba la respuesta de Tracking).
- Reinserción de Preemption: reiniciar el Master y observar si el Preempt‑Delay evita el flapping.
- IP SLA Target unreachable: comprobar si el objeto de Track dispara el FHRP.
- Prueba de estrés de MAC‑flaps: múltiples Up/Down en puertos de acceso y observación de la tasa de flaps.
- Failover de VPN: despliegue con carrier y failover BGP, y comprobación de rutas asimétricas.
Runbook operativo – Lista de verificación rápida
- ¿Está el VLAN de FHRP consistente en todos los switches implicados?
- ¿Quién es el Master planificado por VLAN (documentación de prioridades)?
- ¿Son los IP SLA Targets independientes y alcanzables?
- ¿Están permitidos los paquetes del plano de control (p. ej. VRRP) en las ACLs?
- ¿Existen alertas para MAC‑flaps, cambios de estado de FHRP y pérdidas de IP SLA?
Aspectos especiales de seguridad
Herramientas de seguridad como Dynamic ARP Inspection (DAI), IP Source Guard o RA Guard pueden interferir con el failover si los puertos de confianza no están configurados correctamente. Verifique que los switches de acceso permitan el GARP/NA/Gratuitous‑ARP de los gateways y que las ACLs no filtren el tráfico de control.
Conclusión y recomendaciones
La alta disponibilidad (HA) para routers de core es menos una cuestión de configuración puntual que de diseño del sistema: rutas L2 claras, reglas de Master priorizadas, Preemption con retardo, tracking basado en la comprobación real de alcanzabilidad y un monitoring significativo evitan la mayoría de los casos de split‑brain. Pruebe escenarios de failover controlados, documente dependencias (VLAN, trunk, Tracking‑Targets) y tenga opciones de retorno sencillas. En entornos multi‑site o con VPN, prefiera instancias FHRP locales y apoye la redundancia por sitio en routing/anycast. Así, la redundancia del gateway será robusta y predecible en operación.
Pruebas adicionales y observaciones
Si encuentra problemas persistentes, se recomienda un aislamiento secuencial: primero validar completamente L2, luego FHRP‑Control, a continuación el enrutamiento y por último los síntomas a nivel de aplicación. Una documentación estructurada de todas las pruebas de failover y de las baselines aceptadas minimiza las intervenciones en „War‑Room“ y acelera la resolución de incidentes.
Operación, monitorización y medidas de emergencia para HA para Core‑Router
Además de la configuración, la operación diaria es decisiva: supervisión, copia de seguridad de datos, control de cambios y medidas de emergencia claramente definidas reducen significativamente los tiempos de inactividad. Esta sección proporciona indicaciones prácticas sobre qué métricas debe recopilar, cómo iniciar contramedidas rápidas y de qué manera la automatización mejora la fiabilidad.
Qué métricas importan realmente
- Cambios de estado FHRP por minuto: aumentos bruscos indican flapping o problemas de preempt.
- Flaps en la tabla MAC y número de puertos distintos por MAC virtual: indicador temprano de particiones L2.
- Pérdidas de alcance IP SLA y resets de sesiones BFD: indican fallos reales de reenvío.
- Pérdidas en el plano de control (ACL/QoS/CP‑Policing): si el router tiene alta carga de CPU, se pierden paquetes de señalización.
Reglas de monitorización y alertas (recomendadas)
- Alarma cuando FHRP‑State‑Changes > 3 en 5 minutos.
- Advertencia cuando la tasa de MAC‑Flap > X por minuto (valor dependiente del entorno).
- Crítico cuando IP SLA‑Loss > 5% durante 1 minuto o BFD‑Down.
Medidas de emergencia rápidas (extracto del runbook)
- Aislar: asignar los VLAN‑trunks afectados y, si procede, poner puertos temporalmente en ‚errdisable‘ para detener el flapping.
- Estabilizar: desactivar temporalmente la preemption o aumentar el Preempt‑Delay hasta que las adyacencias upstream estén operativas.
- Actualización ARP: permitir gratuitous ARP en los edge‑switches y vaciar la caché ARP de los clientes si es necesario.
- Fallback: establecer manualmente la prioridad del master (con restablecimiento documentado) si el failover automático no funciona de forma fiable.
Ejemplos de comandos rápidos para operadores:
# Konfigurationssicherung vom Router (via SCP/SSH)
scp admin@10.0.0.1:/running-config ./backup/10.0.0.1.cfg
# Syslog filtern nach FHRP‑Events
ssh syslogserver 'grep -E "VRRP|HSRP|GLBP|STATE|TRACK" /var/log/syslog | tail -n 200'
# Client‑ARP auf Linux leeren
sudo ip neigh flush allAutomatización y gestión de cambios
Mantenga las configuraciones FHRP en un repositorio Git, verifique los cambios mediante CI (linting, validación sintáctica de plantillas) y ejecute pruebas planificadas en un emulador de laboratorio (GNS3、EVE‑NG). Backups versionados permiten un rollback rápido tras cambios erróneos.
Medidas a largo plazo
Realice pruebas de caos regulares (apagados controlados de enlaces, indisponibilidad de IP‑SLA‑Targets) y documente mediciones así como las baselines aceptables. De este modo detectará degradaciones progresivas antes de que los usuarios se vean afectados. La documentación, los backups automatizados y una ruta de emergencia clara hacen que la HA para Core‑Router sea realmente robusta en operación.
Para este tema también son importantes Configurar VRRP y Configurar HSRP. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.