Fehlerbehebung bei Aktiv/Aktiv-VRRP-Problemen bei Viptela SD-WAN-Routern

Einleitung

In diesem Dokument wird beschrieben, wie das Virtual Router Redundancy Protocol (VRRP) des Viptela SD-WAN-Routers aufgelöst wird, das im Aktiv-Aktiv-Status feststeckt.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse der Meraki Lösungen
• Grundkenntnisse von VRRP

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

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

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Topologie

Symptom 1. VRRP im Aktiv-Aktiv-Zustand

Beide vEdge-Geräte am Upstream-Gateway, die abwärts mit den Meraki Stack-Switches verbunden sind, fungieren als primäre VRRP-Geräte.

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

Symptom 2. Switch-Alarm wegen fehlerhafter DNS

Switch 2, der mit VE2 verbunden war, wurde im Meraki Dashboard auf "DNS is misconfigured" (DNS ist falsch konfiguriert) hingewiesen.

Symptom 3. APs gehen in Repeater-Modus

APs, die mit Switch 2 verbunden sind, wechselten in den Repeater-Modus, da der Switch keine Gateway-Erreichbarkeit besitzt.

Fehlerbehebung

1. Überprüfen Sie das VRRP-Verhalten von vEdges.

Erfassen Sie den "tcpdump" von beiden vEdges, und überprüfen Sie den VRRP-Paketstatus. In diesem Fall wurde festgestellt, dass VRRP-Pakete von VE1 empfangen und gesendet werden. Es werden jedoch keine VRRP-Pakete von VE1 bis VE2 empfangen.  Dasselbe wurde jedoch von VE1 gesendet. Sie können daher bestätigen, dass keine Probleme mit der Gateway-vEdges-Funktion vorliegen.

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

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

Kein VRRP-Paket von VE1 (10.17.69.2), daher geht VE2 davon aus, dass VE1 inaktiv ist und als VRRP-primär agiert.

2. Überprüfen des Meraki Stack-Verhaltens

Das Meraki Dashboard zeigt an, dass sich AP4 und AP3 im Repeater-Modus befinden, der mit dem Uplink-Switch2 verbunden ist, der eine Warnung wegen eines fehlerhaften DNS erhält.

Um den Stack-Status zu bestätigen, öffnen Sie das Meraki TAC, da die Stack-Kommunikationsmassagen nur für das Meraki TAC sichtbar sind. Bei der Verifizierung wird festgestellt, dass die Kommunikation im Stack zwischen dem primären und dem sekundären Switch im Stack Probleme verursacht.

Meraki bestätigte außerdem, dass dieses Problem durch das VRRP-Paket von VE1 verursacht wurde, das über Stack member switch1 (primary) über Stack member 2 nicht an VE2 erreicht wurde. Dieses Problem ist im Code 12.28 bekannt.

Lösung

1. Laden Sie alle Switches im Stack neu (temporäre Korrektur).
2. Aktualisieren Sie die Meraki Switch-Firmware auf die neueste stabile Version.