Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment dépanner les pertes de paquets d'interface sur les routeurs Cisco IOS® XE.
Connaissances de base sur le flux de paquets et Cisco IOS XE.
Ce document est basé sur les plates-formes de routeurs Cisco IOS XE telles que les routeurs ISR 4000 et ASR1000.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Sur les routeurs Cisco IOS XE, les abandons de paquets peuvent se produire sur différents composants, notamment :
Interfaces SPA (Shared Port Adapter).
Processeur de flux quantique (QFP) : Processeur de plan de données qui contient les PPE (moteurs de processeur de paquets).
Ces pertes peuvent être observées dans le sens d'entrée ou de sortie sur les interfaces. Lors de l'analyse du QFP, l'accent est mis sur les pertes de sortie.
Pour les abandons de paquets affectant le plan de contrôle sur les périphériques Cisco IOS XE, reportez-vous aux abandons ponctuels comme indiqué dans le guide : Dépanner un contrôleur qui a dépassé un seuil.
Les interfaces peuvent subir des pertes d'entrée dans les files d'attente d'entrée. Ce compteur peut être vu avec la commande show interfaces dans le champ de file d'attente d'entrée, abandonne la section du compteur :
---- show interfaces ----
GigabitEthernet0/0/0 is up, line protocol is up
Input queue: 0/375/71966/0 (size/max/drops/flushes); Total output drops: 47009277
Le compteur d'abandon d'entrée sur les interfaces est également visible dans la commande show interface summary, sous la colonne IQD , qui représente les paquets abandonnés de la file d'attente d'entrée.
---- show interface summary ----
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
-----------------------------------------------------------------------------------------------------------------
* Te0/0/0 0 0 0 0 29544000 2830 1957000 1446 0
* Te0/0/1 0 0 0 0 23476000 2555 16655000 3346 0
* GigabitEthernet0/0/0 0 71966 0 47019440 18852000 5321 59947000 6064 0
Les pertes d'entrée sur les interfaces se produisent généralement lorsque les files d'attente d'entrée sont saturées et ne peuvent pas être traitées à temps. Par conséquent, les paquets peuvent être éliminés sélectivement en fonction de l'algorithme de mise en file d'attente utilisé.
Causes possibles des pertes d'entrée :
Vous pouvez essayer d'augmenter la taille de la file d'attente d'entrée en utilisant la commande hold-queue sous le niveau d'interface :
Router(config-if)#hold-queue ?
<0-240000> Queue length
Remarque : La commande Hold-queue ne peut pas être efficace sur certaines plates-formes. Vérifiez les spécifications de la plate-forme ou soumettez un dossier au TAC.
Remarque : les mécanismes de contrôle de flux peuvent également être utilisés pour envoyer des trames de pause du périphérique récepteur vers le périphérique émetteur. Pour plus d'informations sur le contrôle de flux, reportez-vous au Guide de configuration des composants matériels et d'interface de la plate-forme concernée.
Les abandons de sortie sur les interfaces se manifestent dans les files d'attente de sortie et peuvent être vus avec la commande show interfaces :
---- show int gi 1/0/46 ----
GigabitEthernet1/0/46 is up, line protocol is up (connected)
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 154786
Le compteur Total des abandons en sortie indique la saturation dans les files d'attente de sortie de l'interface affectée. Cette condition peut être exacerbée par des mécanismes tels que la qualité de service (QoS), qui peut rejeter sélectivement des paquets pour gérer l'encombrement.
Comme la QoS modifie la priorité du trafic, une autre étape de dépannage consiste à vérifier si l'interface utilise une stratégie de mise en file d'attente autre que celle par défaut via une carte de stratégie configurée dans la direction de sortie à l'aide de la commande service-policy output.
interface GigabitEthernet0/1
service-policy output PRIORITIZE-VOICE
Pour vérifier si les pertes de sortie sont dues au mécanisme de qualité de service implémenté, utilisez la commande show policy-map interface <interface-name> out. Ceci est montré dans cet exemple :
---- show policy-map interface gi0/0/0 output ----
GigabitEthernet0/0/0
Service-policy output: PRIORITIZE-VOICE
queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: VOICE (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: Strict, b/w exceed drops: 0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
queue limit 4166 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Router#
Cette commande affiche les abandons dus au mécanisme de qualité de service parmi les classes configurées.
Remarque : Si les pertes de sortie sur l'interface sont corrélées avec les pertes vues dans la carte de stratégie, la perte est généralement attendue en raison de la qualité de service configurée. Contactez le TAC si nécessaire pour approfondir le mécanisme de qualité de service utilisé et reportez-vous aux guides correspondants pour cette fonctionnalité.
Pour plus d'informations sur le fonctionnement de la QoS et sur la façon de la mettre en oeuvre, reportez-vous au Guide de configuration de la qualité de service, Cisco IOS XE 17.x configuration guide.
Pour afficher la stratégie de mise en file d'attente, utilisez la commande show interfaces et vérifiez la valeur de la stratégie de mise en file d'attente. Par défaut, la stratégie de traitement des paquets sortants est FIFO (premier entré, premier sorti).
---- show interfaces gigabitEthernet 0/0/0 ----
Queueing strategy: Class-based queueing
Si l'interface n'a pas de policy-map associée dans la direction de sortie pour la qualité de service, d'autres causes peuvent causer les pertes de sortie.
Voici quelques-unes des raisons des pertes de sortie sur une interface qui n'a pas de qualité de service :
Référez-vous à la section Abandons du processeur de flux quantique (QFP) de ce document pour dépanner davantage cette condition.
Pour vérifier les raisons des abandons QFP, utilisez la commande show platform hardware qfp active statistics drop comme démontré ici :
---- show platform hardware qfp active statistics drop ----
Last clearing of QFP drops statistics : never
-------------------------------------------------------------------------
Global Drop Stats Packets Octets
-------------------------------------------------------------------------
BFDoffload 23944858 1904416850
IpTtlExceeded 184211 28644972
IpsecIkeIndicate 175 26744
IpsecInput 686112 171458640
IpsecInvalidSa 1 80
Ipv4Martian 4 392
Ipv4NoAdj 19776 6587643
Ipv4NoRoute 75 10950
Ipv6NoRoute 27068 1515808
ReassDrop 3489529 450382594
ReassNoFragInfo 4561070 6387610348
ReassOverlap 3 198
ReassTimeout 7408271 2631950860
TailDrop 193769387 157113756882
Cette commande montre différentes raisons pour les abandons QFP et les compteurs de paquets associés pour chaque catégorie.
Remarque : La plupart des raisons de la catégorie d'abandon QFP sont explicites par son nom. La catégorie de raison guide le flux de dépannage. Pour les catégories de suppression de paquets non courantes, si nécessaire, soumettez un dossier Cisco TAC.
L'un des types de perte les plus fréquemment observés est le compteur TailDrop, qui augmente généralement pour les raisons suivantes :
Type de journal généré :
%BW_LICENSE-4-THROUGHPUT_MAX_LEVEL : F0/0 : cpp_ha_top_level_server : Le débit moyen approchait la bande passante sous licence de <mbps> Mbps au cours des périodes d'échantillonnage <sampling-number> au cours des dernières <period> heures, la période d'échantillonnage est de <sampling-period> secondes
Commandes de vérification :
Surutilisation (limitation de la plate-forme)
Pour savoir si le trafic affecté est abandonné et pour obtenir une vue plus détaillée de la gestion des paquets par le QFP , vous pouvez utiliser la fonction de suivi des paquets. Référez-vous à Dépannage avec la fonctionnalité de suivi des paquets de chemin de données de Cisco IOS-XE.
Type de journal généré :
%IOSXE_QFP-2-LOAD_EXCEED : Emplacement : 0, QFP : 0, Load <load-pourcentage>% dépasse le seuil défini.
Remarque : Reportez-vous aux numéros de débit de limitation de plate-forme et à l'évolutivité dans les fiches techniques. Le débit varie en fonction du nombre et de l'utilisation des fonctionnalités dans la configuration du périphérique. Elle varie également en fonction des bits par seconde agrégés (bits/s) injectés dans le QFP.
Vous pouvez utiliser la commande show platform hardware qfp active datapath usage summary et vérifier l'utilisation du QFP au cours des 5 dernières secondes, 1 minute, 5 minutes ou 60 minutes.
---- show platform hardware qfp active datapath utilization summary ----
CPP 0: 5 secs 1 min 5 min 60 min
Input: Total (pps) 1 2 2 2
(bps) 320 1032 1032 1032
Output: Total (pps) 0 1 1 1
(bps) 0 8560 8560 8576
Processing: Load (pct) 0 0 0 0
Crypto/IO
Crypto: Load (pct) 0 0 0 0
RX: Load (pct) 0 0 0 0
TX: Load (pct) 2 2 2 2
Idle (pct) 97 97 97 97
Pour une vérification supplémentaire des abandons dans QFP, utilisez show drops { bqs | crypto| firewall| interface| ip-all| nat| punt| qfp| qos|history}, reportez-vous au guide Cisco Catalyst 8500 and 8500L Series Edge Platforms Software Configuration Guide.
Différents compteurs sont affichés via la commande show interfaces [interface]. L'explication sur la signification sur chacun de ces compteurs peut être trouvée à la section Troubleshooting Ethernet document.
Vous pouvez activer la vue graphique des bits d’historique par seconde dans l’interface de ligne de commande (CLI) dans la direction entrante et sortante à partir d’une interface à l’aide de la commande history bps sous interface level. Cette configuration génère un graphique des bits/s historiques sur l’interface.
Router(config)#interface gigabitEthernet 0/0/0
Router(config-if)#history bps
Vous pouvez également activer history bps output-drops et d'autres historiques de compteurs.
Pour afficher les résultats du compteur d’historique dans le temps, utilisez la commande show interfaces <interface> history :
---- show interfaces gigabitEthernet 0/0/0 history ? ----
60min Display 60 minute histograms only
60sec Display 60 second histograms only
72hour Display 72 hour histograms only
all Display all three histogram intervals
both Display both input and output histograms
input Display input histograms only
output Display output histograms only
| Output modifiers
#show int gi1 history 60sec
90100 *
82100 *
74100 ******
66100 ***********
58100 ***********
50100 ****************
42100 *********************
34100 *******************************
26100 ************************************
18100 ***************************************************
10100 **********************************************************
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
GigabitEthernet1 output rate(mbits/sec) (last 60 seconds)
Ces commandes sont utilisées pour effacer diverses statistiques de compteur :
Pour vérifier si le nombre de pertes en sortie a un impact , outre l'utilisation de la commande history bps output-drops au niveau de l'interface pour comprendre les pertes dans le temps, vous pouvez utiliser d'autres valeurs de compteur pour obtenir le pourcentage global de pertes en sortie depuis la dernière effacement des compteurs.
Si les compteurs n'ont pas été effacés depuis le dernier démarrage, utilisez la commande show version pour obtenir le temps de disponibilité du système ou référez-vous à la dernière effacement de la valeur show interface counters avec la commande show interfaces.
Après avoir déterminé la dernière fois que les compteurs ont été effacés ou identifié le temps de disponibilité du périphérique, calculez le pourcentage de pertes en sortie qui se sont produites au cours de cette période.
Pour ce faire, il suffit de multiplier la valeur totale des abandons de sortie par 100, puis de diviser le résultat entre la valeur du compteur de sortie des paquets de la commande show interfaces <interface>. Le résultat de cette opération donne une idée du % de pertes en sortie pour cette interface pendant cette période.
Remarque : N'oubliez pas que les compteurs de show interfaces et de show platform qfp active statistics drop sont historiques et cumulatifs depuis la dernière fois qu'ils ont été effacés. Les compteurs sont effacés si un rechargement est effectué.
Référez-vous à cet exemple de sortie :
---- show version ----
Hostname uptime is 51 weeks, 1 day, 14 hours, 17 minutes
---- show interface GigabitEthernet0/0/1 ----
GigabitEthernet0/0/1 is up, line protocol is up
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 1351
219128599 packets output, 84085726336 bytes, 0 underruns
L'exemple de sortie indique que les compteurs des interfaces n'ont jamais été effacés, ce qui signifie que pour les 51 dernières semaines de disponibilité du périphérique, le pourcentage de pertes totales en sortie est ( 1351 x 100 ) / 219128599 = 0,0006 %.
L'interprétation de ce pourcentage peut être que le total des pertes en sortie sur cette interface n'est pas significatif et puisque ce compteur est historique, cumulatif, et compte tenu du temps de disponibilité prolongé, cela signifie que les pertes sont sans impact.
Intervalle de charge est un paramètre de configuration de niveau interface qui indique la durée pendant laquelle les données sont utilisées pour calculer les statistiques de charge.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface gigabitEthernet 0/0/0
Router(config-if)#load-interval ?
<30-600> Load interval delay in seconds
Le résultat du paramètre load-interval est reflété avec la commande show interfaces sous les valeurs de débit d'entrée et de sortie :
---- show interfaces gigabitEthernet 0/0/0 ----
GigabitEthernet0/0/0 is administratively down, line protocol is down
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
Ceci est important au moment de vérifier le débit de bits par seconde lors de l'exécution de la commande show interfaces.
Les valeurs des débits d’entrée et de sortie sont utiles pour comprendre les bits par seconde entrants et sortants d’une interface.
Utilisez la commande show interface summary pour une vue d'ensemble générale des valeurs de débit d'entrée et de sortie sur toutes les interfaces et obtenez le débit de sortie agrégé à partir des interfaces physiques, ce qui est utile pour comprendre le nombre total de bits agrégés par seconde en sortie à un certain moment. Référez-vous aux compteurs RXBS et TXBS de cet exemple de sortie :
---- show interfaces summary ----
*: interface is up
IHQ: pkts in input hold queue IQD: pkts dropped from input queue
OHQ: pkts in output hold queue OQD: pkts dropped from output queue
RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
TRTL: throttle count
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
-----------------------------------------------------------------------------------------------------------------
* GigabitEthernet0/0/0 1 0 0 0 9000 19 0 0 0
GigabitEthernet0/0/1 0 0 0 0 0 0 0 0 0
GigabitEthernet0/0/2 0 0 0 0 0 0 0 0 0
* GigabitEthernet0/0/3 0 0 0 0 9000 19 0 0 0
Pour résoudre le problème, supprimez temporairement la stratégie QoS de l'interface concernée. Utilisez la commande no service-policy output <policy-name> au niveau de la configuration d’interface.
Remarque : Si une assistance du TAC est requise, il est important de déterminer si les pertes sont dues à la qualité du service ou non pour acheminer le cas vers l'expert approprié dès les premiers stades.
Remarque : Les pertes peuvent également être dues à la fonctionnalité ipsec. Les abandons IPSec sont généralement agrégés dans une interface physique qui est utilisée comme source de tunnel. Si les gouttes ne sont présentes que lorsque le tunnel est utilisé, il est important d'indiquer au TAC si une assistance est requise. Cela permet d'acheminer le dossier vers l'équipe correspondante dès les premières étapes
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
08-Aug-2025
|
Première publication |