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

Introduction

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

Prerequisites

Requirements

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

• Conhecimento básico das soluções Meraki
• Conhecimento básico do 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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. 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 vEdge de gateway de upstream conectados em baixo 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. Alerta do switch para DNS BAD

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 de repetidor

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

Troubleshoot

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

Colete o "tcpdump" de ambos os vEdges 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 vEdges do 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 presume que o VE1 está inativo e atua como o VRRP primário.

2. Verifique o comportamento da pilha Meraki.

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

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

A Meraki também confirmou que esse problema foi causado pelo pacote VRRP do VE1 que não chegou ao VE2 através do switch1 membro da pilha (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.