Comment résoudre les problèmes de latence d’Sensor
Articles techniques ID:
KB70861
Date de la dernière modification : 25/02/2021
Date de la dernière modification : 25/02/2021
Environnement
McAfee Network Security Sensor Appliance
Synthèse
Avant de commencer :
- Lisez la page Guide de l’interface de commande NSP Sensor pour votre version du logiciel. Voir
docs.mcafee.com pour ce guide. - Déterminez les réponses aux questions suivantes :
- Quand la latence a-t-elle été remarquée pour la première fois et que des événements inhabituels ont été détectés sur votre réseau ?
Pour déterminer si des problèmes se sont produits en même temps que la latence, passez en revue les journaux de votre pare-feu, de votre routeur et de votre commutateur. Résoudre ces problèmes. Ensuite, surveillez votre Sensor et vérifiez que la latence est résolue.
- Avez-vous modifié la configuration de votre réseau ou de votre Sensor juste avant ou pendant la période de latence ?
Si vous annulez ces modifications, le problème est-il résolu ?
- Déterminez le Sensor logiciel en cours d’exécution sur le Sensor. S’agit-il de la dernière version ? Pour obtenir des informations sur la version, consultez : KB55448-informations sur la version actuelle de Network Security Platform
Si le logiciel Sensor n’est pas la version la plus récente, mettez-le à niveau pour voir si le problème est résolu.
- Quelle quantité de trafic réseau est l’analyse de Sensor, et est-elle en charge de la Sensor ?
Veuillez Un problème de latence est souvent lié à des problèmes de paquets perdus. Souvent, lorsque la latence est observée sur un Sensor, des paquets supprimés se produisent également.
- Quand la latence a-t-elle été remarquée pour la première fois et que des événements inhabituels ont été détectés sur votre réseau ?
- Ouvrez une session de ligne de commande pour l’Sensor via HyperTerminal, PuTTy ou un autre application.
Veuillez: Démarrez la journalisation des sessions dans la application de connexion. Si le problème est encore présent lorsque votre session est terminée, enregistrez les journaux. Pour plus d’informations sur la procédure d’enregistrement des journaux, consultez la documentation de votre produit.
- Si le Sensor est en cours d’exécution de la version du logiciel 8.3 ou version ultérieure, collectez la sortie de la commande Afficher le statut de la fonctionnalité.
Pour plus d’informations, reportez-vous au Guide de la CLI Sensor pour votre version logicielle.
- Commencez le débogage de latence en isolant la paire de ports qui affiche la latence. Saisissez les commandes suivantes, soit Sensor-large, soit sur l’interface cible, puis appuyez sur ENTREE après chacune d’elles :
show intfport
Par exemple,show intfport 1A/1B/etc . Pour plus d’informations sur lashow inftport commande, voir : KB54660-Sensor commande : afficher inftport
show inlinepktdropstats
Par exemple,show inlinepktdropstats 1A/1B/etc . Pour plus d’informations sur lashow inlinepktdropstats commande, voir : KB69806-Sensor résolution des problèmes : Show inlinepktdropstats Command
Exemple de sortie ci-dessous :
intruShell@IPS-5200> show inlinepktdropstats g1/1
IP Checksum Error Drop Count : 0
TCP Checksum Error Drop Count : 0
UDP Checksum Error Drop Count : 0
ICMP Checksum Error Drop Count : 0
ICMPv6 Checksum Error Drop Count : 0
ACL Drop Count : 0
Out-Of-Context/Bad Packet Drop Count : 0
Cold Start Drop Count : 0
Off/HdrLen Error Drop Count : 0
Attack Packet Drop Count : 0
IP Reassembly Timeout Drop Count : 0
IPv6 Reassembly Timeout Drop Count : 0
TCP Out-Of-Order Timeout Drop Count : 0
TCP Protocol Error Drop Count : 0
UDP Protocol Error Drop Count : 0
ICMP Protocol Error Drop Count : 0
ICMPv6 Protocol Error Drop Count : 0
IP Protocol Error Drop Count : 0
IPv6 Protocol Error Drop Count : 0
System Out-of-Resource Drop Count : 0
Host Quarantine IPv4 Packet Drop Count : 0
Host Quarantine IPv6 Packet Drop Count : 0
Conn Limiting/L7ddos Packet Drop Count : 0
DoS Attack Packets Dropped : 0
Stateless ACL Drop Count : 0
Total CRC Error Packets Dropped : 0
Total Other Layer-2 Error Packets Dropped: 0
Total IP Spoofed Packets dropped : 0
Total IP No Credit Packets dropped : 0
- Affichez la sortie des commandes à l’étape précédente.
- Si vous voyez des erreurs CRC ou autres, procédez comme suit :
- Assurez-vous que les paramètres vitesse/duplex sont configurés de la même manière sur les équipements Sensor et homologue.
FAUT Ne configurez pas manuellement un équipement et définissez l’autre sur négociation automatique. ils doivent être configurés de la même manière.
- Modifiez les câbles de connexion pour vous assurer que le problème n’est pas dû à un mauvais câble. Utilisez des câbles corrects connus lorsque cela est possible.
- Assurez-vous que les paramètres vitesse/duplex sont configurés de la même manière sur les équipements Sensor et homologue.
- Si vous voyez un nombre positif de paquets de quarantaine de l’hôte :
Vérifiez les adresses IP mises en quarantaine dans Manager et vérifiez si le trafic concerné est l’un des hôtes mis en quarantaine.
- Si vous voyez un haut
Conn RéduisL7ddos Valeur de rejet du paquet :
Vérifiez les stratégies de limitation de connexion et le déni de service WebServer dans les stratégies options d’inspection.
- Si vous voyez qu’un nombre élevé de paquets d’attaque de déni de service a été supprimé :
Vérifiez les journaux d’attaque pour voir si des attaques liées à DoS sont déclenchées.
- Si vous voyez un nombre de suppressions d’ACL sans État :
Vérifiez les stratégies de pare-feu pour les règles ACL selon les cas
- Si vous voyez des erreurs CRC ou autres, procédez comme suit :
- Mettez le Sensor en mode layer2. Saisissez la commande suivante et appuyez sur ENTREE :
layer2 mode assert
- Reproduire le problème :
- Si vous mettez le Sensor en mode Layer2 et qu’il ne résout pas votre problème :
Le logiciel Sensor n’est pas à l’origine de la latence. Lorsque vous mettez le Sensor en mode Layer2, le Sensor agit comme un concentrateur et est invisible pour le réseau. Etant donné que le logiciel Sensor est éliminé comme cause, le problème est lié au matériel Sensor ou à un autre emplacement. (Sensor matériel peut inclure des interfaces, des câbles ou des kits de prévention de défaillance.)
Essayez d’utiliser d’autres interfaces, câbles ou kits de prévention de défaillance connus, ou contournez physiquement le Sensor. Si ces actions ne résolvent pas le problème, McAfee vous recommande d’utiliser un analyseur de réseau pour inspecter le trafic réseau et résoudre le problème.
- Si le problème est résolu :
- Mettez le Sensor en mode Layer2 :
Saisissezlayer2 mode deassert et appuyez sur entrée.
- Assurez-vous que le Sensor est hors Layer2 :
Saisissez État et appuyez sur entrée.
L’état correct est le suivant :
Layer 2 Status : normal (IDS/IPS/NAC).
- Poursuivez la procédure de dépannage.
- Mettez le Sensor en mode Layer2 :
- Si vous mettez le Sensor en mode Layer2 et qu’il ne résout pas votre problème :
- Définissez le Sensor pour équilibrer la charge du trafic avant qu’il ne soit envoyé au processeur frontal :
- Type
loadbalance pre-fe et appuyez sur entrée. - Assurez-vous que le Sensor est équilibré en charge
pre-fe :
Typeloadbalance status et appuyez sur entrée.
L’état correct est le suivant :
Primary : Pre-FE
- Type
- Configurez le Sensor pour équilibrer la charge du trafic sur la charge du processeur front-end :
- Saisissez
loadbalance post-fe et appuyez sur entrée. - Assurez-vous que le Sensor est équilibré en charge
post-fe :
Saisissezloadbalance status et appuyez sur entrée.
L’état correct est le suivant :
Primary : Post-FE
- Saisissez
- Définissez Sensor équilibrage de charge sur le mode normal pour un dépannage supplémentaire :
- Saisissez
loadbalance normal et appuyez sur entrée. - Assurez-vous que Sensor équilibrage de charge est défini sur normal :
Saisissezloadbalance status et appuyez sur entrée.
L’état correct est le suivant :
Primary : (null)
- Saisissez
- Désactivez le traitement des paquets Layer3 sur le Sensor à l’aide du mode de débogage Sensor :
- Saisissez la commande suivante et appuyez sur ENTREE :
debug
- Saisissez la commande suivante et appuyez sur ENTREE :
set l3 off
- Saisissez la commande suivante et appuyez sur ENTREE :
- Reproduisez le problème et examinez le résultat :
Si la désactivation de l’option désactiver Layer3 résout votre problème, elle est liée au traitement des paquets Layer3 sur le Sensor. Notez ce détail et incluez-le lorsque vous ouvrez une demande de service.
- Réactivez le traitement des paquets Layer3 et poursuivre le dépannage. Saisissez la commande suivante et appuyez sur ENTREE :
set l3 on - Vérifiez si la fragmentation IP (fonctionnalité Layer3) est à l’origine du problème en le désactivant :
- Saisissez
debug et appuyez sur entrée. - Saisissez
set ipfrag off et appuyez sur entrée.- Si la désactivation de la fragmentation IP résout votre problème, vérifiez que votre réseau comporte des paquets fragmentés.
- Si aucune modification n’est apportée, activez à nouveau la fragmentation IP et poursuivez le dépannage :
Saisissezset ipfrag on et appuyez sur entrée.
- Saisissez
- Désactiver Traitement des paquets Layer7 et détection d’attaques dans la Sensor :
- Saisissez la commande suivante et appuyez sur ENTREE :
set l7 off - Tester si la latence et d’autres problèmes sont résolus ou si leur impact est réduit :
- Si la latence/les problèmes sont réduits ou résolus, un paquet Layer7 spécifique au sein du trafic est à l’origine du problème. Si un certain protocole est supposé être à l’origine du problème, utilisez les listes de Contrã’le d’accès pour isoler Sensor latence.
Créez une liste de contrôle d’accès qui supprime le protocole suspect de l’inspection. Lorsqu’une liste de contrôle d’accès est définie pour un protocole spécifique, le Sensor ignore le protocole et le protocole n’est pas inspecté en interne.
Consultez la section Guide de configuration IPS pour obtenir plus d’informations sur la création de listes de contrôle d’accès pour votre version logicielle.
Veuillez Vous devez réactiver Layer7 pour que les listes de Contrã’le d’accès fonctionnent. Saisissez définir L7 lors et appuyez sur entrée.
- Si un certain protocole est à l’origine de la latence, procédez comme suit :
- Notez le protocole et le serveur/hôte d’origine et la destination.
- Dans la mesure du possible, recueillez une capture de ce trafic et incluez ces informations lorsque vous ouvrez votre demande de service.
- Cliquez sur le traitement des paquets Layer7 et la détection des attaques, saisissez la commande suivante et appuyez sur ENTREE :
set l7 on - Passer à la suivante Etape numérotée et poursuivez le dépannage.
- Si la cause de la latence est indéterminée :
- Enregistrez les listes de Contrã’le d’accès que vous avez configurées et les protocoles supprimés.
- Cliquez sur le traitement des paquets Layer7 et la détection des attaques, saisissez la commande suivante et appuyez sur ENTREE :
set l7 on - Passer à la suivante Etape numérotée et poursuivre le dépannage
- Si un certain protocole est à l’origine de la latence, procédez comme suit :
- Si la latence/les problèmes ne sont pas réduits :
Activez le traitement des paquets Layer7 et la détection d’attaques sur et poursuivez le dépannage. Saisissez la commande suivante et appuyez sur ENTREE :
set l7 on
- Si la latence/les problèmes sont réduits ou résolus, un paquet Layer7 spécifique au sein du trafic est à l’origine du problème. Si un certain protocole est supposé être à l’origine du problème, utilisez les listes de Contrã’le d’accès pour isoler Sensor latence.
- Saisissez la commande suivante et appuyez sur ENTREE :
- Collectez la mémoire, Sensor la consommation de charge, le moniteur de latence et les informations sur le niveau de débogage des performances, ainsi que les détails relatifs au trafic TCP, UDP, ICMP et au trafic fragmenté.
Veuillez Avant d’effectuer la procédure ci-dessous, activez les journaux de session dans le package utilisé pour faire fonctionner votre session de ligne de commande (HyperTerminal ou PuTTy).
- Saisissez les commandes suivantes, puis appuyez sur entrée après chacune d’elles pour collecter les informations :
latency-monitor enable action alert-only or latency-monitor enable action layer2-forward
Veuillez Le mode Layer2 doit être activé pour que l’action Layer2-Forward prenne effet. Vous devez exécuter la commande mode Layer2 activé pour activer le mode layer2.latency-monitor status sensor perf-debug
Veuillez Veillez à définir un délai suffisamment long pour effectuer les étapes suivantes. Par exemple, pour activer perf-Debug pendant 15 minutes, procédez comme suit :sensor perf-debug 15 .sensor perf-debug status set sensor-load on - Exécutez les commandes suivantes dans l’ordre indiqué :
FAUT Vous devez exécuter l’ensemble complet au moins trois fois pour collecter suffisamment de données au fil du temps.show sensor-load sensor perf-debug show
Veuillez Vous devez exécuter la commande dans la période que vous avez spécifiée lors de l’exécution de performances du capteur-débogage.sensor-datapath-stat-analysis show datapathstat core all parameter all show tcpipstats show flows show mem-usage show intfport (par exemple,show intfport 1A/1B/etc )show inlinepktdropstats (par exemple,show inlinepktdropstats 1A/1B/etc )show statistics l4 show statistics tcp show statistics udp show statistics icmp show statistics ipfrag
bcmcli "ports"
bcmcli "show counters"
bcmcli "show counters all"
bcmcli "ps"
bcmcli "vlan show"
bcmcli "trunk show"
l7dpstat
show datapath processunits
show all datapath error-counters
show statistics l4
l7show
show attack count
show statistics alerts
rspstat
show fe stat
- Après avoir exécuté les commandes ci-dessus au moins trois fois, exécutez les commandes suivantes une seule fois :
Perf Sensor-chargement de débogage-protoStats
définir le capteur-déchargementsensor perf-debug off
- Saisissez les commandes suivantes, puis appuyez sur entrée après chacune d’elles pour collecter les informations :
- Quittez le mode débogage. Saisissez activé et appuyez sur entrée.
- Collecter les Protocole journaux de session et
tracelogs . Pour plus d’informations sur la collecte d’un diagnostics traçage à partir du Sensor (trace. log), consultez : KB55549-Comment collecter un diagnostics traçage à partir de Network Security Platform Sensor (trace. log)
Fournissez les deux journaux à Support technique lorsque vous ouvrez une demande de service et incluez les détails suivants :- La désactivation du traitement Layer 2, Layer 3 ou Layer 7 a-t-elle un effet ?
- Savez-vous si des protocoles pourraient être responsables de la latence ?
- Quelles applications sont affectées par la latence ?
- Des modifications ont-elles été apportées au réseau affecté, aux applications ou au Sensor, autour du moment où la latence a commencé ?
- Quelle version précédente du logiciel était installée sur le Sensor ?
- Depuis combien de temps la version actuelle du logiciel a-t-elle été installée sans provoquer de latence ?
Pour contacter Support technique, accédez à la page créer une demande de service et connectez-vous au ServicePortal.
- Si vous êtes un utilisateur enregistré, saisissez votre ID d’utilisateur et votre mot de passe, puis cliquez sur connexion.
- Si vous n’êtes pas un utilisateur enregistré, cliquez sur Enregistrer et renseignez les champs pour que votre mot de passe et les instructions vous soient envoyés par e-mail.
Informations connexes
Pour les documents relatifs aux produits, accédez au portail de la documentation produit.
Clause d'exclusion de responsabilité
Le contenu du présent article a été rédigé en anglais. En cas de divergences entre la version anglaise et sa traduction, la version en anglais prévaut. Certaines parties de ce contenu ont été traduites par le moteur de traduction automatique de Microsoft.
Produits affectés
Langues :
Cet article est disponible dans les langues suivantes :
GermanEnglish United States
Spanish Spain
French
Italian
Japanese
Portuguese Brasileiro
Chinese Simplified