SubnetMaster
GuíaRoutingAlta disponibilidad

FHRP: VRRP y HSRP para redundancia del gateway

Aprende redundancia del primer salto: IP/MAC virtual, VRRPv3, HSRP, prioridades, tracking, convergencia, Capa 2 y troubleshooting.

Ver todas las guíasVer guía relacionada

El problema del gateway como punto único de fallo

Un host suele tener configurado un gateway por defecto. Si ese único router deja de estar disponible, el host puede seguir comunicándose dentro de su subred pero pierde acceso a redes remotas aunque exista otro router físicamente conectado. Los First Hop Redundancy Protocols (FHRP) resuelven ese problema presentando un gateway virtual cuya responsabilidad puede pasar entre varios equipos.

La redundancia del primer salto complementa, no sustituye, al routing dinámico. Los routers también necesitan caminos válidos hacia el resto de la red. Si el nuevo gateway activo no tiene salida upstream, mover la dirección virtual no restablece el servicio.

Dirección IP virtual y MAC virtual

Los hosts apuntan a una dirección IP virtual como gateway. Los routers participantes coordinan cuál debe responder y reenviar en cada momento. Para que el cambio sea transparente también existe una identidad de Capa 2 asociada al gateway virtual, de modo que los hosts no necesiten cambiar manualmente su configuración cuando falla un equipo.

Durante una transición pueden intervenir ARP en IPv4 o Neighbor Discovery en IPv6 para refrescar vecinos. La convergencia real depende tanto del protocolo FHRP como del comportamiento de switches, tablas de vecinos y temporizadores.

VRRPv3: un estándar para IPv4 e IPv6

VRRP versión 3 está definido actualmente por RFC 9568, que reemplazó a RFC 5798. Varios routers participan en un Virtual Router y uno actúa como Active Router; los demás quedan como backups. La elección utiliza prioridades y el protocolo anuncia el estado del router activo.

VRRP puede proteger gateways IPv4 e IPv6. Cada familia se trata como una instancia independiente. El detalle de preemption, timers y tracking depende de implementación y configuración, por lo que debe comprobarse en la plataforma concreta en lugar de asumir valores universales.

HSRP: redundancia de primer salto en ecosistemas Cisco

HSRP es un protocolo de redundancia de primer salto ampliamente utilizado en equipos Cisco. Presenta un router activo y otro standby para una dirección virtual. Conceptualmente resuelve el mismo problema de disponibilidad del gateway que VRRP, aunque su formato y operación son específicos del protocolo y de la implementación.

Cuando diseñas una red multivendor, VRRP suele ser la referencia interoperable. En entornos Cisco, HSRP puede integrarse con capacidades de la plataforma como tracking. La elección debe documentarse para evitar mezclar terminología: “active/standby” en HSRP no convierte automáticamente sus detalles en reglas de VRRP.

Tracking: detectar más que la caída del propio router

Un router puede seguir encendido y conectado a la VLAN de usuarios mientras ha perdido su enlace hacia el core o Internet. Si continúa como gateway activo, el tráfico queda blackholed. El object/interface tracking permite reducir prioridad o provocar failover cuando desaparece una condición relevante.

Diseña qué eventos deben disparar el cambio. Trackear demasiadas señales inestables puede provocar flapping; trackear demasiado poco puede mantener un gateway sin salida. Correlaciona el FHRP con OSPF, rutas estáticas o el mecanismo que garantice reachability upstream.

Dependencias de Capa 2 y STP

Los participantes de un FHRP deben compartir el dominio de Capa 2 adecuado para representar el mismo gateway virtual. VLAN, trunks y spanning tree influyen en la conectividad entre ellos y los hosts. Un cambio de topología STP puede modificar qué enlaces están disponibles durante el mismo incidente que provoca el failover.

Por eso la redundancia debe probarse como sistema completo. Revisa STP/RSTP y inter-VLAN routing para comprender la interacción entre gateway y switching.

Redundancia no significa balanceo automático por paquete

El objetivo principal de FHRP es mantener disponible el primer salto. Algunas arquitecturas distribuyen distintas VLAN o grupos entre routers para utilizar ambos equipos, pero eso no implica que una única dirección virtual reparta cada flujo de forma uniforme. El comportamiento exacto depende del protocolo y del diseño.

Si necesitas balanceo de rutas upstream, puede intervenir ECMP u otros mecanismos de routing. Mantén separados los conceptos: un FHRP decide quién representa el gateway virtual; el routing decide por dónde continúa el paquete después.

Qué ocurre durante un fallo

Cuando el activo deja de anunciar o pierde prioridad según las reglas configuradas, un backup asume el rol. Después debe conseguir que los hosts y switches envíen el tráfico hacia él, normalmente utilizando la identidad virtual y anuncios que actualizan las tablas necesarias. El tiempo visible para la aplicación depende de timers, detección, Capa 2 y rutas upstream.

No pruebes alta disponibilidad únicamente desconectando la alimentación. Simula pérdida del uplink, fallo parcial, caída de un trunk y recuperación del primario. Así descubres si tracking y preemption producen el comportamiento que esperabas.

Troubleshooting de VRRP/HSRP

Si los hosts no salen de la VLAN, comprueba primero qué router cree ser activo y si ambos tienen configuración coherente de grupo, VLAN y dirección virtual. Verifica que el activo responde por el gateway y que posee una ruta válida de salida. Después revisa ARP/ND y la tabla MAC si el tráfico sigue llegando al equipo equivocado.

  • ¿Los routers ven los mensajes del protocolo en la VLAN?
  • ¿Las prioridades y tracking reflejan el diseño?
  • ¿Hay split-brain por un fallo de Capa 2?
  • ¿El nuevo activo tiene rutas y políticas equivalentes?
  • ¿La recuperación del primario provoca una segunda interrupción por preemption?

Ejemplo práctico de gateway redundante

Supón una VLAN de usuarios con gateway virtual 10.20.30.1 y dos switches L3. El equipo A tiene mayor prioridad y actúa como gateway activo; B permanece preparado. Si A pierde su uplink al core y el tracking está configurado, reduce su prioridad y B asume la dirección virtual. Los hosts siguen usando 10.20.30.1: no necesitan recibir un gateway nuevo por DHCP. La prueba correcta consiste en verificar también que B posee rutas de salida y que el tráfico de retorno puede volver por un camino coherente.