Dépannage WAN alternatif

Vue d'ensemble

WAN Alternative (Alt. WAN) permet aux organisations d'améliorer leur connectivité réseau en proposant des solutions de gestion du trafic WAN flexibles et résilientes. Elle prend en charge deux types de configurations : Couche-2 pour les Sockets sur le même sous-réseau et Couche-3 pour les Sockets sur différents réseaux. Pour plus de détails sur le déploiement, consultez Intégrer-Cato-avec-Réseau-WAN-Alternative.

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 de Alt. WAN ne parvient pas à s'établir
  • CMA affiche le site comme déconnecté malgré le trafic passant par Alt. WAN
  • Réinitialisation de la connexion TLS par le serveur lors de l'utilisation d'Alt. WAN
  • Récupération WAN vers Alt. WAN échouée lorsque le tunnel principal est tombé en panne
  • La connexion BGP échoue à être établie via Alt. WAN

Causes possibles

  • Mauvaise configuration
  • UDP/20049 est bloqué entre Alt. Sites WAN
  • Processeur de Socket Élevé

Dépannage du problème

Les tunnels WAN alternatifs ne s'établissent pas

Revoir la configuration

  • Pour assurer une configuration correcte, naviguez jusqu'au Site Socket où le WAN Alternative est activé. Allez à Network > Site > Socket et vérifiez que le Status du Port pour l'interface WAN Alternative est affiché comme UP. 
  • Si le statut affiche Down, 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 l'option correcte—soit WAN Alternative (Couche-2) ou 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 Alternative sont actifs, accédez au Socket en utilisant le WebUI du Socket. Si les tunnels WAN Alternative sont correctement établis, il affichera le nombre de canaux connectés sous Tunnels SDWAN.
  • . 

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

  • Le tunnel WAN Alternative est établi sur UDP/20049.
  • Accéder à l'interface utilisateur de Socket des deux Sockets et naviguer vers l'onglet Capture de Trafic.
  • Sélectionnez l'interface WAN que Alt. WAN est configurée et commence à capturer pour le protocole UDP.
  • Le PCAP devrait montrer un trafic bidirectionnel sur le port UDP 20049. Si vous ne voyez pas de flux bidirectionnel, vérifiez si un appareil entre les 2 sites bloque UDP/20049.

    NOTE :  Dans la configuration de Couche 2 du WAN Alternative, le tunnel est initié en utilisant la IP du WAN Alternative. En revanche, avec une configuration de Couche 3 du WAN Alternative, 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 Couche 3, en se concentrant spécifiquement sur l'IP source du tunnel.

    COUCHE 2

    COUCHE 3

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

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

     

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

  • Le site apparaît déconnecté dans le CMA car le tunnel vers le Cloud Cato est en panne.
  • Le trafic continue de circuler par l'Alt. Le lien WAN assure les opérations du réseau, mais le CMA enregistre le site hors ligne car il ne peut pas être atteint.
  • Pour rétablir la visibilité dans le CMA, dépannez et rétablissez la connexion du tunnel vers le Cloud Cato. Pour les étapes de dépannage détaillées, veuillez consulter Dépannage-de-la-connectivité-du-tunnel-Socket-Site. 

Échec de connexion TLS sur Alt. Liens WAN

  • Une règle réseau a été explicitement configurée pour utiliser Alt. WAN comme transport principal 
  • Vérification de l'UI de Socket montre que le tunnel de Alt. WAN est actif. 
  • 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 de Alt. WAN en raison de la manière 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 de Alt. WAN, le Socket envoie le trafic au PoP pour déterminer le traitement réseau approprié.

  • Ce processus peut aboutir à un flux asymétrique lorsque le trafic de retour traverse le lien Alt. WAN, provoquant finalement le serveur à réinitialiser la connexion.

  • Pour plus d'informations sur la règle complexe, consultez Explication-de-l'accélération-TCP-de-Cato-et-Meilleures-Pratiques, sous la section "Travailler avec des règles réseau complexes"
  • Consultez Solution à l'échec de connexion TLS sur Alt. Liens WAN pour savoir comment résoudre ce problème.

Récupération de 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. Ceci est considéré comme une fonctionnalité limitée, et si vous souhaitez y souscrire, vous pouvez envoyer votre demande à votre représentant Cato.
  • Consultez Récupération-de-la-connectivité-avec-les-liens-Alt-WAN pour plus de détails. 

BGP n'a pas pu établir la connexion

  • Le peering BGP a été configuré entre le routeur BGP du client et le Socket sur le lien Alt. WAN, mais la connexion BGP ne parvient pas à s'établir.
  •  Dans ce cas, la configuration de Alt. 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 Activé
%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 demande au routeur de s'annoncer 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 à BGP n'a pas pu établir la connexion pour les détails.

Vérifiez la Performance du Processeur de Socket

  • Une utilisation constante du processeur au-delà de 90 % peut affecter négativement la performance du socket et causer une perte de paquets et des tunnels non établis ou des déconnexions fréquentes.
  • To view historical CPU usage per core browse to Network Analytics and select the Hardware Tab.
  • Pour l'utilisation en temps réel du processeur de Socket, parcourez l'Interface Web du Socket et sélectionnez l'onglet État matériel.
  • En cas de détection de processeur constamment élevé, contactez le Support.

Résolution des problèmes découverts

Solution à l'échec de connexion TLS sur Alt. Liens WAN

  • Une connexion TLS entre deux sites Cato peut échouer lors de l'utilisation d'un lien Off-Cloud ou Alt-WAN si une règle réseau simple est placée en dessous d'une règle complexe impliquant des applications définies.
  • Cela se produit car le proxy TCP est appliqué, ce qui fait que la poignée de main TCP passe par le Cato Cloud tandis que le paquet de données traverse l'Alt. WAN, conduisant à une réinitialisation de la connexion. 
  • La solution consiste à déplacer la règle simple Off-Cloud 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 obtenir des détails sur ce problème, consultez Échec de connexion TLS sur Off-Cloud ou Liens Alt-WAN 

Solution à l'échec de BGP pour établir la connexion

  • 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'IP WAN alternative du voisin BGP :

      voisin <IP WAN alternative du Socket> next-hop-self

    2. Appliquez une carte de route pour définir explicitement le prochain saut à l'IP de l'interface WAN alternative du routeur :

      carte-de-route <nom-de-la-carte> permettre 10
          définir ip next-hop <IP de l'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 l'Alt. Un tunnel WAN avec des sites distants. 

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0

0 commentaire