Risoluzione dei problemi di VRRP attivo-attivo in Viptela SD-WAN Router

Introduzione

Questo documento descrive come risolvere il protocollo Viptela SD-WAN Router Redundancy Protocol (VRRP) bloccato nello stato Active-Active.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Conoscenze base delle soluzioni Meraki
• Conoscenze base di VRRP

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• vEdge 2000, versione 19.2.3
• MS250-48FP, versione MS 12.28

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Topologia

Sintomo 1. VRRP in stato attivo-attivo

I dispositivi vEdge del gateway upstream collegati a valle agli switch dello stack Meraki agiscono come dispositivi primari VRRP.

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

Sintomo 2. Switch avvisato per DNS danneggiato

Lo switch 2 connesso a VE2 è stato avvisato in caso di configurazione errata del DNS nel dashboard Meraki.

Sintomo 3. I punti di accesso vanno in modalità Ripetitore

I punti di accesso collegati allo switch 2 sono passati alla modalità ripetitore perché lo switch non ha la raggiungibilità del gateway.

Risoluzione dei problemi

1. Verificare il comportamento del protocollo VRRP da vEdges.

Raccogliere "tcpdump" da entrambi i vEdge e verificare lo stato del pacchetto VRRP. In questo caso, si è notato che i pacchetti VRRP vengono ricevuti e inviati da VE1, ma non vengono ricevuti pacchetti VRRP da VE1 a VE2.  Tuttavia, lo stesso messaggio è stato inviato da VE1. È quindi possibile confermare che non vi sono problemi con la funzionalità gateway Edge.

Dalla 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)

Da 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)

Nessun pacchetto VRRP da VE1 (10.17.69.2), quindi VE2 presuppone che VE1 sia inattivo e agisce come primario VRRP.

2. Verificare il comportamento dello stack Meraki.

Il dashboard Meraki indica che AP4 e AP3 sono in modalità ripetitore, connessa allo switch2 uplink che riceve l'avviso per il DNS errato.

Per confermare lo stato dello stack, aprire Meraki TAC perché i massaggi di comunicazione dello stack sono visibili solo a Meraki TAC. Dopo una verifica, viene identificato il problema di comunicazione tra gli switch primario e secondario dello stack.

Meraki ha inoltre confermato che il problema è stato causato dal pacchetto VRRP tra VE1 e VE2 non raggiunto tramite il dispositivo switch1 (primario) attraverso il dispositivo membro 2 dello stack. Questo è un problema noto nel codice 12.28.

Soluzione

1. Ricaricare tutti gli switch membri dello stack (correzione temporanea).
2. Aggiornare il firmware dello switch Meraki all'ultima versione stabile.