Ce document explique comment dépanner une augmentation du nombre de pertes d'entrée qui apparaît dans le résultat de la commande show interface sur un routeur Internet de la gamme Cisco 12000.
Les lecteurs de ce document devraient avoir connaissance des sujets suivants :
Architecture du routeur Internet de la gamme Cisco 12000
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Toute version du logiciel Cisco IOS® prenant en charge le routeur Internet de la gamme Cisco 12000. Par exemple, le logiciel Cisco IOS Versions 12.0S et 12.0ST.
Toutes les plates-formes Cisco 12000, dont 12008, 12012, 12016, 12404, 12410 et 12416.
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. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Le symptôme le plus courant est une augmentation du nombre de gouttes d'entrée. Vous pouvez voir le nombre de pertes d'entrée dans le résultat de la commande show interfaces sur le routeur Internet de la gamme Cisco 12000. Voici un exemple de sortie de la commande show interfaces :
Router#show interface Gig2/0 GigabitEthernet2/0 is up, line protocol is up Hardware is GigMac 3 Port GigabitEthernet, address is 0003.fd1a.9040 (bia 0003.fd1a.9040) Internet address is 203.177.3.21/24 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex mode, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:55:39 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 27/75, 954 drops !--- Here are the input drops. 5 minute input rate 3000 bits/sec, 5 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7167 packets input, 601879 bytes, 0 no buffer Received 2877 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 3638 multicast, 0 pause input 992 packets output, 104698 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 1 lost carrier, 21992 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
Exécutez la commande show interfaces toutes les 10 secondes pour vérifier si le compteur de pertes augmente pour la file d'attente d'entrée.
Lorsqu’un paquet entre dans le routeur, celui-ci tente de le transférer au niveau d’interruption. Si le routeur ne trouve pas de correspondance dans une table de cache appropriée, il met le paquet en file d’attente dans la file d’attente d’entrée de l’interface entrante pour traiter le paquet plus tard. Le routeur traite toujours certains paquets. Cependant, le taux de paquets traités ne congestionne jamais la file d'attente d'entrée dans les réseaux stables avec la configuration appropriée. Si la file d’attente d’entrée est pleine, le routeur abandonne le paquet.
Dans l'exemple de sortie, vous ne pouvez pas identifier exactement les paquets que le routeur abandonne. Afin de dépanner les pertes de file d'attente d'entrée, vous devez déterminer quels paquets remplissent la file d'attente d'entrée. L'exemple de sortie indique que 27 paquets attendent dans la file d'attente d'entrée de l'interface GigabitEthernet2/0. La profondeur de la file d'attente est de 75 paquets, et 954 abandons ont eu lieu après avoir effacé les compteurs d'interface pour la dernière fois.
Dans un réseau qui efface un grand nombre de routes, les abandons de file d'attente d'entrée peuvent entraîner :
Échecs de keepalive de couche 2
Protocole de routage de secours à chaud/protocole de redondance de routeur virtuel (HSRP/VRRP)
Frappes d'interface
Les valeurs par défaut sont inadéquates pour les systèmes qui prennent en charge un grand nombre d’interfaces ou de routes, en particulier dans les réseaux de fournisseurs de services plus importants. Une seule suppression du protocole BGP (Border Gateway Protocol) peut souvent entraîner des milliers de pertes de file d'attente d'entrée sur la même interface. De grandes pertes d'entrée peuvent fortement entraver les temps de convergence.
Complétez ces étapes afin d'éviter une telle situation :
Utilisez la commande globale spd headroom 1000 pour augmenter la portée SPD (Selective Packet Discard).
La valeur par défaut de la salle de tête SPD est 100. La commande spd headroom spécifie le nombre de paquets de haute priorité que vous pouvez mettre en file d'attente au-dessus de la limite de file d'attente de mise en attente d'entrée normale. Les paquets de haute priorité incluent des mises à jour de protocole de routage et d'autres trafic de contrôle important, par exemple des keepalives de couche 2 et des paquets Hello IS-IS. Lorsque vous spécifiez cette valeur, vous réservez de la place pour les paquets entrants de haute priorité. Dans le logiciel Cisco IOS Version 12.0(22)S et ultérieure, la valeur par défaut pour la tête de SPD est 1000 pour le routeur Internet de la gamme Cisco 12000. Utilisez la commande show ip spd pour vérifier la valeur.
Utilisez hold-queue 1500 pour chaque interface pour augmenter la valeur de la file d'attente de l'interface. La valeur par défaut est 75.
Comme indiqué précédemment dans le document, seuls les paquets destinés au routeur atteignent la file d'attente d'entrée. Le processeur de routage Gigabit (GRP) doit déterminer comment gérer les paquets. Tous les paquets sont commutés par processus. Par conséquent, les paquets empruntent le chemin lent. En règle générale, tous les paquets que les commutateurs du routeur Cisco 12000 utilisent la fonction Distributed Cisco Express Forwarding (dCEF) via les cartes de ligne. Cette plate-forme prend uniquement en charge dCEF comme méthode de commutation.
Parfois, des abandons surviennent lors de la convergence BGP (Border Gateway Protocol) si le routeur a un grand nombre d'homologues. Cependant, il existe de nombreuses raisons valables pour lesquelles le protocole GRP doit examiner certains paquets. Voici quelques raisons :
Le protocole GRP reçoit des mises à jour de routage.
Le protocole GRP gère les paquets ICMP (Internet Control Message Protocol).
Le protocole GRP établit et conserve des sessions homologues BGP.
Utilisez la commande show interfaces stat pour vérifier s'il existe des paquets à commutation de processus.
Si le routeur Cisco 12000 n'est pas encore en production, vous pouvez activer certaines commandes debug. Les commandes de débogage vous permettent de capturer plus d'informations sur le type de paquets que le protocole GRP reçoit. La sortie debug ip packet est très utile. Cependant, soyez très prudent avec cette commande, car elle peut affecter le comportement du routeur par un blocage, un plantage ou d’autres problèmes similaires. Désactivez les journaux de console pour éviter une rafale de messages vers le port de console. Activez la mémoire tampon du journal pour rediriger le résultat de la commande debug vers une mémoire tampon que vous pourrez consulter ultérieurement. Utilisez la commande show logging pour afficher la mémoire tampon. Vous pouvez également spécifier une liste d'accès pour affiner la sortie de débogage. Afin de spécifier une liste d'accès, utilisez cette configuration :
no logging console logging buffer 128000 debug ip packet <ACL #> !--- Warning: !--- Be aware that this configuration on a production router can damage the box. undebug all (after 5-10 seconds)
Cette commande debug vous permet de voir tous les paquets à commutation de processus que le protocole GRP reçoit. Vous pouvez également utiliser la commande show buffers input-interface [type d'interface] [numéro d'interface] header pour identifier le type de paquets qui remplissent la file d'attente d'entrée.
Remarque : cette commande n'est utile que lorsque la file d'attente d'entrée contient beaucoup de paquets.
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
Souvent, le même type de paquet est présent en grande quantité. Par exemple, l'exemple de sortie indique un grand nombre de paquets ICMP (protocole IP 1).
Remarque : Si vous ne parvenez pas à identifier un modèle dans les sorties des commandes debug ou show buffers input-interface, le problème est probablement une configuration de routeur incorrecte.
Remarque : Pour plus d'informations, référez-vous à Dépannage des pertes de file d'attente d'entrée et de file d'attente de sortie.
Effectuez les actions appropriées en fonction du résultat de la commande debug ip packet detail, ou comme indiqué dans Dépannage des pertes de file d'attente d'entrée et de file d'attente de sortie. Pour un exemple détaillé, voir la section Étude de cas .
Parfois, lorsque vous vérifiez l'interface de votre routeur Cisco 12000, vous constatez que l'interface abandonne les paquets entrants. Par conséquent, la valeur du compteur de l'entrée diminue régulièrement. Prenons par exemple l'exemple suivant :
Router#show interface Gig2/0 GigabitEthernet2/0 is up, line protocol is up Hardware is GigMac 3 Port GigabitEthernet, address is 0003.fd1a.9040 (bia 0003.fd1a.9040) Internet address is 203.177.3.21/24 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex mode, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:55:39 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 27/75, 954 drops !--- This is the input drops counter value. 5 minute input rate 3000 bits/sec, 5 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7167 packets input, 601879 bytes, 0 no buffer Received 2877 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 3638 multicast, 0 pause input 992 packets output, 104698 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 1 lost carrier, 21992 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
Certaines pertes d'entrée apparaissent dans le résultat de la commande show interfaces. Si vous émettez cette commande toutes les 10 secondes, vous pouvez vérifier si le compteur de dépôt augmente pour la file d'attente d'entrée.
Utilisez la commande show interface stat pour vérifier la présence de paquets à commutation de processus :
Router#show interfaces stat ..... GIG2/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 45354 1088496 0 0 !--- Here are the packets that are process-switched (sent to the GRP) Route cache 0 0 0 0 Distributed cef 0 0 8575 207958 Total 45354 1088496 8575 207958 ....
Si le routeur Cisco 12000 n'est pas encore en production, vous pouvez activer certaines commandes de débogage pour capturer plus d'informations sur le type de paquets que le protocole GRP reçoit. Le résultat de la commande debug ip packet est intéressant. Avec cette commande debug, vous pouvez voir tous les paquets à commutation de processus que le GRP reçoit. Émettez la commande show logging après un certain temps :
Router#show log Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: disabled Monitor logging: level debugging, 1110 messages logged Logging to: vty2(572) vty3(538) Buffer logging: level debugging, 107 messages logged Trap logging: level informational, 162 message lines logged Log Buffer (10000 bytes): *Jan 13 08:03:51.550: %SYS-5-CONFIG_I: Configured from console by vty2 (144.254.2.215) 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 79, sending 1w5d: IP: s=203.177.3.62 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=0.0.0.0 (GigabitEthernet2/0), d=255.255.255.255, len 328, rcvd 2 1w5d: IP: s=203.177.3.15 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), len 40, rcvd 3 1w5d: IP: s=203.177.3.1 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.2 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.10 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.6 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.62 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.1 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.15 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 69, unroutable 1w5d: IP: s=203.177.3.2 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.10 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 89, unroutable 1w5d: IP: s=203.177.3.6 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.62 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.15 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.1 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), len 41, rcvd 3 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41, sending 1w5d: IP: s=203.177.3.2 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.10 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), len 41, rcvd 3 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41, sending 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=203.177.3.6 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), len 43, rcvd 3 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41, sending 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41, sending
Dans cet exemple, l'interface GigabitEthernet2/0 reçoit beaucoup de paquets EIGRP (Enhanced Interior Gateway Routing Protocol). Le protocole EIGRP utilise l’adresse de multidiffusion 224.0.0.10, mais vous n’avez pas configuré le routeur pour gérer de tels paquets. Par conséquent, le routeur envoie ces paquets au protocole GRP. Le protocole GRP prend la décision de supprimer les paquets, car le protocole GRP ne peut pas les traiter assez rapidement.
Afin de vous assurer que le protocole GRP ne reçoit pas ces paquets EIGRP, vous pouvez effectuer l'une des actions suivantes :
Spécifiez l’interface comme passive sur les autres routeurs.
Spécifiez différents routeurs voisins.
Parfois, le nombre de pertes d'entrée augmente en raison d'un défaut du logiciel Cisco IOS. Par exemple, dans le logiciel Cisco IOS Version 12.0(11)S, le routeur Internet de la gamme Cisco 12000 incrémente incorrectement le compteur des pertes d'entrée en raison d'un problème de comptabilité. Le résultat ne reflète pas correctement le nombre de paquets abandonnés pendant la congestion. Toutes les interfaces peuvent indiquer ce problème, mais le problème n'affecte pas le service ou la fonctionnalité des interfaces. Il n'existe aucune solution connue.
Assurez-vous d'exécuter la dernière version du logiciel Cisco IOS disponible dans votre train pour éliminer les bogues corrigés. Si vous voyez toujours des abandons par la suite, ouvrez une demande de service via la .
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
07-Jul-2005 |
Première publication |