Introduction
Ce document décrit comment résoudre le protocole VRRP (Virtual Router Redundancy Protocol) du routeur SD-WAN Viptela bloqué dans l'état Actif-Actif.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Connaissances de base des solutions Meraki
- Connaissances de base du protocole VRRP
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- vEdge 2000, version 19.2.3
- MS250-48FP, version 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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Topologie

Symptôme 1. VRRP à l’état actif-actif
Les deux périphériques vEdge de passerelle en amont connectés vers le bas aux commutateurs de pile Meraki agissent en tant que VRRP principal.
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
Symptôme 2. Commutateur alerté pour DNS incorrect
Le commutateur 2 connecté à VE2 a été alerté pour « DNS is misconfigured » (DNS mal configuré) dans le tableau de bord Meraki.

Symptôme 3. Les points d’accès passent en mode répéteur
Les points d’accès connectés au commutateur 2 sont passés en mode répéteur car le commutateur n’a pas d’accessibilité de passerelle.

Dépannage
- Vérifiez le comportement VRRP à partir des vEdge.
Collectez le « tcpdump » à partir des deux vEdge et vérifiez l'état du paquet VRRP. Dans ce cas, vous avez remarqué que les paquets VRRP sont reçus et envoyés par VE1. Mais aucun paquet VRRP n'est reçu de VE1 à VE2. Cependant, la même chose a été envoyée à partir de VE1. Vous pouvez donc confirmer qu'il n'y a aucun problème avec la fonctionnalité vEdge de passerelle.
À partir de 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)
À partir de 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)
Aucun paquet VRRP provenant de VE1 (10.17.69.2), VE2 suppose donc que VE1 est inactif et agit comme VRRP principal.
- vérification du comportement de la pile Meraki
Le tableau de bord Meraki indique que les points d'accès AP4 et AP3 sont en mode répéteur qui est connecté au commutateur de liaison ascendante 2 qui reçoit l'alerte pour un DNS incorrect.
Pour confirmer l'état de la pile, ouvrez le centre d'assistance technique Meraki, car les massages de communication de la pile ne sont visibles que par le centre d'assistance technique Meraki. Lors de la vérification, il est identifié que des problèmes de communication intra-pile surviennent entre les commutateurs principal et secondaire dans la pile.
Meraki a également confirmé que ce problème était dû au fait que le paquet VRRP de VE1 n'était pas accessible à VE2 via le commutateur membre de pile 1(principal) via le membre de pile 2. Il s'agit d'un problème connu dans le code 12.28.
Solution
- Recharger tous les commutateurs membres de la pile (correction temporaire).
- Mettez à niveau le micrologiciel du commutateur Meraki vers la dernière version stable.