Introduction
Ce document décrit comment résoudre le VRRP (Virtual Router Redundancy Protocol) du routeur Viptela SD-WAN bloqué à l'état Actif-Actif.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Connaissances de base des solutions Meraki
- Connaissances de base du protocole VRRP
Components Used
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 dans l'état Actif-Actif
Les périphériques vEdge de passerelle en amont connectés vers le bas aux commutateurs de la pile Meraki agissent comme des périphériques VRRP principaux.
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 BAD DNS
Le commutateur 2 connecté à VE2 a été alerté pour “ DNS est 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 contours.
Collectez les ” tcpdump “ des deux contours et vérifiez l'état du paquet VRRP. Dans ce cas, a remarqué que les paquets VRRP reçoivent et envoient par VE1. Mais aucun paquet VRRP n'est reçu de VE1 à VE2. Cependant, la même chose a été envoyée depuis VE1. Par conséquent, vous pouvez confirmer qu'il n'y a pas de problème avec la fonctionnalité d'arêtes 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 de VE1 (10.17.69.2), par conséquent VE2 suppose que VE1 est désactivé et agit comme VRRP principal.
- Vérifiez le comportement de la pile Meraki.
Le tableau de bord Meraki indique que AP4 et AP3 sont en mode répéteur, connecté au commutateur de liaison ascendante 2, qui reçoit l'alerte en cas d'erreur DNS.
Pour confirmer l'état de la pile, ouvrez le centre d'assistance technique Meraki lorsque les massages de communication de la pile sont visibles uniquement par le centre d'assistance technique Meraki. Lors de la vérification, il est identifié que les problèmes de communication intra-pile entre les commutateurs principal et secondaire de la pile sont identifiés.
Meraki a également confirmé que ce problème était dû au paquet VRRP de VE1 non atteint à VE2 via le commutateur membre de la pile 1 (principal) via le membre de la pile 2. Il s'agit d'un problème connu dans le code 12.28.
Solution
- Rechargez tous les commutateurs membres de la pile (correctif temporaire).
- Mettez à niveau le micrologiciel du commutateur Meraki vers la dernière version stable.