Table des matières

Introduction

Exigences

Composants utilisés

Informations générales

Pertes en entrée

Pertes en sortie sur les interfaces

Abandons de sortie sans qualité de service en place

Abandons de QFP (Quantum Flow Processor)

Gouttes De Queue

Conseils supplémentaires pour le dépannage des pertes de paquets

Compteurs sur interfaces

Graphique basé sur l'interface de ligne de commande (CLI) en bits d'historique par seconde

clear counters

Pourcentage de pertes dans le temps

Intervalle de charge

Supprimer temporairement la stratégie QoS

Articles et documentation associés

Introduction

Ce document décrit comment dépanner les pertes de paquets d'interface sur les routeurs Cisco IOS® XE.

Exigences

Connaissances de base sur le flux de paquets et Cisco IOS XE.

Composants utilisés

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.

Informations générales

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.

Pertes en entrée

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 :

- Le périphérique émetteur transmet des paquets à un débit supérieur à celui que le périphérique récepteur peut traiter, ce qui entraîne un épuisement de la file d'attente d'entrée

- Rafales ou microrafales dans les modèles de trafic

- Limites de plate-forme

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.

Pertes en sortie sur les interfaces

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

Abandons de sortie sans qualité de service en place

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 :

- Interfaces entrantes formant des canaux de port et interface de surabonnement à sortie unique

- Rétro-pression QFP (Quantum Flow Processor)

- Limites de débit de licence

- Limites de plate-forme

Référez-vous à la section Abandons du processeur de flux quantique (QFP) de ce document pour dépanner davantage cette condition.

Abandons de QFP (Quantum Flow Processor)

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.

Gouttes De Queue

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 :

- Limitation du débit de licence.

- Abandons QoS

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 :

- show platform hardware qfp active infrastructure bqs queue output default interface <interface>

- show plat hardware qfp active infrastructure bqs queue output default all

- show platform hardware qfp active feature lic-bw oversubscription

- show platform hardware throughput level

- show platform hardware throughput crypto

- 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.

Conseils supplémentaires pour le dépannage des pertes de paquets

Compteurs sur interfaces

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.

Graphique basé sur l'interface de ligne de commande (CLI) en bits d'historique par seconde

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)

clear counters

Ces commandes sont utilisées pour effacer diverses statistiques de compteur :

- clear counters : Efface les données de compteur au niveau de l'interface.

- show platform hardware qfp active statistics drop clear : Réinitialise les compteurs de branchement sur le QFP (Quantum Flow Processor).

Pourcentage de pertes dans le temps

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

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

Supprimer temporairement la stratégie QoS

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.

- Si les abandons persistent sans la stratégie QoS, le problème n'est pas lié à la QoS.

- Si les abandons cessent après la suppression de la stratégie QoS, la stratégie en est la cause probable.

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

Articles et documentation associés

- Dépannage des pertes de paquets sur les routeurs de service de la gamme ASR 1000