Comment résoudre SD-WAN les problèmes de latence, de gigue et de perte de paquets
39414
Created On 01/20/23 00:01 AM - Last Modified 12/10/25 01:04 AM
Objective
La PAN-OS firewall SD-WAN fonctionnalité surveille SD-WAN les interfaces virtuelles (qui contiennent à la fois des interfaces physiques ISP et/ou VPN des interfaces de tunnel) à l’aide de SD-WAN sondes. Si ces sondes connaissent une quantité de latence (ms), de gigue (ms) ou de perte de paquets (%) supérieure aux seuils configurés dans le profil de qualité du chemin, cette ou ces mesures seront marquées comme non intègres et, par conséquent, le trafic pourrait être modifié vers un chemin différent.
Ce document vous décrit les étapes de dépannage réseau pour affiner, vérifier et résoudre la cause première de cette latence, gigue ou perte de paquets détectée dans votre réseau sur la ou les liaisons affectées.
Conseil : La SD-WAN fonctionnalité mesure la latence, la gigue et la perte de paquets de la liaison en mesurant les ICMP paquets de sonde, et non la latence, la gigue ou la perte de paquets de paquets de trafic
réels.firewall Au lieu de cela, le vérifie si les paquets de sonde subissent une latence, une gigue ou une perte de SD-WAN paquets sur cette liaison (ce que le firewall trafic réel va également). Ensuite, il suffit de firewall vérifier si ces valeurs sont supérieures ou inférieures à vos seuils configurés dans le profil de qualité du chemin pour cette application ou non.
Environment
- PAN-OS
- SD-WAN
Procedure
- Recherchez quel SD-WAN lien rencontre une latence, une gigue ou une perte de paquets et identifiez quelle application traversant ce lien dépasse le(s) seuil(s) de profil de qualité de chemin configuré(s) en raison de l’utilisation de Web UI et CLI
Lors du déploiement SD-WAN Policy des règles, les utilisateurs doivent configurer les profils de qualité de chemin.C’est ici que l’utilisateur définit ses seuils préférés pour la latence, la gigue et la perte de paquets :
Panorama > Objets > Profil de qualité de la gestion des liens > SD-WAN du chemin
Le firewall mesure les sondes pour la latence, la gigue ou la SD-WAN perte de paquets. Si ces paquets de sonde rencontrent des valeurs de latence, de gigue ou de perte de paquets supérieures aux seuils configurés dans le profil de qualité du chemin d’accès pour cette application dans la SD-WAN Policy règle que le trafic frappe, cette application sera marquée comme non intègre. Pour afficher l'état de ces applications et déterminer si elles atteignent ou dépassent vos seuils configurés, utilisez les méthodes ci-dessous :
Panorama SD-WAN > > surveillance
CLI Commandes
> show sdwan path-monitor stats vif sdwan.1
===slot1 dp0 health_ver:(High sensitive) 15 (Medium sensitive) 11 (Low sensitive) 2 ===
----------------------------------------------------------------
ethernet1/1 idx: 16 Probing: Enabled Monitor-mode: Aggressive
----------------------------------------------------------------
probe-req-send:30920 State: up
probe-reply-recv:30919
packet loss : real-time crt-use change
per 1000 pkt: 0 0 0
latency jitter pkt_loss health_ver
3000ms average
real time: 16 1 0
current use: 0 0 0 2
10000ms average
real time: 16 1 0
current use: 0 1 0 8
25000ms average
real time: 16 1 0
current use: 0 0 0 2
- Identifier le chemin (et ISP) emprunté par le trafic subissant la latence, la gigue ou la perte de paquets pour atteindre sa destination
Accédez à Surveiller les journaux de trafic > et utilisez des filtres pour déterminer l'adresse source IP , l'adresse de destination et l'interface de sortie du trafic de cette application sur ce chemin, et vérifier le chemin et le lien qu'elle emprunte pour atteindre sa destination IP .
- Appelez votre ISP et demandez-leur de résoudre la latence, la gigue ou la perte de paquets
S’il n’y a pas d’autres périphériques que le ISP entre la branche et Hub firewall, veuillez poursuivre ce problème de latence, de gigue ou de perte de paquets avec votre ISP. Remarque : Si les revendications ne contiennent pas de latence, de gigue ou de perte de paquets sur le chemin, demandez-leur de fournir des preuves documentées, d'autant plus que les ISP firewallsondes de SD-WAN ICMP (qui traversent ce ISP/VPN tunnel) subissent une latence, une gigue ou une perte de paquets).
S’il y a d’autres périphériques (routeurs, commutateurs, etc.) dans le chemin de ces SD-WAN sondes en dehors du ISP, procédez comme suit.
S’il y a d’autres périphériques (routeurs, commutateurs, etc.) dans le chemin de ces SD-WAN sondes en dehors du ISP, procédez comme suit.
- Identifiez quel périphérique ou interface (ou si le ) dans le ISPchemin du trafic est à l’origine de la latence
- Passez en revue tous les outils de surveillance du trafic ou du réseau tiers pour identifier le point auquel la latence se produit sur le chemin de ce flux de trafic
- Identifiez s’il y a eu des changements de configuration ou de nouveaux périphériques introduits dans votre réseau sur le chemin de ce trafic qui peuvent avoir causé cette latence, gigue ou perte de paquets
- Connectez-vous et vérifiez les périphériques dans le chemin du trafic pour voir s’ils montrent des signes de problèmes de traitement du trafic. Commencez par tout appareil que vous soupçonnez d’être le plus susceptible de provoquer ce type de lenteur ou tout nouvel appareil introduit puisque le trafic fonctionnait comme prévu. Conseil : Utilisez les outils de diagnostic du trafic intégrés de ce fournisseur (trace des paquets, capture de paquets, journaux de performances, journaux de trafic, etc.) pour diagnostiquer pourquoi ce flux de trafic (par source IP et destination IP) traverse lentement ce périphérique.
- Prenez des captures de paquets à différents points du réseau le long du chemin de ce flux de trafic. Comparez côte à côte les horodatages des captures de paquets à différents points du réseau pour identifier à quel point de capture (c’est-à-dire le périphérique) le paquet prend plus de temps à arriver ou à entrer/sortir. Le faire jusqu’à ce que vous puissiez vous limiter à un seul périphérique ou lien du réseau directement à l’origine de la latence vous permettra ensuite de dépanner, de résoudre ou d’apporter les modifications de configuration nécessaires sur cet appareil.
- Vérifiez auprès du ISP et demandez-leur de fournir une preuve qu’il n’y a pas de latence, de perte de paquets ou de gigue sur le chemin emprunté par le trafic
- Identifiez et réduisez ou éliminez toute charge lourde, utilisation ou congestion sur tout périphérique ou lien dans le chemin
Vérifiez les statistiques/l’intégrité de chaque lien et périphérique sur le chemin du trafic pour tout problème, erreur, inondation ou traitement des paquets. Ces types de symptômes peuvent entraîner des paquets à prendre plus de temps que la normale pour entrer/sortir d'un périphérique, ce qui à son tour amènera les utilisateurs finaux à signaler une lenteur dans les fonctionnalités de l'application.
Les coupables les plus courants sont les suivants :
Les coupables les plus courants sont les suivants :
- Tout appareil soumis à une attaque DDoS/inondation de trafic de quelque nature que ce soit
- Tout appareil qui redirige ou transmet par proxy le flux de trafic
- Tout appareil qui inspecte fortement (dispositifs de décryptage) qui traite inutilement
- Tout appareil rencontrant des problèmes de ressources élevés tels que , mémoire CPU, tampons, etc.
- Configurer la QoS sur n'importe quel périphérique (s) nécessaire(s) pour hiérarchiser les paquets de ce trafic le long du chemin de trafic
Configurez QoS sur tous les périphériques appropriés sur le chemin de ce flux de trafic. Par conséquent, ce flux de trafic spécifique sera prioritaire par rapport aux autres trafics et sera traité par les appareils de ce chemin le plus rapidement possible. Consultez la documentation du fournisseur de l'appareil respectif pour savoir comment configurer la QoS sur son appareil.
- Optimiser le routage et le chemin
Assurez-vous que le trafic emprunte les itinéraires et les liens les plus courts, les plus directs et les plus rapides pour atteindre sa destination. Vérifiez que le trafic n’est pas inutilement redirigé ou transmis par proxy par un ou plusieurs dispositifs de sécurité le long du chemin. Arrêtez temporairement la redirection ou le proxy pour déterminer si tel est le problème. Si le trafic est involontairement redirigé ou transmis par proxy, reconfigurez le périphérique effectuant la redirection ou le proxy pour ne pas le faire sur ce flux de trafic. Ensuite, vérifiez si le problème est résolu ou si les performances du trafic (latence, gigue ou perte de paquets) sont améliorées.
Les coupables communs de ceci comprennent:
Les coupables communs de ceci comprennent:
- Pare-feu effectuant des inspections intensives
- Dispositifs de décryptage
- Périphériques proxy
- Routage de tunnel inutile / sous-optimal VPN
- (Facultatif) Réduisez les paramètres de l’application ou utilisez un protocole / une technologie plus léger et plus rapide pour transmettre ce trafic
Exemples :
- Limitation de la qualité vidéo (de 4k à 1080p)
- Codec de qualité audio limité (de G.722 à G.711 ou G.729)
- Évaluez s’il existe une version ou une implémentation plus légère du protocole / de l’application que vous utilisez qui a des besoins en bande passante plus faibles si nécessaire
- Créer un profil de qualité de chemin avec des exigences moins strictes en matière de perte de paquets, de latence ou de gigue
Si vous ou votre ISP ne parvenez pas à faire en sorte que l’application/le chemin d’accès atteigne les niveaux seuils que vous avez spécifiés dans son profil de qualité de chemin actuel, vous devrez peut-être modifier les seuils de perte de paquets, de latence ou de gigue dans le profil de qualité du chemin à un niveau inférieur