Resolución de Problemas de VRRP Activo-Activo en el Router Viptela SD-WAN

Introducción

Este documento describe cómo resolver el Protocolo de redundancia de router virtual (VRRP) del router SD-WAN de Viptela detenido en el estado Activo-Activo.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimientos básicos de las soluciones Meraki
• Conocimientos básicos de VRRP

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• vEdge 2000, versión 19.2.3
• MS250-48FP, versión MS 12.28

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Topología

Síntoma 1. VRRP en estado Activo-Activo

Ambos dispositivos vEdge de gateway ascendente conectados hacia abajo a switches de pila Meraki actúan como 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

Síntoma 2. Interruptor alertado por DNS incorrecto

El switch 2 que se conectó a VE2 recibió una alerta de "DNS mal configurado" en el panel de Meraki.

Síntoma 3. Los AP entran en modo Repetidor

Los AP conectados al Switch 2 pasaron al modo repetidor dado que el Switch no tiene alcance de gateway.

Troubleshoot

1. Verifique el comportamiento de VRRP desde vEdges.

Recopile el "tcpdump" de ambos vEdges y verifique el estado del paquete VRRP. En este caso, observe que los paquetes VRRP reciben y envían por VE1. Pero no se reciben paquetes VRRP de VE1 a VE2.  Sin embargo, se ha enviado el mismo mensaje desde VE1. Por lo tanto, puede confirmar que no hay problemas con la funcionalidad de vEdges de la puerta de enlace.

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

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

Ningún paquete VRRP de VE1 (10.17.69.2), por lo tanto, VE2 asume que VE1 está inactivo y actúa como VRRP principal.

2. Verifique el comportamiento de la pila Meraki.

El panel de Meraki indica que AP4 y AP3 están en modo repetidor que está conectado al switch de enlace ascendente 2 que recibe la alerta para el mal DNS.

Para confirmar el estado de la pila, abra el TAC de Meraki, ya que los masajes de comunicación de la pila solo los puede ver el TAC de Meraki. Al realizar la verificación, se identifica que existen problemas de comunicación dentro de la pila entre los switches primarios y secundarios de la pila.

Meraki también confirmó que este problema se debía a que el paquete VRRP de VE1 no se alcanzó a VE2 a través del switch 1 del miembro de la pila (principal) hasta el miembro de la pila 2. Se trata de un problema conocido en el código 12.28.

Solución

1. Recargue todos los switches miembros de la pila (corrección temporal).
2. Actualice el firmware del switch Meraki a la versión estable más reciente.