Identificar e Solucionar Problemas de VRRP Ativo-Ativo no Roteador Viptela SD-WAN

Introdução

Este documento descreve como resolver o Virtual Router Redundancy Protocol (VRRP) do roteador Viptela SD-WAN preso no estado Ativo-Ativo.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Conhecimento básico das soluções Meraki
• Conhecimento básico de VRRP

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• vEdge 2000, versão 19.2.3
• MS250-48FP, Versão MS 12.28

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Topologia

Sintoma 1. VRRP no Estado Ativo-Ativo

Ambos os dispositivos de gateway upstream vEdge conectados de forma descendente aos switches de pilha Meraki atuam como VRRP primário.

VE1# show vrrp



MASTER PREFIX

GROUP VRRP OMP ADVERTISEMENT DOWN LIST

VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME TRACK PREFIX LIST STATE

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

11 10ge0/0.670 1 10.17.69.1 00:00:5e:00:01:01 110 master up 1 3 2021-10-12T02:16:49+00:00 Default_Route_Prefix_List resolved





VE2# show vrrp



MASTER PREFIX

GROUP VRRP OMP ADVERTISEMENT DOWN LIST

VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME TRACK PREFIX LIST STATE

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

11 10ge0/0.670 1 10.17.69.1 00:00:5e:00:01:01 100 master up 1 3 2021-10-12T02:16:40+00:00 Default_Route_Prefix_List resolved

Sintoma 2. Switch Alertado para DNS INVÁLIDO

O switch 2 conectado ao VE2 foi alertado sobre "O DNS está configurado incorretamente" no painel da Meraki.

Sintoma 3. Os APs Entram no Modo Repetidor

Os APs conectados ao Switch 2 foram para o modo de repetidor, já que o Switch não tem acessibilidade de gateway.

Troubleshooting

1. Verifique o comportamento do VRRP a partir das Bordas.

Colete o "tcpdump" de ambas as Bordas e verifique o status do pacote VRRP. Nesse caso, observe que os pacotes VRRP recebem e enviam por VE1. Mas nenhum pacote VRRP é recebido de VE1 para VE2.  No entanto, o mesmo foi enviado do VE1. Portanto, você pode confirmar que não há problemas com a funcionalidade de Bordas de gateway.

Do VE1:

    10.17.69.3 > 224.0.0.18: vrrp 10.17.69.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.17.69.1

08:57:12.744406 80:b7:09:32:e5:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 6968, offset 0, flags [DF], proto VRRP (112), length 40)

    10.17.69.2 > 224.0.0.18: vrrp 10.17.69.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 110, authtype none, intvl 1s, length 20, addrs: 10.17.69.1

08:57:13.708034 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 56: (tos 0xc0, ttl 255, id 29924, offset 0, flags [DF], proto VRRP (112), length 40)

Do VE2:

10.17.69.3 > 224.0.0.18: vrrp 10.17.69.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.17.69.1

08:57:50.644532 80:b7:09:31:82:a2 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 31817, offset 0, flags [DF], proto VRRP (112), length 40)

Nenhum pacote VRRP do VE1 (10.17.69.2), portanto, o VE2 supõe que o VE1 está desativado e atua como VRRP primário.

2. Verifique o comportamento da pilha da Meraki.

O painel da Meraki indica que o AP4 e o AP3 estão no modo de repetidor conectado ao switch de uplink2, que recebe o alerta de DNS inválido.

Para confirmar o status da pilha, abra o Meraki TAC como as mensagens de comunicação da pilha são visíveis apenas para o Meraki TAC. Na verificação, é identificado que há problemas de comunicação entre os switches primário e secundário na pilha.

A Meraki também confirmou que esse problema foi causado pelo pacote VRRP de VE1 não alcançado para VE2 através do switch membro da pilha 1(primário) através do membro da pilha 2. Esse é um problema conhecido no código 12.28.

Solução

1. Recarregue todos os switches membros na pilha (correção temporária).
2. Atualize o firmware do switch Meraki para a versão estável mais recente.