Início / Notas técnicas / VRRP duplo mestre e falhas de failover

VRRP em produção: duplo mestre, failover lento e a armadilha do VRID duplicado

O VRRP parece simples até deixar de ser: dois roteadores reivindicando ser Master ao mesmo tempo, um failover que tecnicamente funciona mas leva vinte minutos para realmente se recuperar, ou dois sites que geram silenciosamente o mesmo MAC virtual. Três casos reais de campo, os comandos que identificaram cada causa raiz, e o que verificar da próxima vez que o VRRP se comportar mal.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Três formas de o VRRP falhar que nada têm a ver com o próprio VRRP

Nos três casos abaixo, a configuração do VRRP em si estava correta — a falha estava uma camada ao lado, no MSTP, no tratamento de ARP, ou em um segundo site que ninguém havia conferido.

O VRRP em si é um protocolo simples: a prioridade decide quem é Master, e um MAC virtual conhecido derivado do VRID torna o failover invisível para os hosts do segmento. Essa simplicidade é exatamente o motivo pelo qual, quando o VRRP se comporta mal, reler a configuração do VRRP linha por linha costuma ser o primeiro passo errado. Os três casos de campo abaixo remontam todos a algo adjacente ao VRRP — um loop que o STP não havia realmente bloqueado, um recurso de reforço de ARP interagindo mal com uma falha de link, e uma colisão de MAC virtual entre dois sites que nunca foram verificados um contra o outro.

A seguir está cada caso detalhado — a rede em que ocorreu, o sintoma, os comandos que identificaram a causa, e a solução — além das respostas de perguntas frequentes sobre a eleição de Master no VRRP e as causas de duplo mestre que aparecem sempre que esses chamados são discutidos.

Onde olhar primeiro — três sintomas muito diferentes

Duplo mestre, uma recuperação lenta e silêncio total entre dois sites parecem o mesmo protocolo se comportando mal — não são a mesma falha, e não se resolvem da mesma forma.

Colocar primeiro o sintoma nesta árvore indica qual dos casos abaixo é realmente o que você está vendo, e qual recurso fora do próprio VRRP você deve verificar.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Nenhuma dessas três falhas é um bug do protocolo VRRP — o VRRP está expondo um problema que já existia na rede: um loop não bloqueado, um recurso de reforço de ARP que presumia que a topologia nunca mudaria, e um VRID que nunca foi coordenado entre sites. Corrigir o recurso adjacente corrige o VRRP.

Três casos de campo, detalhados

Mesmo protocolo, três causas raiz completamente diferentes — e três conjuntos diferentes de comandos para confirmar cada uma.

Caso 1 — Duplo mestre sob VRRP + MSTP

SwitchA e SwitchB mostravam ambos o estado Master do VRRP ao mesmo tempo; clientes com e sem fio de parte da rede perderam o acesso à internet. A causa não era o VRRP — era um loop que o MSTP não havia realmente bloqueado.

Verifique display cpu-defend statistics all para o tipo de pacote vrrp. Uma grande contagem de Pass junto com uma grande contagem de Drop em pacotes de controle VRRP significa que muito mais tráfego VRRP está chegando à CPU do que dois roteadores trocando hellos jamais gerariam — esse é o primeiro sinal de um loop inundando pacotes VRRP, não uma falha de configuração do VRRP.
Verifique display trapbuffer em busca de um alarme de movimento de MAC (MFLPVLANALARM). Os campos Original-Port e Flapping port do alarme indicam exatamente entre quais portas o mesmo endereço MAC está oscilando.
Rastreie essas duas portas até o switch de acesso abaixo delas — neste caso, um switch a jusante com um loop que o MSTP deveria estar bloqueando, mas não estava.
Elimine o loop na camada de acesso. Assim que o loop é eliminado, o alarme de movimento de MAC para, os contadores de descarte do VRRP param de subir, e o estado de duplo mestre se resolve sozinho — nada em SwitchA ou SwitchB precisa ser alterado.

<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 loop

Caso 2 — O failover funciona, mas a recuperação leva 20 minutos

SwitchA (Master) e SwitchB (Backup) estavam ligados por um cabo de heartbeat; um servidor de dupla conexão estava em ambos. Quando o link do servidor para o SwitchA falhou, o tráfego de fato passou para o caminho de backup — mas o serviço não se recuperou de verdade por 20 minutos.

Primeiro entenda o caminho normal: o SwitchA aprende o ARP do servidor diretamente do seu próprio link; o SwitchB, normalmente ocioso para esse tráfego, aprende o ARP do mesmo servidor indiretamente através da interface de heartbeat via SwitchA.
Quando o link servidor-SwitchA falha, o servidor começa a enviar pelo caminho de backup para o SwitchB, e as respostas do SwitchB chegam bem ao servidor — mas a entrada ARP do SwitchB para o servidor ainda aponta para a interface de heartbeat, então o SwitchB continua encaminhando o tráfego de retorno de volta para o SwitchA, que não tem mais um caminho funcional até o servidor.
Verifique se arp anti-attack entry-check fixed-all enable e arp learning strict force-enable estão configurados em ambos os switches. Com a fixação de ARP ativa no modo fixed-all, a interface de uma entrada ARP existente não é atualizada só porque o tráfego começa a chegar por outra porta — ela só é atualizada quando a entrada antiga envelhece naturalmente, o que é o que realmente consome os 20 minutos.
Desative os dois comandos que estão em conflito com a mudança de topologia, ou escolha um modo de fixação que corresponda ao comportamento real desta rede (veja a armadilha abaixo para os três modos e onde cada um deve ser usado).

[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 out

Caso 3 — Dois sites, o mesmo MAC virtual

Site1 e Site2 se comunicavam através de um backbone; o par de firewalls de cada site executava seu próprio cluster VRRP. O SW-1 conseguia dar ping no SW-2 através do backbone, mas os firewalls dos dois sites não conseguiam se comunicar de forma alguma.

Aplique um classificador de tráfego + política de tráfego com statistic enable na interface de entrada, correspondendo ao tráfego ICMP entre os dois firewalls, e verifique display traffic policy statistics. Uma contagem Matched/Passed diferente de zero com Dropped em zero confirma que o ICMP está realmente chegando — o problema está a jusante deste switch, não um filtro aqui.
Verifique display mac-address para o MAC virtual conhecido do firewall (0000-5e00-0136 neste caso) no switch de trânsito. Ver o mesmo MAC aprendido a partir de duas direções diferentes — uma em direção ao Site1, outra ao Site2 — significa que há um loop, ou que duas instâncias VRRP independentes estão gerando exatamente o mesmo MAC virtual.
Não existia nenhum loop em nenhum lugar desta rede, então a próxima verificação foi a própria configuração VRRP dos firewalls — especificamente o VRID com que cada cluster foi configurado.
Descobriu-se que os clusters de firewall de ambos os sites estavam configurados com o mesmo VRID. Como o MAC virtual é derivado diretamente do VRID como 00-00-5E-00-01-{VRID}, VRIDs idênticos em dois sites independentes produzem exatamente o mesmo MAC virtual, e a rede de trânsito não tem como distinguir os dois. Reconfigure o VRID de um site para um valor que seja único em todos os sites que compartilham o mesmo backbone.

[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 MAC

5 coisas que vale a pena verificar antes de mexer no VRRP

Depois que a árvore acima indicar em qual caso você está, esses cinco pontos explicam a maior parte do que realmente está errado.

1. Um loop em outro lugar da rede se disfarça de falha de duplo mestre do VRRP

SINTOMAAmbos os roteadores VRRP relatam Master simultaneamente; a própria configuração VRRP dos dois roteadores é totalmente consistente ao comparar.

CAUSAUm loop em algum lugar a jusante inunda os anúncios VRRP e corrompe a tabela MAC no caminho entre os dois roteadores, então cada roteador para de ouvir de forma confiável os hellos do outro e decide independentemente que é o único Master restante.

SOLUÇÃONão comece relendo a configuração do VRRP — primeiro verifique display cpu-defend statistics all e display trapbuffer em busca de um alarme de movimento de MAC, e rastreie o loop a partir daí. Veja «Tempestade de loop de camada 2» para o processo completo de caça ao loop.

2. Três modos de fixação de ARP resolvem três problemas diferentes — usar o errado trava o failover

SINTOMAO failover acontece, mas a rede não se recupera de fato até vários minutos depois — não segundos, minutos.

CAUSAA fixação de ARP tem três modos mutuamente exclusivos para situações diferentes: fixed-mac serve para um MAC fixo que se move entre portas de acesso; fixed-all serve quando tanto o MAC quanto o local de acesso permanecem fixos; send-ack serve quando ambos mudam com frequência. Configurar fixed-all em uma topologia em que o ponto de acesso realmente muda — como um servidor de dupla conexão alternando entre dois switches — trava a entrada obsoleta até que ela envelheça naturalmente.

SOLUÇÃOCombine o modo de fixação com o comportamento real da rede, não com uma lista genérica de reforço de segurança. Se o ponto de acesso puder mudar legitimamente, fixed-mac ou send-ack é o modo correto — fixed-all não é.

3. O mesmo VRID em dois sites independentes gera um único MAC virtual em colisão

SINTOMADois sites que deveriam ser independentes entre si não conseguem se comunicar de forma alguma, mesmo que o próprio cluster VRRP de cada site funcione bem internamente.

CAUSAO MAC virtual que um grupo VRRP anuncia é derivado de forma determinística do seu VRID (00-00-5E-00-01-{VRID}), não escolhido de forma independente. Dois sites configurados com o mesmo VRID — perfeitamente plausível quando cada site foi construído por uma equipe diferente, ou a partir do mesmo modelo — acabam gerando o mesmo MAC virtual, e qualquer dispositivo no caminho entre eles vê o mesmo MAC chegando de duas direções.

SOLUÇÃOTrate o VRID como um valor que precisa ser coordenado entre todos os sites que compartilham o mesmo backbone, não apenas único dentro do próprio grupo VRRP de um único site. Renumere o VRID de um site para resolver a colisão.

4. Configurações assimétricas de prioridade ou preempção causam oscilação, não um failover limpo

SINTOMAO estado do VRRP muda com mais frequência do que um evento real de link explicaria, ou o roteador «errado» continua se tornando Master.

CAUSAPor padrão, o VRRP preempta: qualquer roteador que descobrir que sua própria prioridade é maior que a do Master atual assume imediatamente, e o antigo Master volta a ser Backup. Se os valores de prioridade, o modo de preempção ou o atraso de preempção não forem configurados de forma consistente com o design pretendido, os roteadores podem trocar o papel de Master de um lado para o outro toda vez que uma interface monitorada oscilar ou um recálculo de prioridade acontecer.

SOLUÇÃODecida deliberadamente qual roteador deve manter o Master em condições normais, ajuste sua prioridade de acordo, e configure um atraso de preempção sensato para que uma interface oscilante não dispare uma troca de papel a cada transição.

5. O IP virtual do VRRP não responde a ping por padrão

SINTOMAdisplay vrrp mostra que o grupo está saudável e o Master está ativo, mas fazer ping no próprio IP virtual não obtém resposta.

CAUSAEste é o comportamento padrão esperado, não uma falha — o VRRP não responde a pings endereçados ao IP virtual a menos que esse comportamento seja explicitamente ativado.

SOLUÇÃOAtive vrrp virtual-ip ping enable na visão de sistema se você especificamente precisar que o IP virtual responda a requisições ICMP echo para fins de monitoramento.

[HUAWEI] vrrp virtual-ip ping enable

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.

Como o VRRP realmente decide quem se torna Master?

A prioridade decide isso: o roteador com a prioridade configurada mais alta no grupo se torna Master, e o restante permanece Backup. Com o modo de preempção padrão, qualquer roteador que descobrir depois que sua própria prioridade é maior que a do Master atual assume imediatamente, e o antigo Master volta a ser Backup. No modo sem preempção, uma vez que um roteador é Master, ele permanece Master mesmo que um roteador de prioridade maior entre depois, desde que não tenha falhado. Uma interface monitorada que cai reduz automaticamente a prioridade daquele roteador em uma quantidade configurada, e é assim que as falhas de link se refletem na eleição.

Por que não consigo dar ping no endereço IP virtual do VRRP?

Por padrão, o IP virtual não responde a requisições ICMP echo — isso é normal, não uma falha. Execute vrrp virtual-ip ping enable na visão de sistema se precisar que ele responda para fins de monitoramento.

Além de um loop, o que mais pode causar um estado de duplo mestre no VRRP?

Vale a pena verificar em ordem: parâmetros de configuração assimétricos entre os dois roteadores (tipo e chave de autenticação, ID do grupo, lista de IP virtual, versão do VRRP); o link de heartbeat entre os dois roteadores estar caído ou instável; uma porta que deveria ter sido bloqueada pelo STP ou RRPP não bloquear; e utilização de CPU incomumente alta em um dos roteadores atrasando o processamento de hellos do VRRP.

Se ambos os roteadores estiverem configurados com exatamente a mesma prioridade, qual vence?

Quando as prioridades são iguais, o roteador com o endereço IP primário mais alto na interface VRRP se torna Master. Este é um caso extremo que vale a pena evitar por design — atribuir deliberadamente prioridades diferentes ao roteador primário e de backup pretendidos elimina completamente a ambiguidade.

Uma linha de heartbeat do VRRP quebrada sozinha pode causar duplo mestre?

Sim. Se os dois roteadores dependem de um link de heartbeat dedicado para trocar hellos do VRRP e esse link cai enquanto os dois roteadores estão saudáveis por outro lado, cada lado para de ouvir o outro e se promove independentemente a Master — exatamente o mesmo sintoma final do Caso 1 acima, mas com uma causa raiz completamente diferente para rastrear.

Limites honestos desta nota

Limites honestos desta nota

Esses três casos vêm de implantações VRRP em switches de campus Huawei série S e clusters de firewall, usando os comandos display cpu-defend statistics / display trapbuffer / display mac-address mostrados acima. A lógica subjacente — eleição orientada por prioridade, MAC virtual derivado do VRID, e comportamento de ARP em torno de um failover — se aplica à maioria das implementações da família VRRP de outros fabricantes, mas a sintaxe exata dos comandos será diferente. Esta nota não cobre em profundidade o VRRP6, o balanceamento de carga do VRRP com múltiplos roteadores virtuais por grupo, ou a interoperabilidade com protocolos do tipo VRRP de terceiros.

Travado com dois mestres VRRP ou um failover travado?

Conte-nos o sintoma — duplo mestre, recuperação lenta, ou dois sites que não conseguem se comunicar — junto com a saída de display trapbuffer / display mac-address, e ajudamos você a interpretá-la.

WhatsApp com um engenheiro →