XOps Network Playbook - Dépannage Alternative WAN

Vue d'ensemble

WAN alternative (Alt. WAN) permet aux organisations d'améliorer leur connectivité réseau en offrant des solutions de gestion du trafic WAN flexibles et résilientes. Il prend en charge deux types de configurations : le couche 2 pour les sockets du même sous-réseau et le couche 3 pour les sockets sur différents réseaux. Pour plus de détails sur le déploiement, reportez-vous à Intégrer Cato avec Alternative WAN Network.

Cet article couvre les problèmes courants avec Alt. WAN et fournit des étapes de dépannage pour les résoudre.

Symptômes

Voici quelques symptômes courants lorsque Alt. WAN ne fonctionne pas comme prévu :

La connexion Alt. WAN échoue à s'établir
CMA montre le site comme déconnecté malgré le trafic passant par Alt. WAN
Connexion TLS réinitialisée par le serveur lors de l'utilisation de Alt. WAN
La récupération WAN vers Alt. WAN a échoué lorsque le tunnel principal est tombé
La connexion BGP échoue à être établie via Alt. WAN

Causes possibles

Mauvaise configuration
UDP/20049 est bloqué entre les sites Alt. WAN
CPU élevé du socket

Dépannage du problème

Les tunnels WAN alternatifs ne s'établissent pas

Réviser la configuration

Pour garantir une configuration correcte, accédez au site du socket où le WAN alternatif est activé. Allez dans Réseau > Site > Socket et vérifiez que le Statut du port pour l'interface WAN alternatif est affiché comme Activé.
Si le statut affiche Inactif, vérifiez la connexion du port pour confirmer qu'il est correctement connecté au réseau.
Assurez-vous que l'interface est configurée avec la bonne option—soit WAN alternatif (couche 2) soit WAN alternative (couche 3).
Ensuite, confirmez que les adresses IP et les paramètres de sous-réseau sont correctement configurés.
Pour confirmer que les tunnels WAN alternatifs sont actifs, accédez au socket via le Socket WebUI. Si les tunnels WAN alternatifs sont établis avec succès, il affichera le nombre de canaux connectés sous les Tunnels SDWAN.
.

Assurez-vous que le port UDP 20049 n'est pas bloqué

Le tunnel WAN alternatif est établi sur UDP/20049.
Accédez au SocketUI des deux sockets et allez dans l'onglet de capture de trafic.
Sélectionnez l'interface WAN sur laquelle l'Alt. Le WAN est configuré et commence à capturer pour le protocole UDP.

Le PCAP doit montrer un trafic bidirectionnel sur le port UDP 20049. Si vous ne voyez pas de flux bidirectionnel, vérifiez si des appareils entre les deux sites bloquent UDP/20049.

Remarque : Dans la configuration WAN alternative de couche 2, le tunnel est initié en utilisant l'IP WAN alternative. En revanche, avec une configuration WAN alternative de couche 3, le tunnel est initié en utilisant l'IP locale du sous-réseau natif. Le tableau ci-dessous met en évidence les différences de flux de trafic entre les configurations de couche 2 et de couche 3, en se concentrant spécifiquement sur l'IP source du tunnel.

COUCHE 2

COUCHE 3

Le tunnel WAN alternatif proviendra de l'IP WAN alternative. Une capture de paquets à partir de l'interface WAN alternative montre que le tunnel a été initié depuis l'adresse IP 192.168.20.2, établissant des connexions avec les IP WAN alternatives des sites distants : 192.168.20.3 et 192.168.20.4.

Bien que l'adresse IP WAN alternative soit configurée comme 192.168.20.2 dans le Socket UI, le tunnel WAN alternatif ne provient pas de cette IP. Une capture de paquets à partir de l'interface WAN alternative montre que le tunnel provient en fait de 192.168.2.1 et établit des connexions avec les IP locales natives des sites distants configurés pour le WAN alternatif : 192.168.3.1 et 192.168.4.1.

Le site est déconnecté dans le CMA malgré le trafic traversant Alt. WAN

Le site apparaît comme déconnecté dans le CMA car le tunnel vers le Cato Cloud est hors service.
Le trafic continue de circuler à travers le lien Alt. Le lien WAN assure les opérations réseau, mais le CMA considère le site hors ligne car il ne peut pas être atteint.
Pour restaurer la visibilité dans le CMA, dépannez et rétablissez la connexion du tunnel vers le Cato Cloud. Pour des étapes de dépannage détaillées, veuillez consulter Dépannage de la connectivité du tunnel Site-Socket.

Échec de la connexion TLS sur Alt. Liens WAN

Une règle réseau a été configurée explicitement pour utiliser Alt. WAN comme transport principal
La vérification de l'interface utilisateur du Socket montre que le tunnel Alt. Le tunnel WAN est opérationnel.
Cependant, le serveur réinitialise constamment l'application TLS lorsqu'elle traverse en utilisant l'Alt. WAN.
Dans ce scénario, il est crucial de s'assurer qu'aucune règle réseau complexe n'existe au-dessus de la règle Alt. La règle WAN en raison de la façon dont les règles complexes sont traitées au sein du réseau. Une règle réseau complexe est celle que le Socket ne peut pas évaluer directement. Par conséquent, lorsqu'une règle complexe apparaît au-dessus de la règle Alt. Règle WAN, le Socket envoie le trafic au PoP pour déterminer le traitement réseau approprié.
Ce processus peut entraîner un flux asymétrique lorsque le trafic de retour traverse le lien Alt. Lien WAN, ce qui entraîne finalement le serveur à réinitialiser la connexion.
Pour plus d'informations sur la règle complexe, reportez-vous à Explication de l'accélération TCP de Cato et des meilleures pratiques, sous la section "Travailler avec des règles réseau complexes"
Consultez Solution pour la défaillance de la connexion TLS sur Alt. Liens WAN sur la façon de résoudre ce problème.

Récupération du WAN vers Alt. WAN n'a pas eu lieu lorsque le tunnel principal est tombé en panne

Par défaut, la récupération WAN n'est pas activée pour Alt. WAN. C'est considéré comme une fonctionnalité limitée, et si vous souhaitez la choisir, vous pouvez envoyer votre demande à votre représentant Cato.
Consultez Récupérer la Connectivité avec Alt-WAN Liens pour plus de détails.

Échec de l'établissement de la connexion BGP

Le peering BGP a été configuré entre le routeur BGP du client et le socket via le lien Alt. Le lien WAN, mais la connexion BGP ne parvient pas à s'établir.
Dans ce cas, la configuration WAN Alt. La configuration WAN sur le socket est la suivante :
Les journaux du routeur BGP indiquent que le prochain saut spécifié est invalide. Une raison possible est que le prochain saut annoncé dans la mise à jour BGP est inaccessible via le pair BGP.

%BGP-5-ADJCHANGE: voisin 192.168.200.1 Up
%BGP-3-NOTIFICATION: reçu du voisin 192.168.200.1 3/8 (prochain saut invalide spécifié) 4 octets 0AFD0011

Une solution potentielle est d'utiliser la commande next-hop-self dans la configuration BGP. Cette commande indique au routeur de se déclarer comme le prochain saut pour les routes, garantissant que les routes annoncées ont une adresse IP de prochain saut accessible pour le voisin BGP récepteur.
Consultez Solution pour Échec de l'établissement de la connexion BGP pour les détails.

Vérifiez la performance CPU du socket

Une utilisation constante du CPU supérieure à 90 % peut avoir un impact négatif sur les performances du socket et provoquer une perte de paquets et des tunnels non établis ou des déconnexions fréquentes.
Pour voir l'utilisation historique du CPU par cœur, parcourez les Analyses Réseau et sélectionnez l'onglet Matériel.
Pour l'utilisation du CPU du socket en temps réel, parcourez le Socket WebUI et sélectionnez l'onglet HM Statut.
En cas de détection d'un CPU constamment élevé, contactez le Support.

Résolution des Problèmes Découverts

Solution pour l'Échec de la Connexion TLS sur Alt. Liens WAN

Une connexion TLS entre deux sites Cato peut échouer lorsqu'un lien hors-nuage ou Alt-WAN est utilisé si une règle réseau simple est placée sous une règle complexe impliquant des applications définies.
Cela se produit parce que le proxy TCP est appliqué, provoquant le passage de la poignée de main TCP par le Cato Cloud tandis que le paquet de données traverse le Alt. WAN, entraînant une réinitialisation de la connexion.
La solution consiste à déplacer la règle simple hors-nuage ou Alt-WAN au-dessus de toute règle complexe ou, alternativement, à désactiver l'inspection TLS pour éviter l'application du proxy TCP.
Pour des détails sur ce problème, reportez-vous à Échec de la Connexion TLS via des Liens Off-Cloud ou Alt-WAN

Solution pour l'Échec de l'Établissement de la Connexion BGP

Le client doit s'assurer que le prochain saut pour la route par défaut est correctement configuré sur leur routeur BGP. Sur le routeur du client, configurez la route par défaut en utilisant l'une des options suivantes :
1. Utilisez la commande next-hop-self pour définir le prochain saut comme l'adresse IP WAN alternative du voisin BGP :
```
voisin <Socket Alternative WAN IP> next-hop-self
```
2. Appliquez une carte de route pour définir explicitement le prochain saut sur l'adresse IP WAN alternative du routeur :
```
carte de route <nom de la carte> permit 10
   définir ip next-hop <Adresse IP Interface WAN Alternative du Routeur>
```

Limitations/Remarques

Lorsque Alt. WAN est configuré sur un site HA, Alt. Le tunnel WAN est établi uniquement avec le Socket Maître. Par conséquent, dans des conditions normales, seul le Socket Maître établira le Alt. Tunnel WAN avec des sites distants.