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

Introducción

Este documento describe cómo resolver el protocolo de redundancia de router virtual (VRRP) de Vptela SD-WAN atascado en el estado Activo-Activo.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico de las soluciones Meraki
• Conocimiento básico 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

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 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 los switches de pila Meraki actúan como VRRP primario.

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. Se alerta al switch para DNS BAD

El switch 2 que se conectó a VE2 fue alertado de "DNS está mal configurado" en el panel de Meraki.

Síntoma 3. Los AP entran en el modo repetidor

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

Troubleshoot

1. Verifique el comportamiento de VRRP desde los bordes.

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 lo mismo desde VE1. Por lo tanto, puede confirmar que no hay problemas con la funcionalidad de vEdges de gateway.

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 que VE2 asume que VE1 está inactivo y actúa como VRRP primario.

2. Verifique el comportamiento de la pila Meraki.

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

Para confirmar el estado de la pila, abra el TAC de Meraki, ya que los masajes de comunicación de la pila sólo son visibles para el TAC de Meraki. En la verificación, se identifica que la comunicación dentro de la pila tiene problemas entre los switches primarios y secundarios en la pila.

Meraki también confirmó que este problema fue causado por el paquete VRRP de VE1 no alcanzado a VE2 a través del miembro Stack switch1(primario) a través del miembro stack 2. Este es un problema conocido en el código 12.28.

Solución

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