VRRP parece simple hasta que deja de serlo: dos routers que reclaman ser Master al mismo tiempo, una conmutación que técnicamente funciona pero tarda veinte minutos en recuperarse de verdad, o dos sitios que generan silenciosamente la misma MAC virtual. Tres casos reales de campo, los comandos que identificaron cada causa raíz, y qué revisar la próxima vez que VRRP se comporte mal.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
En los tres casos siguientes, la configuración de VRRP en sí era correcta — la falla estaba una capa más allá, en MSTP, en el manejo de ARP, o en un segundo sitio que nadie había verificado.
VRRP en sí es un protocolo simple: la prioridad decide quién es Master, y una MAC virtual conocida derivada del VRID hace que la conmutación sea invisible para los hosts del segmento. Esa simplicidad es precisamente la razón por la que, cuando VRRP se comporta mal, releer la configuración de VRRP línea por línea suele ser el primer movimiento equivocado. Los tres casos de campo siguientes se remontan todos a algo adyacente a VRRP — un bucle que STP en realidad no había bloqueado, una función de refuerzo de ARP que interactúa mal con una falla de enlace, y una colisión de MAC virtual entre dos sitios que nunca se verificaron entre sí.
A continuación se desglosa cada caso — la red donde ocurrió, el síntoma, los comandos que identificaron la causa, y la solución — además de las respuestas de preguntas frecuentes sobre la elección de Master en VRRP y las causas del doble maestro que surgen cada vez que se discuten estos tickets.
El doble maestro, una recuperación lenta y un silencio total entre dos sitios parecen el mismo protocolo comportándose mal — no son la misma falla, y no se resuelven de la misma manera.
Ubicar primero el síntoma en este árbol indica cuál de los casos siguientes es realmente el que está viendo, y qué función fuera del propio VRRP debe revisar.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Ninguna de estas tres fallas es un error del protocolo VRRP — VRRP simplemente expone un problema que ya existía en la red: un bucle sin bloquear, una función de refuerzo de ARP que asumía que la topología nunca cambiaría, y un VRID que nunca se coordinó entre sitios. Arreglar la función adyacente arregla VRRP.
Mismo protocolo, tres causas raíz completamente distintas — y tres conjuntos de comandos diferentes para confirmar cada una.
SwitchA y SwitchB mostraban ambos el estado Master de VRRP al mismo tiempo; los clientes cableados e inalámbricos de parte de la red perdieron el acceso a internet. La causa no era VRRP — era un bucle que MSTP en realidad no había bloqueado.
<HUAWEI> display cpu-defend statistics all
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp 47876567 1856471019 2017-06-21 10:46:18
3255606556 126240029k
// huge pass+drop counts on vrrp -> far more VRRP traffic than two routers should generate
<HUAWEI> display trapbuffer
#Jun 21 2017 10:36:14 HX-1 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move
detected, VLANID = 28, MacAddress = 12b7-c3d0-9070, Original-Port = XGE2/0/0, Flapping port =
XGE2/0/10 and XGE2/0/6. Please check the network accessed to flapping port.
// Original-Port / Flapping port -> trace these down to the downstream switch with the loopSwitchA (Master) y SwitchB (Backup) estaban unidos por un cable de latido; un servidor de doble conexión estaba en ambos. Cuando el enlace del servidor a SwitchA falló, el tráfico sí pasó a la ruta de respaldo — pero el servicio no se recuperó realmente hasta 20 minutos después.
[SwitchB] undo arp anti-attack entry-check fixed-all enable
[SwitchB] undo arp learning strict
// server's ARP entry is now free to re-learn against the new inbound interface
// instead of waiting up to ~20 minutes for the old heartbeat-interface entry to age outSite1 y Site2 se comunicaban a través de una red troncal; el par de firewalls de cada sitio ejecutaba su propio clúster VRRP. SW-1 podía hacer ping a SW-2 a través de la red troncal, pero los firewalls de los dos sitios no podían alcanzarse en absoluto.
[SW-1] display mac-address | include 0000-5e00-0136
-------------------------------------------------------------------------------
MAC Address VLAN/VSI Learned-From Type
-------------------------------------------------------------------------------
0000-5e00-0136 339/- XGE0/0/1 dynamic
0000-5e00-0136 339/- GE0/0/2 dynamic
-------------------------------------------------------------------------------
// same virtual MAC learned from two different directions -> loop, or duplicate VRID
// no loop found -> checked VRRP config on both firewall clusters -> same VRID both sites
// virtual MAC format: 00-00-5E-00-01-{virtual-router-ID} -> identical VRID = identical MACUna vez que el árbol anterior le ha indicado en qué caso está, estos cinco puntos explican la mayor parte de lo que realmente falla.
SÍNTOMAAmbos routers VRRP informan Master simultáneamente; la propia configuración VRRP de los dos routers es completamente coherente al compararla.
CAUSAUn bucle en algún lugar aguas abajo inunda los anuncios VRRP y corrompe la tabla MAC en la ruta entre los dos routers, por lo que cada router deja de escuchar de forma fiable los hellos del otro y decide de forma independiente que es el único Master que queda en pie.
SOLUCIÓNNo empiece releyendo la configuración VRRP — primero verifique display cpu-defend statistics all y display trapbuffer en busca de una alarma de movimiento de MAC, y rastree el bucle desde ahí. Vea «Tormenta de bucle de capa 2» para el proceso completo de búsqueda de bucles.
SÍNTOMALa conmutación ocurre, pero la red no se recupera realmente hasta varios minutos después — no segundos, minutos.
CAUSALa fijación de ARP tiene tres modos mutuamente excluyentes para distintas situaciones: fixed-mac es adecuado para una MAC fija que se mueve entre puertos de acceso; fixed-all es adecuado cuando tanto la MAC como la ubicación de acceso permanecen fijas; send-ack es adecuado cuando ambas cambian con frecuencia. Configurar fixed-all en una topología donde el punto de acceso sí cambia — como un servidor de doble conexión que conmuta entre dos switches — bloquea la entrada obsoleta hasta que envejece de forma natural.
SOLUCIÓNHaga coincidir el modo de fijación con el comportamiento real de la red, no con una lista genérica de refuerzo de seguridad. Si el punto de acceso puede cambiar legítimamente, fixed-mac o send-ack es el modo correcto — fixed-all no lo es.
SÍNTOMADos sitios que deberían ser independientes entre sí no pueden comunicarse en absoluto, aunque el propio clúster VRRP de cada sitio funcione bien internamente.
CAUSALa MAC virtual que anuncia un grupo VRRP se deriva de forma determinista de su VRID (00-00-5E-00-01-{VRID}), no se elige de forma independiente. Dos sitios configurados con el mismo VRID — perfectamente posible cuando cada sitio fue construido por un equipo distinto, o a partir de la misma plantilla — terminan generando la misma MAC virtual, y cualquier dispositivo en la ruta entre ellos ve la misma MAC llegando desde dos direcciones.
SOLUCIÓNTrate el VRID como un valor que debe coordinarse en todos los sitios que comparten la misma red troncal, no solo ser único dentro del propio grupo VRRP de un sitio. Renumere el VRID de un sitio para resolver la colisión.
SÍNTOMAEl estado de VRRP cambia con más frecuencia de lo que un evento real de enlace explicaría, o el router «equivocado» sigue convirtiéndose en Master.
CAUSAPor defecto, VRRP se antepone: cualquier router que descubra que su propia prioridad es mayor que la del Master actual toma el control de inmediato, y el Master anterior pasa a Backup. Si los valores de prioridad, el modo de anteposición o el retardo de anteposición no se configuran de forma coherente con el diseño previsto, los routers pueden intercambiar el rol de Master cada vez que una interfaz monitoreada fluctúa o se recalcula la prioridad.
SOLUCIÓNDecida deliberadamente qué router debe tener el rol de Master en condiciones normales, ajuste su prioridad en consecuencia, y configure un retardo de anteposición razonable para que una interfaz inestable no dispare un cambio de rol en cada transición.
SÍNTOMAdisplay vrrp muestra que el grupo está saludable y el Master está activo, pero hacer ping a la propia IP virtual no obtiene respuesta.
CAUSAEste es el comportamiento predeterminado esperado, no una falla — VRRP no responde a los pings dirigidos a la IP virtual a menos que ese comportamiento se active explícitamente.
SOLUCIÓNHabilite vrrp virtual-ip ping enable en la vista de sistema si específicamente necesita que la IP virtual responda a solicitudes ICMP echo con fines de monitoreo.
[HUAWEI] vrrp virtual-ip ping enableExtraídas directamente del campo — las que vale la pena tener respondidas de antemano.
La prioridad lo decide: el router con la prioridad configurada más alta en el grupo se convierte en Master, y el resto permanece en Backup. Con el modo de anteposición predeterminado, cualquier router que descubra posteriormente que su propia prioridad es mayor que la del Master actual toma el control de inmediato, y el antiguo Master vuelve a Backup. En modo sin anteposición, una vez que un router es Master, sigue siéndolo aunque más tarde se una un router de mayor prioridad, siempre que no haya fallado. Una interfaz monitoreada que cae reduce automáticamente la prioridad de ese router en una cantidad configurada, que es cómo las fallas de enlace se reflejan en la elección.
Por defecto, la IP virtual no responde en absoluto a las solicitudes ICMP echo — eso es normal, no una falla. Ejecute vrrp virtual-ip ping enable en la vista de sistema si necesita que responda con fines de monitoreo.
Vale la pena revisar en orden: parámetros de configuración asimétricos entre los dos routers (tipo y clave de autenticación, ID de grupo, lista de IP virtuales, versión de VRRP); el enlace de latido entre los dos routers caído o inestable; un puerto que debería haber sido bloqueado por STP o RRPP y no lo fue; y una utilización de CPU inusualmente alta en uno de los routers que retrasa su procesamiento de hellos VRRP.
Cuando las prioridades son iguales, el router con la dirección IP primaria más alta en la interfaz VRRP se convierte en Master. Este es un caso límite que vale la pena evitar por diseño — asignar deliberadamente prioridades distintas al router primario y de respaldo previstos elimina por completo la ambigüedad.
Sí. Si los dos routers dependen de un enlace de latido dedicado para intercambiar hellos VRRP y ese enlace cae mientras ambos routers están sanos por lo demás, cada lado deja de escuchar al otro y se promueve de forma independiente a Master — exactamente el mismo síntoma final que el Caso 1 anterior, pero con una causa raíz completamente distinta que rastrear.
Estos tres casos provienen de implementaciones VRRP en switches de campus Huawei serie S y clústeres de firewall, usando los comandos display cpu-defend statistics / display trapbuffer / display mac-address mostrados arriba. La lógica subyacente — elección impulsada por prioridad, MAC virtual derivada del VRID, y comportamiento de ARP en torno a una conmutación — se traslada a la mayoría de las implementaciones de la familia VRRP de otros fabricantes, pero la sintaxis exacta de los comandos será distinta. Esta nota no cubre en profundidad VRRP6, el balanceo de carga de VRRP con múltiples routers virtuales por grupo, ni la interoperabilidad con protocolos similares a VRRP de terceros.
Cuéntenos el síntoma — doble maestro, recuperación lenta, o dos sitios que no pueden comunicarse — junto con la salida de display trapbuffer / display mac-address, y le ayudamos a interpretarla.