Fehlerbehebung bei aktiv-aktiven VRRP-Problemen mit dem SD-WAN-Router von Viptela

Einleitung

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

Voraussetzungen

Anforderungen

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

• Grundkenntnisse der Meraki-Lösungen
• Grundkenntnisse des 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 verstehen.

Topologie

Symptom 1. VRRP im Aktiv-Aktiv-Status

Beide Upstream-Gateway-vEdge-Geräte, die nach unten mit Meraki Stack-Switches verbunden sind, fungieren als primäres 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

Symptom 2. Switch wird für BAD DNS alarmiert

Switch 2, der mit VE2 verbunden ist, wurde im Meraki Dashboard über "DNS ist falsch konfiguriert" informiert.

Symptom 3. APs wechseln in Repeater-Modus

An Switch 2 angeschlossene APs wechselten in den Repeater-Modus, da der Switch nicht über Gateway-Erreichbarkeit verfügt.

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 bemerkt, dass VRRP-Pakete von VE1 empfangen und gesendet werden. Es werden jedoch keine VRRP-Pakete von VE1 bis VE2 empfangen.  Gleiches wurde jedoch von VE1 gesendet. Daher können Sie bestätigen, dass es keine Probleme mit der Gateway-vEdges-Funktionalität gibt.

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 ausgefallen ist und als primäres VRRP agiert.

2. Überprüfen Sie das Meraki Stack-Verhalten.

Das Meraki-Dashboard gibt an, dass sich AP4 und AP3 im Repeater-Modus befinden, der mit dem Uplink-Switch2 verbunden ist, der die Warnmeldung für einen 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 Überprüfung wird festgestellt, dass die Kommunikation innerhalb des Stacks zwischen den primären und sekundären Switches im Stack Probleme verursacht.

Meraki bestätigte außerdem, dass dieses Problem durch das VRRP-Paket von VE1 verursacht wurde, das nicht über Stack-Member-Switch1 (primär) über Stack-Element 2 auf VE2 erreicht wurde. Dies ist ein bekanntes Problem im Code 12.28.

Lösung

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