XOps Network Playbook - Solucionar problemas de WAN alternativa

Resumen

WAN alternativa (Alt. WAN) permite a las organizaciones mejorar su conectividad de red ofreciendo soluciones flexibles y resilientes de gestión de tráfico WAN. Soporta dos tipos de configuraciones: Capa-2 para Sockets en la misma subred y Capa-3 para Sockets en diferentes redes. Para más detalles sobre la implementación, consulte Integrar-Cato-con-Red-WAN-Alternativa.

Este artículo cubre problemas comunes con Alt. WAN y proporciona pasos de solución de problemas para resolverlos.

Síntomas

Aquí hay algunos síntomas comunes cuando Alt. WAN no funciona como se esperaba:

La Alt. conexión WAN no se establece
CMA muestra el sitio como desconectado a pesar de que el tráfico fluye a través de Alt. WAN
Reset de conexión TLS por parte del servidor al usar Alt. WAN
Autorreparación WAN para Alt. falló cuando el túnel principal se cayó
La conexión BGP no se establece a través de Alt. WAN

Posibles causas

Configuración incorrecta
UDP/20049 está bloqueado entre Alt. Sitios WAN
CPU alta del Socket

Solucionando el problema

Los túneles de WAN alternativa no se establecen

Revisar configuración

Para asegurar la configuración correcta, navegue al sitio del Socket donde está habilitada la WAN alternativa. Vaya a Red > Sitio > Socket y verifique que el Estado del Puerto para la interfaz de WAN alternativa muestre como UP.
Si el estado muestra Down, revise la conexión del puerto para confirmar que esté adecuadamente conectado a la red.
Asegúrese de que la interfaz esté configurada con la opción correcta: ya sea WAN Alternativa (Capa-2) o WAN Alternativa (Capa-3).
A continuación, confirme que las direcciones IP y la configuración de subred estén configuradas con precisión.
Para confirmar que los túneles de WAN alternativa están activos, acceda al Socket usando el Socket WebUI. Si los túneles de WAN alternativa están exitosamente establecidos, mostrará el número de canales conectados bajo los Túneles SDWAN.
.

Asegúrate de que el puerto UDP 20049 no esté bloqueado

El túnel de WAN alternativa se establece sobre UDP/20049.
Acceda al SocketUI de ambos Sockets y navegue a la pestaña de Captura de Tráfico.
Seleccione la interfaz WAN que Alt. WAN está configurada y comienza a capturar para el protocolo UDP.

El PCAP debería mostrar tráfico bidireccional en el puerto UDP 20049. Si no ves flujo bidireccional, verifica si algún dispositivo entre los 2 sitios está bloqueando UDP/20049.

Nota: En la configuración de Capa 2 de WAN Alternativa, el túnel se inicia usando la IP de WAN Alternativa. En contraste, con una configuración de Capa 3 de WAN Alternativa, el túnel se inicia usando la IP local de la subred nativa. La tabla a continuación resalta las diferencias en el flujo de tráfico entre las configuraciones de Capa 2 y Capa 3, específicamente enfocándose en la IP de origen del túnel.

CAPA 2

CAPA 3

El túnel de WAN Alternativa se originará desde la IP de WAN Alternativa. Una captura de paquetes desde la interfaz de WAN Alternativa muestra que el túnel se inició desde la dirección IP 192.168.20.2, estableciendo conexiones con las IPs de WAN Alternativas de los sitios remotos: 192.168.20.3 y 192.168.20.4.

Aunque la dirección IP de WAN Alternativa está configurada como 192.168.20.2 en la UI de Socket, el túnel de WAN Alternativa no se origina desde esta IP. Una captura de paquetes desde la interfaz de WAN Alternativa muestra que el túnel, en cambio, se origina desde 192.168.2.1 y establece conexiones con las IPs locales nativas de los sitios remotos configurados para WAN Alternativa: 192.168.3.1 y 192.168.4.1.

El sitio está desconectado en CMA a pesar de que el tráfico fluye a través de Alt. WAN

El sitio parece desconectado en el CMA porque el túnel hacia la Nube Cato está abajo.
El tráfico continúa fluyendo a través de la Alt. vínculo WAN asegura operaciones de red, pero el CMA registra el sitio como fuera de línea porque no puede ser alcanzado.
Para restaurar la visibilidad en CMA, solucione el problema y restablezca la conexión del túnel hacia la Nube Cato. Para los pasos de solución de problemas detallados, consulte Socket-Site-Tunnel-Connectivity-Troubleshooting.

Error de conexión TLS en Alt. Vínculos WAN

Se configuró una regla de red explícitamente para usar Alt. WAN como transporte principal
Revisar el UI de Socket muestra que el Alt. túnel WAN está arriba.
Sin embargo, el servidor constantemente reinicia la aplicación TLS cuando se atraviesa usando Alt. WAN.
En este escenario, es crucial asegurarse de que no exista una regla de red compleja por encima de la regla Alt. regla WAN debido a cómo se procesan las reglas complejas dentro de la red. Una regla de red compleja es aquella que el Socket no puede evaluar directamente. Por lo tanto, cuando una regla compleja aparece por encima de la regla Alt. Regla WAN, el Socket envía el tráfico al PoP para determinar el manejo de la red apropiado.
Este proceso puede resultar en un flujo asimétrico cuando el tráfico de retorno atraviesa sobre el Alt. vínculo WAN, causando finalmente que el servidor reinicie la conexión.
Para más información sobre la regla compleja, consulte Explicando-la-Aceleración-TCP-de-Cato-y-Mejores-Prácticas, bajo la Sección "Trabajando con Reglas de Red Complejas"
Consulte Solución para Error de Conexión TLS en Alt. Vínculos WAN sobre cómo resolver este problema.

Recuperación WAN a Alt. WAN no ocurrió cuando el túnel principal se cayó

Por defecto, la recuperación WAN no está habilitada para Alt. WAN. Esta es considerada una característica limitada, y si desea optar por ella, puede enviar su solicitud a su Representante de Cato.
Consulte Recuperar-Conectividad-con-Vínculos-WAN-Alt para más detalles.

BGP falla al establecer conexión

Se ha configurado peering de BGP entre el router BGP del cliente y el Socket a través del vínculo Alt. vínculo WAN, pero la conexión BGP no se establece.
En este caso, la configuración de Alt. WAN en el Socket es la siguiente:
Los registros del router BGP muestran que el siguiente salto especificado es inválido. Una posible razón es que el siguiente salto anunciado en la actualización BGP es inalcanzable a través del peer BGP.

%BGP-5-ADJCHANGE: vecino 192.168.200.1 Arriba
%BGP-3-NOTIFICACIÓN: recibido de vecino 192.168.200.1 3/8 (siguiente salto inválido especificado) 4 bytes 0AFD0011

Una solución potencial es usar el comando next-hop-self en la configuración BGP. Este comando instruye al router para anunciarse a sí mismo como el siguiente salto para las rutas, asegurándose de que las rutas anunciadas tengan una dirección IP de siguiente salto alcanzable para el vecino BGP receptor.
Consulte Solución para el fallo de BGP al establecer conexión para los detalles.

Verificar rendimiento de la CPU del Socket

La utilización consistente de la CPU por encima del 90% puede impactar negativamente en el rendimiento del socket y causar pérdida de paquetes y túneles no establecidos o desconexiones frecuentes.
Para ver el uso histórico de la CPU por núcleo, navegue a Análisis de Red y seleccione la Pestaña de Hardware.
Para el uso de CPU del Socket en tiempo real, navegue a la WebUI del Socket y seleccione la pestaña de Estado de HW.
En caso de detectar alta CPU constante, contacte con Soporte.

Resolviendo problemas descubiertos

Solución para el fallo de conexión TLS en Alt. Vínculos WAN

Una conexión TLS entre dos sitios Cato puede fallar cuando se usa un vínculo Off-Cloud o Alt-WAN si una regla de red simple se coloca debajo de una regla compleja que involucra aplicaciones definidas.
Esto ocurre porque el proxy TCP se aplica, haciendo que el saludo TCP pase a través de la Nube Cato mientras el paquete de datos atraviesa Alt. WAN, lo que lleva a un reinicio de conexión.
La solución es mover la regla simple de Off-Cloud o Alt-WAN por encima de cualquier regla compleja o, alternativamente, deshabilitar la inspección TLS para evitar la aplicación del proxy TCP.
Para detalles sobre este problema, consulte Fallo de Conexión TLS Sobre Vínculos Off-Cloud o Alt-WAN

Solución para el fallo de BGP al establecer conexión

El cliente debe asegurarse de que el siguiente salto para la ruta predeterminada esté configurado correctamente en su router BGP. En el router del cliente, configure la ruta predeterminada usando una de las siguientes opciones:
1. Use el comando next-hop-self para establecer el siguiente salto como la IP de WAN alternativa del vecino BGP:
```
vecino <IP de WAN Alternativa de Socket> next-hop-self
```
2. Aplique un mapa de ruta para establecer explícitamente el siguiente salto a la IP de la interfaz de WAN alternativa del router:
```
mapa de ruta <nombre-del-mapa> permitir 10
 establecer ip siguiente-salto <IP de Interfaz de WAN Alternativa del Router>
```

Limitaciones/Notas

Cuando Alt. WAN se configura en un sitio HA, Alt. vínculo WAN se establece solo con el Socket Principal. Por lo tanto, en condiciones normales, solo el Socket Principal establecerá el Alt. túnel WAN con sitios remotos.