Problemen met VRRP Active-Active oplossen in Viptela SD-WAN Router

Inleiding

In dit document wordt beschreven hoe u het Viptela SD-WAN-router Virtual Router Redundancy Protocol (VRRP) kunt oplossen dat vastzit in de Active-Active-status.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Basiskennis van Meraki Solutions
• Basiskennis van VRRP

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

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

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Topologie

Symptoom 1. VRRP in actieve-actieve toestand

Beide upstream gateway vEdge-apparaten die naar beneden zijn verbonden met Meraki-stack-switches, fungeren als VRRP-primaire apparaten.

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

Symptoom 2. Switch gewaarschuwd voor slechte DNS

Switch 2 die is aangesloten op VE2 is gewaarschuwd voor "DNS is verkeerd geconfigureerd" in het Meraki-dashboard.

Symptoom 3. AP's gaan in de repeatermodus

AP's die zijn verbonden met Switch 2 zijn naar de repeatermodus gegaan omdat de Switch geen gateway-bereikbaarheid heeft.

Problemen oplossen

1. Controleer het VRRP-gedrag van vEdges.

Verzamel de "tcpdump" van beide vEdges en controleer de status van het VRRP-pakket. In dit geval merkte ik dat VRRP-pakketten ontvangen en verzenden door VE1. Maar er worden geen VRRP-pakketten ontvangen van VE1 naar VE2. Hetzelfde is echter verzonden van VE1. Daarom kunt u bevestigen dat er geen problemen zijn met de functionaliteit van gateway vEdges.

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

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

Geen VRRP-pakket van VE1 (10.17.69.2), dus VE2 gaat ervan uit dat VE1 is uitgeschakeld en fungeert als VRRP-primair.

2. Controleer het gedrag van de Meraki-stapel.

Meraki-dashboard geeft aan dat AP4 en AP3 zich in de repeatermodus bevinden die is verbonden met uplink switch 2, die de waarschuwing voor slechte DNS krijgt.

Om de status van de stapel te bevestigen, opent u Meraki TAC omdat de communicatiemassages van de stapel alleen zichtbaar zijn voor Meraki TAC. Bij verificatie wordt vastgesteld dat er problemen zijn met de communicatie binnen de stapel tussen de primaire en secundaire switches in de stapel.

Meraki bevestigde ook dat dit probleem werd veroorzaakt door het VRRP-pakket van VE1 dat niet via Stack Member switch 1 (primair) via Stack Member 2 naar VE2 werd bereikt. Dit is een bekend probleem in de 12.28-code.

Oplossing

1. Herlaad alle switches in de stapel (tijdelijke oplossing).
2. Upgrade de Meraki Switch firmware naar de nieuwste stabiele build.