Routeurs : Routeurs de la gamme Cisco 10000

Dépannage des suppressions dans la file d'attente d'entrée et de sortie

16 janvier 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (31 décembre 2015) | Commentaires


Interactif : Ce document propose une analyse personnalisée de votre périphérique Cisco.


Contenu


Introduction

Ce document décrit les pertes de la file d'attente d'entrée et de sortie issues de la commande show interfaces sur le routeur. Ce document décrit ce que ces pertes signifient, le type de problèmes qu'elles indiquent, et comment dépanner la source de ces problèmes. Il fournit quelques astuces sur la façon d'empêcher ces problèmes.

Remarque: Les pertes peuvent souvent être utiles, parce qu'elles déclenchent les mécanismes de contrôle de flux de protocoles de couche supérieure (par exemple, les pertes diminuent la taille de la fenêtre TCP).

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Traitement et commutation

Dans les réseaux IP, les routeurs prennent des décisions de transfert basées sur le contenu de la table de routage. Quand un routeur effectue une recherche dans la table de routage, il recherche la plus longue correspondance pour l'adresse IP de destination. Le routeur effectue cette opération au niveau processus. Le processus de recherche est donc mis en file d'attente avec d'autres processus de l'UC ; c'est pourquoi le temps de recherche est imprévisible et peut être très long. Par conséquent, un certain nombre de méthodes de commutation basées sur la précis-correspondance-consultation ont été introduites en logiciel de Cisco IOSÝ.

Le principal avantage de la recherche de correspondances exactes est que le temps de recherche est déterministe et très court. Cela a sensiblement raccourci le temps que le routeur met pour prendre une décision de transfert. Par conséquent, des routines qui exécutent la recherche peuvent être implémentées au niveau de priorité d'interruption. Cela signifie que l'arrivée d'un paquet déclenche une interruption, suite à quoi l'UC diffère d'autres tâches et gère le paquet. La méthode traditionnelle pour transférer des paquets est de rechercher une meilleure correspondance dans la table de routage. Cela ne peut pas être implémenté au niveau de priorité d'interruption et doit être exécuté au niveau processus. Pour un certain nombre de raisons, dont certaines sont mentionnées dans ce document, la méthode de recherche de la correspondance la plus longue ne peut pas être complètement abandonnée ; donc ces deux méthodes de recherche existent en parallèle sur les routeurs Cisco. Cette stratégie a été généralisée, et est maintenant également appliquée à IPX et à AppleTalk.

Pour plus d'informations sur les chemins de commutation du logiciel Cisco IOS, référez-vous à Bases de l'optimisation des performance.

Pertes de la file d'attente d'entrée

Quand un paquet entre dans le routeur, celui-ci essaye de le transférer au niveau de priorité d'interruption. Si une correspondance ne peut pas être trouvée dans un tableau de cache approprié, le paquet est aligné dans la file d'attente de l'interface entrante à traiter. Certains packets sont toujours traités, mais avec la configuration appropriée et dans des réseaux stables, le débit des paquets traités ne doit jamais congestionner la file d'attente d'entrée. Si la file d'attente d'entrée est pleine, le paquet est perdu.

Voici un exemple de sortie :

router#show interfaces ethernet 0/0 
...
Input queue: 30/75/187/0 (size/max/drops/flushes); Total output drops: 0 
Output queue :0/40 (size/max)...

Dans cet exemple de sortie, il n'y a aucune façon de voir exactement quels paquets ont été perdus. Afin de dépanner les pertes de la file d'attente d'entrée, vous devez découvrir quels paquets remplissent la file d'attente d'entrée. En cet exemple, 30 paquets sont dans la file d'attente d'entrée de l'interface Ethernet0/0 quand la commande show interfaces ethernet 0/0 est émise. La profondeur de la file d'attente est de 75 paquets et il y a eu 187 pertes depuis que les compteurs de l'interface ont été effacés pour la dernière fois.

Le système compte les pertes de la file d'attente d'entrée si le nombre de mémoires tampons pour les paquets allouées à l'interface est épuisé ou atteint son seuil maximal. Vous pouvez augmenter la valeur de file d'attente maximale avec la commande hold-queue <value> pour chaque interface (la valeur longueur de la file d'attente peut être comprise entre 0 et 4096. La valeur par défaut est 75).

Remarque: Les routeurs à mémoire partagée (1600, 2500 et 4000) utilisent également la file d'attente d'entrée pour le trafic à commutation rapide. Si vous obtenez des pertes de file d'attente d'entrée sur ces plates-formes, assurez-vous que tout le trafic utilise le meilleur chemin de commutation disponible (voir Bases de l'optimisation des performances). Les pertes de la file d'attente d'entrée se produisent généralement quand un paquet est commuté par processus. Une commutation par processus signifie que le routeur ne peut pas utiliser une méthode de cache de route préférable, comme la commutation rapide ou Cisco Express Forwarding (CEF), pour traiter la décision de transfert. Si des pertes d'entrée sont encore présentes, cela implique qu'il y a simplement trop de trafic. Considérez une mise à niveau matérielle, ou essayez de diminuer la charge de trafic.

Voici les conditions pour le compteur des pertes de la file d'attente d'entrée. Elles se produisent habituellement quand le routeur reçoit du trafic en rafale et ne peut pas traiter tous les paquets.

  • Le FIFO Rx qui est accessible par le PHY de l'interface et le DMA de l'interface est plein et toutes les nouvelles trames qui arrivent dans cette condition seront perdues (normalement appelé débordement) et le compteur rx_overflow (vu via show controller interface-id) sera incrémenté. Quand le compteur rx_overflow est incrémenté de 1, cela indique que la condition de débordement s'est produite une fois et n'indique pas le nombre de trames perdues.

  • L'anneau Rx qui est accessible par le DMA de l'interface et le code du pilote d'interface est plein. Aucun nouveau transfert de trames à partir du DMA ne peut se poursuivre avec cette condition, puisqu'il n'y a aucune entrée de libre dans l'anneau Rx et par conséquent les trames envoyées sont perdues (appelé condition de débordement). Le compteur rx_int_drop (vu via show controller interface-id) est également incrémenté de 1. De nouveau, si rx_int_drop est incrémenté de 1, cela indique qu'il y a une occurrence d'une condition de débordement, et le nombre de trames perdues n'est pas connu.

La taille de la file d'attente de rétention des entrées peut être augmentée au-delà des 75 paquets par défaut. La file d'attente de rétention stocke les paquets reçus du réseau qui attendent d'être envoyés au client. Cisco recommande que la taille de la file d'attente ne dépasse pas dix paquets sur les interfaces asynchrones. Pour la plupart des autres interfaces, la longueur de la file d'attente ne doit pas dépasser 100. La file d'attente de rétention des entrées empêche une unique interface d'inonder le serveur réseau avec trop de paquets en entrée. Les autres paquets en entrée sont ignorés si l'interface a trop de paquets en entrée en attente dans le système.

Router(conf-if)# hold-queue length in

Pour les commutateurs Catalyst, Cisco recommande de faire ce réglage sur toutes les interfaces L3 sur le périphérique, à la fois sur les interfaces physiques et sur les interfaces de VLAN. Les ports L2 configurés avec la commande switchport peuvent être laissés à la valeur par défaut.

Remarque: Après que vous appliquiez cette commande, vous devez effacer les compteurs d'interface et puis surveillez le réseau.

attention Attention : Une augmentation dans la file d'attente de rétention peut avoir des effets néfastes sur le routage réseau et sur les temps de réponse. Pour les protocoles qui emploient des paquets SEQ/ACK pour déterminer les temps d'aller-retour, n'augmentez pas la file d'attente de sortie. La perte de paquets informe à la place les hôtes de ralentir les transmissions pour s'adapter à la bande passante disponible. C'est généralement mieux que des copies en double du même paquet dans le réseau, ce qui peut se produire avec de grandes files d'attente de rétention.

Dépannage des pertes de la file d'attente d'entrée

Vous pouvez avec succès dépanner des pertes de file d'attente d'entrée tandis que des paquets arrivent constamment dans la file d'attente d'entrée. Vous ne pouvez pas dépanner un encombrement qui s'est produit dans le passé. Si plusieurs protocoles routés sont configurés sur l'interface, déterminez d'abord le protocole qui encombre la file d'attente d'entrée. Voici la façon la plus rapide de faire cela :

  1. Déterminez le protocole suspect. Contrôlez l'utilisation de l'UC dans les processus <protocole> Input. Pour ce faire, exécutez la commande show processes cpu exec. Si le logiciel Cisco IOS version 12.1 ou supérieure est exécuté sur le routeur, vous pouvez raccourcir la sortie de la commande show processes CPU via les modificateurs de sortie :

    router#show processes CPU | i ^PID|Input 
     PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
      10        8503      1713   4963   0.00%  0.00%  0.00%   0 ARP Input 
      24       69864     11429   6112   0.08%  0.11%  0.10%   0 Net Input 
      28       55099      8942   6161  26.20% 20.07% 19.26%   0 IP Input 
      37           4         2   2000   0.00%  0.00%  0.00%   0 SSCOP Input 
      40           8         2   4000   0.00%  0.00%  0.00%   0 ILMI Input 
      49           8         1   8000   0.00%  0.00%  0.00%   0 Probe Input 
      50       28209      4637   6083   0.00%  0.03%  0.04%   0 RARP Input 
      59           8         2   4000   0.00%  0.00%  0.00%   0 SPX Input 
      61           8         2   4000   0.00%  0.00%  0.00%   0 Tag Input 
      68       20803      3392   6132   0.00%  0.03%  0.00%   0 IPX Input 
     104           4         1   4000   0.00%  0.00%  0.00%   0 IPXWAN Input 
     107           8         1   8000   0.00%  0.00%  0.00%   0 AT Input

    Le tableau 1 répertorie les processus d'entrée possibles et les types de paquets qui encombrent la file d'attente d'entrée :

    Processus d'entrée qui utilise des cycles processeur Type de paquets
    IP IP
    À AppleTalk
    IPX, SPX ou IPXWAN IPX
    ARP IP ARP

    Les autres processus d'entrée ne sont pas susceptibles d'encombrer la file d'attente d'entrée.

  2. Découvrez si des paquets qui encombrent la file d'attente d'entrée sont destinés au routeur, ou sont transférés via le routeur. Exécutez la commande show interfaces [type number] switching en mode exec.

    Remarque: La commande show interfaces [type number] switching est masquée, et ne s'affiche pas si vous utilisez les touches « ? » ou TAB sur l'interface de ligne de commande. Tapez la commande complète sur le routeur. Cette commande n'est pas documentée dans le Guide de référence des commandes.

    router#show interfaces ethernet 0/0 switching 
    Ethernet0/0 
        ... 
        Protocol          Path    Pkts In   Chars In   Pkts Out  Chars Out 
        ... 
         IP            Process      12142    2211929         35       5169 
                  Cache misses      10212 
        ...
    

    Vérifiez si le nombre de paquets traités reçus est suivi par un nombre élevé de pertes dans le cache. Si oui, cela indique que les paquets, qui encombrent la file d'attente d'entrée, sont transférés par le routeur. Autrement, ces paquets sont destinés au routeur.

  3. Si les paquets sont destinés au routeur, découvrez quel protocole de couche supérieure encombre la file d'attente d'entrée. Pour cela, utilisez l'une des commandes show traffic exec suivantes :

    Remarque: Ces commandes s'appliquent seulement si vous suspectez l'un des processus d'entrée mentionnés dans le tableau 1.

  4. Essayez d'obtenir plus d'informations sur les paquets qui congestionnent la file d'attente d'entrée. Pour cela, vous devez déboguer les paquets reçus. Les étapes précédentes indiquent les commandes de débogage que vous devez activer.

    Remarque: Vous pouvez exécuter cela directement, même si vous n'exécutez pas les étapes précédentes. Cependant, quand vous déboguez, plusieurs messages sont générés, et ils peuvent être difficiles à lire. Quand vous suivez toutes les étapes précédentes, vous obtenez une indication de quoi rechercher dans la sortie de débogage.

    avertissement Avertissement : Faites très attention quand vous déboguez. Autrement, l'utilisation de l'UC peut augmenter considérablement. N'activez pas le débogage pendant plus de 5 à 10 secondes. Pour plus d'informations sur l'utilisation des commandes de débogage, référez-vous à Utilisation des commandes de débogage. Ne désactivez jamais les journaux de console, les journaux de terminaux et les journaux sur un serveur Syslog. Activez les journaux en mémoire tampon, et augmentez la taille de la mémoire tampon de journalisation. Une bonne valeur pour la taille de la mémoire tampon de journalisation est de 128 000 octets. Utilisez les commandes suivantes :

    La sortie doit être suffisante pour localiser la source du problème. Vous pouvez contrôler la sortie de débogage avec la commande show log après avoir terminé la session de débogage. Le tableau 2 répertorie les commandes debug à émettre en fonction du type de paquets qui congestionnent la file d'attente d'entrée :

    Type de paquets qui congestionnent la file d'attente d'entrée Commande de débogage à utiliser
    IP debug ip packet
    AppleTalk debug apple packet
    IPX debug ipx packet
    ARP debug arp

    Pour plus d'informations, référez-vous à Référence des commandes de débogage Cisco IOS.

    Alternativement, vous pouvez utiliser la commande show buffers input-interface [interface type] [interface number] header pour découvrir les types de ces paquets qui remplissent la file d'attente d'entrée.

    Remarque: C'est utile seulement s'il y a beaucoup de paquets dans la file d'attente d'entrée.

    Router#show buffers input-interface serial 0/0      
     Buffer information for Small buffer at 0x612EAF3C 
       data_area 0x7896E84, refcount 1, next 0x0, flags 0x0       
       linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0       
       if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)       
       inputtime 0x0, outputtime 0x0, oqnumber 65535 
       datagramstart 0x7896ED8, datagramsize 728, maximum size 65436 
       mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0       
       network_start 0x7896ED8, transport_start 0x0       
       source: 212.176.72.138, destination: 212.111.64.174, id: 0xAAB8, 
       ttl: 118, prot: 1      
     Buffer information for Small buffer at 0x612EB1D8 
       data_area 0x78A6E64, refcount 1, next 0x0, flags 0x0       
       linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0       
       if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)       
       inputtime 0x0, outputtime 0x0, oqnumber 65535
       datagramstart 0x78A6EB8, datagramsize 728, maximum size 65436
       mac_start 0x78A6EB8, addr_start 0x78A6EB8, info_start 0x0       
       network_start 0x78A6EB8, transport_start 0x0       
       source: 212.176.72.138, destination: 212.111.64.174, id: 0xA5B8, 
       ttl: 118, prot: 1
    

    Le plus souvent, un type de paquet est présent en grande quantité. Ici, par exemple, il y a plusieurs paquets Internet Control Message Protocol (ICMP) (protocole IP 1).

    Si le problème est une configuration du routeur incorrecte (par exemple, la commutation rapide et Cisco Express Forwarding (CEF) sont tous les deux désactivés), il n'y a probablement aucun modèle particulier dans les débogages, ou dans la sortie de la commande show buffers input-interface.

  5. Quand vous avez déterminé le type de paquets qui congestionnent la file d'attente d'entrée, l'étape suivante est de vérifier si vous pouvez empêcher cet encombrement.

    Il y a plusieurs raisons pour lesquelles des paquets doivent être traités :

    • Configuration de routeur incorrecte - Les chemins de commutation qui fonctionnent au niveau de priorité d'interruption sont désactivés sur les interfaces appropriées.

      Pour contrôler quels chemins de commutation sont configurés sur une interface, exécutez la commande show <protocol> interface [type number].

      • Afin d'activer la commutation rapide traditionnelle, configurez-la sur les interfaces de sortie.

      • Afin d'activer la commutation Netflow, configurez-la sur les interfaces d'entrée.

      • Afin d'activer Cisco Express Forwarding (CEF), vous devez s'activer CEF globalement (sur l'ensemble du routeur) et localement (sur l'interface entrante).

        Pour plus d'informations, consultez le Guide de configuration des services de commutation Cisco IOS.

    • Destination locale - Les paquets sont destinés au routeur.

      • Dans les réseaux stables, le nombre de mises à jour du routage ne doit pas être excessif. Dans les réseaux instables, des mises à jour fréquentes de grandes tables de routage peuvent congestionner la file d'attente d'entrée.

      • Vérifiez si un trafic excessif est dirigé vers le routeur lui-même (avec, par exemple, Simple Network Management Protocol (SNMP), Telnet, Trivial File Transfer Protocol (TFTP) et ping). Déboguez les paquets pour le protocole approprié pour identifier la source de ces paquets. Quand vous trouvez la source, éliminez-la.

    • Le protocole de couche 2 fiable Open System Interconnection (OSI) est utilisée pour le transport - Les paquets qui passent par des interfaces série avec l'encapsulation X.25 doivent être traités parce que dans la suite de protocoles X.25, le contrôle de flux est mis en application sur la seconde couche OSI.

    • Compression logicielle - Si le paquet entre ou doit être transféré via une interface sur laquelle la compression logicielle est configurée, le paquet doit être traité.

    • D'autres fonctionnalités ne sont pas prises en charge au niveau de priorité d'interruption - Cela dépend fortement de la version du logiciel Cisco IOS qui est exécutée sur le routeur. Contrôlez les notes de publication pour voir quelles fonctionnalités sont prises en charge au niveau de priorité d'interruption. Par exemple, dans les versions antérieures du logiciel Cisco IOS, les paquets Multilink PPP devaient être traités. Dans les versions ultérieures du logiciel Cisco IOS, ils peuvent être commutés rapidement ou même commutés par CEF. Des fonctionnalités telles que le chiffrement, la traduction LAT (local-area transport) et Data-Link Switching Plus (DLSw+) ne sont pas encore commutées rapidement.

    • Un trafic excessif via le routeur, où chaque en-tête de paquet contient intentionnellement différentes informations - En fonction du chemin de commutation configuré, les premiers paquets vers une destination, ou dans un flux, sont toujours traités. C'est parce qu'il n'y a aucune entrée dans le cache qui leur correspond. Si un périphérique envoie des paquets à un débit extrêmement élevé, et qu'il n'y a aucune correspondance dans le cache, ces paquets peuvent congestionner la file d'attente d'entrée.

    La source de ces derniers paquets est indiquée après la session de débogage. Si l'adresse de la source est toujours différente, vous devez continuer à dépanner sur le périphérique en amont, à partir duquel le paquet est reçu. Si l'interface sur le routeur est connectée à un support de diffusion, vous pouvez déterminer l'adresse de contrôle d'accès au support (MAC) de la source ou du périphérique en amont :

    Configurez la gestion des comptes MAC sur l'interface avec la commande ip accounting mac-address input interface configuration. Après cela, émettez la commande show interfaces mac-accounting exec. Cette commande indique l'adresse MAC qui a envoyé les paquets à un débit excessif.

Pertes de la file d'attente de sortie

Les pertes en sortie sont provoquées par une interface congestionnée. Par exemple, le débit du trafic sur l'interface sortante ne peut pas accepter tous les paquets qui devraient être envoyés. La solution ultime pour résoudre le problème est d'augmenter la vitesse de la ligne. Cependant, il y a des façons d'empêcher, de diminuer ou de contrôler les pertes en sortie quand vous ne voulez pas augmenter la vitesse de la ligne. Vous pouvez empêcher les pertes en sortie seulement si elles sont une conséquence de brèves rafales de données. Si les pertes en sortie sont provoquées par un flux constant à haut débit, vous ne pouvez pas empêcher les pertes. Cependant, vous pouvez les contrôler.

Quand des paquets sont traités, ils sont envoyés à la file d'attente de sortie de l'interface sortante. Émettez la commande show interfaces exec pour afficher la taille de la file d'attente, le nombre actuel de paquets dans la file d'attente et le nombre de pertes. En fonction du type d'interface et du type de mise en file d'attente configuré, le nombre de pertes de la file d'attente de sortie n'est pas explicitement montré, parce que le compteur des pertes en sortie récapitule les pertes en sortie séparément au niveau du traitement et au niveau de priorité d'interruption :

router#show interfaces serial 0/0
  ...
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)   
  ...
router#show interfaces serial 0/0
...
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo 
Output queue :0/40 (size/max)
...

Cependant, cela prend plus de temps de traiter un paquet que d'envoyer le paquet de la file d'attente de sortie sur le réseau. Par conséquent, il est très peu probable que les pertes de file d'attente de sortie (pertes au niveau du traitement) puissent se produire sans pertes au niveau de priorité d'interruption. Les pertes de file d'attente de sortie se produisent seulement si l'interface est déjà congestionnée au niveau de priorité d'interruption, de sorte que les paquets ne peuvent pas être retirés de la file d'attente de sortie avant que la file d'attente soit remplie. Par conséquent, les pertes en sortie au niveau du traitement (pertes de file d'attente de sortie) et les pertes en sortie au niveau de priorité d'interruption se produisent toujours ensemble, et il n'y a pratiquement aucun besoin de distinguer ces deux compteurs.

Remarque:  Cependant, il y a une exception. Si la file d'attente de sortie est constamment pleine et si absolument aucun paquet n'est envoyé à l'interface, vous devez rechercher une défaillance matérielle sur l'interface.

Dépannage des pertes de la file d'attente de sortie

Vous pouvez diminuer, ou même empêcher, les pertes en sortie si vous ajustez la configuration des fonctionnalités suivantes :

  • Mode duplex - Si l'interface fonctionne en mode semi-duplex, configurez-la (si possible) pour qu'elle fonctionne en duplex intégral.

  • Mécanisme de fenêtrage de couche 2 - Si l'encapsulation X.25 est configurée sur l'interface, augmentez la taille de fenêtre x.25. Pour plus d'informations, consultez Configuration des tailles de fenêtre par défaut.

  • Commutation distribuée - Sur les routeurs Cisco 7500, si des cartes Versatile Interface Protocol (VIP) sont installées dans le châssis, activée la commutation distribuée. Quand vous faites cela, le VIP entrant met en mémoire tampon jusqu'à 1 seconde de trafic pour l'interface si l'interface sortante est congestionnée. Cela s'appelle la mise en mémoire tampon côté rx.

Remarque: N'augmentez jamais la file d'attente de sortie afin d'essayer d'empêcher des pertes en sortie. Si des paquets restent trop longtemps dans la file d'attente de sortie, les temporisateurs TCP peuvent expirer et déclencher la retransmission. Les paquets retransmis ne font que congestionner encore davantage l'interface sortante.

Si des pertes en sortie se produisent encore après avoir ajusté la configuration du routeur comme recommandé, cela signifie que vous ne pouvez pas empêcher ou diminuer les pertes en sortie. Cependant, vous pouvez les contrôler, et cela peut être aussi efficace que la prévention. Il y a deux approches pour contrôler les baisses de sortie :

  • Gestion de la congestion

  • Manière d'éviter d'encombrement

Les deux approches sont basées sur la classification du trafic, et vous pouvez les utiliser en parallèle.

La gestion de la congestion s'assure, avec la configuration appropriée, que les paquets importants sont toujours transférés, tandis que les paquets moins importants sont perdus quand la liaison est congestionnée. La gestion de la congestion comporte des mécanismes de mise en file d'attente recherchés comme :

La prévention de congestion est basée sur les pertes de paquets intentionnelles. La taille de la fenêtre dans les connexions TCP dépend du délai d'aller-retour. Par conséquent, ces pertes intentionnelles ralentissent le débit auquel le périphérique source envoie les paquets. La prévention de congestion utilise Weighted Random Early Detection.

Si des pertes en sortie non désirées se produisent encore après l'implémentation de ces mécanismes, vous devez augmenter la vitesse de la ligne.

Commandes pour obtenir plus d'informations

Voici quelques commandes qui fournissent plus d'informations sur les pertes de la file d'attente :

Si vous disposez d'une sortie d'une commande show interfaces de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et des solutions. Pour l'utiliser, vous devez être un client enregistré , être connecté, et avoir Javascript activé.

show interfaces switching

Description

Cette commande montre le nombre de paquets envoyés et reçus sur l'interface, classés en fonction du chemin de commutation. C'est une commande masquée.

Format

show interfaces [type number] switching

Exemple de sortie

Ethernet0/0 
               Throttle count          0
             Drops         RP          0      SP  0 
       SPD Flushes       Fast          0     SSE  0 
       SPD Aggress       Fast          0
      SPD Priority     Inputs         86   Drops  0     
          Protocol       Path    Pkts In   Chars In   Pkts Out   Chars Out
             Other    Process         75       6728         79        4740 
                 Cache misses          0 
                         Fast          0          0          0           0 
                    Auton/SSE          0          0          0           0
                IP    Process        142      11929         35        5169
                 Cache misses          0 
                         Fast          0          0          0           0 
                    Auton/SSE          0          0          0           0 
         AppleTalk    Process          0          0         25        1635
                 Cache misses          0
                         Fast          0          0          0           0
                    Auton/SSE          0          0          0           0 
           DEC MOP    Process          0          0          2         154
                 Cache misses          0
                         Fast          0          0          0           0 
                    Auton/SSE          0          0          0           0
               ARP    Process         56       3580         13         780 
                 Cache misses          0
                         Fast          0          0          0           0
                    Auton/SSE          0          0          0           0 
               CDP    Process         90      26906         27        8900
                 Cache misses          0
                         Fast          0          0          0           0 
                    Auton/SSE          0          0          0           0   
Champ Définition
<protocole> Process Nombre de paquets traités. Cela inclut les paquets destinés au routeur, et les paquets pour lesquels il n'y a aucune entrée dans la table de cache de commutation appropriée.
Cache misses Paquets qui sont transférés via le niveau processus (pour lequel il n'y a aucune entrée dans le cache de commutation rapide).
Rapide Paquets transférés au niveau de priorité d'interruption.

show interfaces stats

Description

Cette commande est semblable à la commande show interfaces switching , et fournit des informations sur le nombre de paquets qui sont commutés par processus, commutés rapidement (n'importe quel chemin de commutation rapide) et commutés distribués (pour les plates-formes compatibles VIP). C'est une commande masquée.

Format

show interfaces [type number] stats

Exemple de sortie

Router#show interfaces stats 
FastEthernet8/0/0 
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out 
               Processor         64      38646        323      32790 
             Route cache     477985  611343050      14815   18948150 
       Distributed cache          0          0       3564    4558356 
                   Total     478049  611381696      18702   23539296 
Serial12/0/0 
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out 
               Processor         37       3783         36       2299 
             Route cache      14815   18800000      45118   59862772 
       Distributed cache       3450    4378520          0          0 
                   Total      18302   23182303      45154   59865071 
Interface Serial12/0/1 is disabled 
...

ip accounting mac-address

Description

C'est une commande de configuration d'interface. Elle explique les paquets reçus ou transmis, classés en fonction de l'adresse MAC source ou de destination.

Format

ip accounting mac-address {input|sortie}

show interfaces mac-accounting

Description

C'est une commande d'exécution. Elle montre le nombre de paquets envoyés et reçus, classés en fonction de l'adresse MAC de destination et source.

Format

show interfaces [type number] mac-accounting

Exemple de sortie

router#show interfaces ethernet 0/0 mac-accounting
Ethernet0/0
  Input(494 free) 
    0000.0c5d.92f9(58 ):  1 packets, 106 bytes, last: 4038ms ago
    0004.c059.c060(61 ):  0 packets, 0 bytes, last: 2493135ms ago
    00b0.64bc.4860(64 ):  1 packets, 106 bytes, last: 20165ms ago
    0090.f2c9.cc00(103):  12 packets, 720 bytes, last: 3117ms ago 
                  Total:  14 packets, 932 bytes 
  Output (511 free)
    0090.f2c9.cc00(103):  8 packets, 504 bytes, last: 4311ms ago 
                  Total:  8 packets, 504 bytes

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 6343