Présentation des raisons d'un taux d'utilisation du processeur VIP à 99 % et présentation de la mise en mémoire tampon Rx-Side

Introduction

Ce document explique pourquoi la CPU de Versatile Interface Processor (VIP) fonctionne à 99%, et ce qui sont des mémoires tampons de Rx-side.

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.

Informations générales

la mise en mémoire tampon de Rx-side est le processus qui se produit quand l'interface sortante :

• est congestionné.

• utilise le premier dedans, d'abord (FIFO) stratégie de queue.

La Versatile Interface Processor d'arrivée (VIP) ne relâche pas le paquet immédiatement. Au lieu de cela, il met en mémoire tampon le paquet dans sa mémoire de paquet jusqu'à ce que les mémoires tampons soient disponibles pour l'interface sortante. Basé sur le type de VIP, la mémoire de paquet peut être MÉMOIRE RAM statique (SRAM) ou mémoire vive dynamique synchrone (SDRAM).

Fondements d'architecture de gamme Cisco 7500

Chaque processeur d'interface (IP de legs ou VIP) a une connexion à un bus système étendu ultra-rapide appelé un CyBus. Des processeurs d'artère/commutateur (RSPs) sont connectés à deux CyBuses (voir le schéma 1).

Figure 1 – Architecture de gamme Cisco 7500

Types de tampons de paquets

Cette section décrit les divers types de tampons de paquets.

• Mises en mémoire tampon du système dans la mémoire du processeur sur le RSP

  Ces mémoires tampons sont utilisées pour des paquets commutés par processus. Vous pouvez voir ces mémoires tampons dans la sortie des interfaces d'exposition (files d'attente d'entrée et sortie) et des commandes de shows buffer. Un routeur de gamme Cisco 7500 ne doit pas faire beaucoup de processus-commutation. Par conséquent, si vous avez des problèmes avec des mises en mémoire tampon du système, il signifie que trop de paquets sont envoyés au niveau de processus. Ceci peut être dû à beaucoup de facteurs, comme :

  • Une saturation de diffusion

  • Instabilité dans le réseau qui entraîne des mises à jour de routage

  • Une attaque de « déni de service » (DOS)

  • Une caractéristique qui n'est pas prise en charge dans le chemin de commutation rapide (par exemple, le X.25)

  • Paquets IP avec des options.

  Pour les informations sur la façon dont dépanner la commutation de processus excessive, référez-vous à ces documents :

  • Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco

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

• Mémoire de paquet sur des mémoires tampons RSP (MEMD)

  La taille de MEMD est réparée à 2 Mo sur le RSP7000, le RSP1, le RSP2, et le RSP4. Sur le RSP8 et le RSP16, la taille de MEMD est 8 Mo. MEMD est distribué entre toutes les interfaces au moment du démarrage, quand il y a une mise en place et une suppression en ligne (OIR), une recharge de microcode, une modification de Maximum Transmission Unit (MTU), ou un cbus complex. Pour plus d'informations sur le cbus complex, référez-vous à ce qui entraîne un "%RSP-3-RESTART : cbus complex » ?. Vous pouvez utiliser la commande de show controllers cbus de vérifier le statut de mémoires tampons MEMD.

  Quand MEMD est alloué, ces structures sont créées :

  • Une file d'attente libre locale (lfreeq) — Il est assigné à chaque interface, et est utilisé pour des paquets reçus sur cette interface.

  • Une file d'attente libre globale (gfreeq) — Il est également alloué, et une interface peut retomber à cette file d'attente dans quelques limites.

  • Une file d'attente de transmission (txqueue ou txq) — il est assigné à chaque interface, et est utilisé pour les paquets qui sortent par cette interface.

  • L'accumulateur de transmission (txacc) — Il représente le nombre d'éléments sur la file d'attente de transmission d'interface de sortie (txqueue). Quand l'accumulateur de transmission (txacc) égale la limite de transmission (txlimit), toutes les mémoires tampons sont libérées. Quand le txacc est 0, la file d'attente est pleine, et plus s'alignant est laissé.

• Mémoire de paquet

  Sur un VIP, la mémoire de paquet contient des tampons de paquets (particules) utilisés pour des paquets reçus de ou envoyés à une interface de VIP. La figure 2 représente l'écoulement de paquet.

  Figure 2 – Écoulement de paquet

  

  Cette section se concentre sur un VIP où la commutation distribuée est activée, parce que le Rx-side bufferisant se produit habituellement quand un paquet suit ce type de chemin de commutation. Les différents scénarios sont possibles, qui sont expliqués ici :

  Scénario 1 : Quand il n'y a aucun encombrement sur le sortant reliez.

  • Un paquet est reçu sur un adaptateur de port (PA) et entré dans un tampon de paquets dans la mémoire de paquet.

  • Si le VIP ne peut pas distribuer-commutateur le paquet, il en avant le paquet au RSP, qui prend la décision de commutation.

  • Si le VIP peut prendre la décision de commutation et l'interface sortante est sur le même VIP, le paquet est envoyé sur l'interface sortante. Le paquet est dit « localement commuté » sur le VIP, parce qu'il ne croise pas le cbus.

  • Si le VIP peut prendre la décision de commutation et l'interface sortante est dans un autre emplacement, les essais de VIP pour copier le paquet au-dessus du cbus dans le txqueue (dans MEMD) de l'interface sortante.

  • Le paquet est alors copié sur (V) l'IP sortant au-dessus du cbus et envoyé sur la ligne.

  Scénario 2 : Quand l'interface sortante est congestionnée.

  Il y a deux possibilités :

  • Si s'alignant est configuré sur l'interface sortante, le VIP transfère le paquet dans le txqueue dans MEMD, et le paquet est tiré immédiatement de la file d'attente par le code de queue.

    • Si la queue basée sur RSP est configurée, le paquet est copié dans les mises en mémoire tampon du système dans la mémoire du processeur sur le RSP.

    • Si la queue basée sur VIP est utilisée, le paquet est copié dans la mémoire de paquet du VIP sortant.

  • Si la stratégie de queue de l'interface sortante est FIFO, l'interface ne relâche pas le paquet immédiatement (c'est ce qui se produit normalement avec le FIFO quand une interface sortante est congestionnée). Au lieu de cela, le VIP d'arrivée met en mémoire tampon le paquet dans sa mémoire de paquet jusqu'à ce que quelques mémoires tampons soient de nouveau disponibles pour l'interface sortante. Cela s'appelle la mise en mémoire tampon côté rx.

Utilisez la commande d'accumulateur de VIP de shows controllers de vérifier le statut de mise en mémoire tampon de Rx-side. L'état indique :

• Le nombre d'interfaces de sortie présentent dans le routeur.

• Combien de paquets le VIP Rx-a mis en mémoire tampon pour ces interfaces.

• Pourquoi le VIP Rx-a mis en mémoire tampon.

• Combien de paquets le VIP a relâchés, et pourquoi.

Passages de VIP à l'utilisation du processeur de 99%

Une conséquence de la mise en mémoire tampon de Rx-side est que le VIP s'exécute à l'utilisation du processeur de 99%. Le VIP surveille continuellement le statut du txqueue de l'interface sortante et, dès qu'il y aura une mémoire tampon libre, elle copie le paquet au-dessus du cbus dans le txqueue.

Il n'y a rien qui alarme en soi quand le VIP s'exécute à 99% quand la Rx-mise en mémoire tampon se produit. Il ne signifie pas que le VIP est surchargé. Si le VIP reçoit quelque chose plus importante pour faire (par exemple, un autre paquet à commuter), ceci n'est pas affecté par la CPU de haute.

Voici un test simple que vous pouvez faire dans le laboratoire pour illustrer ceci :

L'interface série 2/0/0 a un rythme d'horloge de 128 Kbps, et reçoit le trafic à la ligne débit. Le trafic est commuté à l'interface série 10/0 où le rythme d'horloge est des 64 Kbits/s, et la stratégie de queue est FIFO. La seule option est de relâcher des paquets.

router#show controller cbus 

MEMD at 40000000, 8388608 bytes (unused 697376, recarves 6, lost 0) 

RawQ 48000100, ReturnQ 48000108, EventQ 48000110 

BufhdrQ 48000130 (21 items), LovltrQ 48000148 (15 items, 2016 bytes) 

IpcbufQ 48000158 (24 items, 4096 bytes) 

IpcbufQ_classic 48000150 (8 items, 4096 bytes) 

3570 buffer headers (48002000 - 4800FF10) 

pool0: 8 buffers, 256 bytes, queue 48000138 

pool1: 2940 buffers, 1536 bytes, queue 48000140 

pool2: 550 buffers, 4512 bytes, queue 48000160 

pool3: 4 buffers, 4544 bytes, queue 48000168 

slot2: VIP2, hw 2.11, sw 22.20, ccb 5800FF40, cmdq 48000090, vps 8192 

software loaded from system 

IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE 
SOFTWARE (fc1) 

ROM Monitor version 122.0 

Mx Serial(4), HW Revision 0x3, FW Revision 1.45 

Serial2/0/0, applique is V.35 DCE 

received clockrate 2015232 

gfreeq 48000140, lfreeq 480001D0 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 16, maxrxcurr 293 

txq 48001A00, txacc 48001A02 (value 294), txlimit 294 

Serial2/0/1, applique is V.35 DTE 

received clockrate 246 

gfreeq 48000140, lfreeq 480001D8 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A08, txacc 48001A0A (value 6), txlimit 6 

Serial2/0/2, applique is Universal (cable unattached) 

received clockrate 246 

gfreeq 48000140, lfreeq 480001E0 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A10, txacc 48001A12 (value 6), txlimit 6 

Serial2/0/3, applique is Universal (cable unattached) 

received clockrate 246 

gfreeq 48000140, lfreeq 480001E8 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A18, txacc 48001A1A (value 6), txlimit 6 

slot10: FSIP, hw 1.12, sw 20.09, ccb 5800FFC0, cmdq 480000D0, vps 8192 

software loaded from system 

Serial10/0, applique is V.35 DTE 

gfreeq 48000140, lfreeq 48000208 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 1, maxrxcurr 1 

txq 48000210, txacc 480000B2 (value 2), txlimit 294 

Serial10/1, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000218 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000220, txacc 480000BA (value 6), txlimit 6 

Serial10/2, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000228 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000230, txacc 480000C2 (value 6), txlimit 6 

Serial10/3, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000238 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000240, txacc 480000CA (value 6), txlimit 6 

Serial10/4, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000248 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000250, txacc 480000D2 (value 6), txlimit 6 

Serial10/5, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000258 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000260, txacc 480000DA (value 6), txlimit 6 

Serial10/6, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000268 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000270, txacc 480000E2 (value 6), txlimit 6 

Serial10/7, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000278 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000280, txacc 480000EA (value 6), txlimit 6 

router# 

La valeur 2 signifie que seulement deux mémoires tampons sont laissées. la Rx-mise en mémoire tampon n'aligne pas des paquets dans MEMD quand le txacc est moins de 4.

La commande de support technique du VIP 2 de shows controllers du VIP prouve qu'elle fonctionne à la CPU de 99% :

router#show controllers vip 2 tech-support 

show tech-support from Slot 2: 

------------------ show version ------------------ 


Cisco Internetwork Operating System Software 

IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE 
SOFTWARE (fc1) 

Copyright (c) 1986-2000 by cisco Systems, Inc. 

Compiled Tue 18-Jul-00 22:03 by htseng 

Image text-base: 0x600108F0, data-base: 0x602E0000 


ROM: System Bootstrap, Version 11.1(4934) [pgreenfi 122], INTERIM SOFTWARE 


VIP-Slot2 uptime is 1 week, 23 hours, 27 minutes 

System returned to ROM by power-on 

Running default software 



cisco VIP2 (R4700) processor (revision 0x02) with 32768K bytes of memory. 

Processor board ID 00000000 

R4700 CPU at 100Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache 

4 Serial network interface(s) 

Configuration register is 0x0 

... 

------------------ show process cpu ------------------ 

CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69% 

Le VIP s'exécute à l'utilisation du processeur de 99% quoiqu'elle reçoive seulement 128 Kbps. Ceci prouve que l'utilisation du processeur n'est pas liée au nombre de paquets par seconde. C'est parce qu'un VIP 2 peut commuter beaucoup plus de paquets que ceci. C'est simplement un signe de mise en mémoire tampon de Rx-side.

Afin de vérifier quelle mise en mémoire tampon de Rx-side fait, exécutez ces commandes :

router#show controllers vip 2 accumulator

show vip accumulator from Slot 2:

Buffered RX packets by accumulator:
...
Serial10/0: 
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps   
   No MEMD acc: 544980 in      
      Limit drops  : 2644102 normal pak drops, 80 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops   
   No MEMD buf: 0 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops
...
Interface x: 
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps 
No MEMD acc: i in
      Limit drops  : j normal pak drops, k high prec pak drops      
      Buffer drops : l normal pak drops, m high prec pak drops
No MEMD buf: n in
      Limit drops  : o normal pak drops, p high prec pak drops      
      Buffer drops : q normal pak drops, r high prec pak drops

Clé	Description
a	Adresse du txacc dans MEMD. Il y a une file d'attente de mémoire tampon de Rx-side pour chaque txacc dans le système (jusqu'à 4096).
b	Nombre de paquets qui Rx-sont mis en mémoire tampon.
c	Nombre de paquets que le VIP a relâchés. S'il y a assez de tampons mémoire de paquet, le VIP peut Rx-mémoire tampon jusqu'à une seconde du trafic. Cependant, si l'interface est continuellement congestionnée, il n'est pas possible d'éviter des baisses.
d	Nombre de paquets actuellement Rx-mis en mémoire tampon.
e	Nombre de particules actuellement Rx-mises en mémoire tampon. Un paquet peut être fait de plusieurs particules.
f	Limite douce, qui est le nombre maximal de particules quand la mémoire de VIP est basse.
g	Limite dure, qui est le nombre maximal de particules qui peuvent être utilisées à tout moment.
h	La vitesse de l'interface sortante dans le Kbps.
i	Le nombre de paquets Rx-mis en mémoire tampon parce qu'aucun txacc n'était disponible dans MEMD. Ceci signifie que la file d'attente de sortie a été congestionnée (plus de mémoires tampon libres ne sont disponibles dans le tx-queue). La solution au problème est d'augmenter la bande passante d'interface de sortie (si possible).
j	Le nombre de paquets avec la Priorité IP autre que 6 ou 7 qui ne pourraient pas être envoyés parce qu'il n'y a aucun CRNA MEMD, et sont abandonnés parce que la limite douce ou dure des particules a été atteinte.
k	Mêmes que j, mais pour des paquets avec la Priorité IP 6 ou 7 (interréseau et réseau).
l	Le nombre de paquets avec la Priorité IP autre que 6 ou 7 que le VIP veut la Rx-mémoire tampon, mais baisses dues à un manque de mémoires tampon libres dans la mémoire de paquet. Des versions du logiciel Cisco IOS 12.0(13)S et 12.1(4) en avant, vous pouvez également le VIP utiliser show controller [tout/slot#] que les paquet-mémoire-baisses commandent de voir le nombre de paquets abandonnés. Dans ce cas, une mise à jour de la mémoire de paquet aide.
m	Mêmes que l, mais pour des paquets avec la Priorité IP 6 ou 7 (interréseau et réseau).
n	Le nombre de paquets le VIP essaye la Rx-mémoire tampon parce qu'il n'y a aucun tampon MEMD, mais ne peut pas faire si en raison des mémoires tampons d'un manque de mémoire de paquets. Améliorez la mémoire de paquet dans ce cas. Des versions du logiciel Cisco IOS 12.0(13)S et 12.1(4) en avant, vous pouvez également le VIP utiliser shows controllers [tout/slot#] que les paquet-mémoire-baisses commandent de comprendre pourquoi les paquets ont été lâchés.
o	Le nombre de paquets Rx-mis en mémoire tampon avec la Priorité IP autre que 6 ou 7 sans le tampon MEMD qui sont relâchés parce que le (f) doux ou la limite dure (G) a été atteint. Dans cette situation, un RSP16 aide parce qu'il a plus de mémoire MEMD (8 Mo comparés à 2 Mo pour le RSP1, le RSP2, le RSP4, et le RSP7000). Vous pouvez également réduire le MTU de quelques interfaces (telles que l'atmosphère, le POS, ou le FDDI) dans ce cas. Ces interfaces ont habituellement un MTU 4470-byte, et moins mémoires tampons MEMD peuvent être allouées parce que les mémoires tampons doivent être plus grandes.
p	Mêmes qu'o, mais pour des paquets avec la Priorité IP 6 ou 7 (interréseau et réseau).
q	Le nombre de paquets avec la Priorité IP autre que 6 ou 7 que le VIP essaye la Rx-mémoire tampon parce qu'il n'y a aucun tampon MEMD, mais ne peut pas faire si en raison des mémoires tampons d'un manque de mémoire de paquets. Une mise à jour de la mémoire de paquet aide dans ce cas. Des versions du logiciel Cisco IOS 12.0(13)S et 12.1(4) en avant, vous pouvez également le VIP utiliser shows controllers [tout/slot#] que les paquet-mémoire-baisses commandent de comprendre mieux pourquoi les paquets ont été lâchés.
r	Mêmes que q, mais pour des paquets avec la Priorité IP 6 ou 7 (interréseau et réseau).

Si le routeur exécute une version de logiciel de Cisco IOS plus tôt que le 12.0(13)ST, 12.1(04)DB, 12.1(04)DC, 12.0(13)S, 12.1(4) 12.1(4)AA 12.1(4)T 012.0(13), ou 12.0(13)SC, la sortie de l'accumulateur de VIP de shows controllers [tout/slot#] fournit une version simplifiée de ce qui précède. Il ne prend pas en considération les différentes priorités IP des paquets relâchés en raison de la mise en mémoire tampon de Rx-side.

La sortie ressemble à ceci :

Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer
No MEMD buf: 0 in, 0 limit drops, 0 no buffer


Interface x: 
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps 
No MEMD acc: i in, j+k limit drops, l+m no buffer 
No MEMD buf: n in, o+p limit drops, q+r no buffer 

Exemples des mémoires tampons du Rx-side

Exemple 1 : Le VIP dans l'emplacement 2 reçoit le trafic sur un 128Kbps et le conduit à l'interface série 10/0 (64 Kbits/s).

Serial10/0: 
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps   
   No MEMD acc: 544980 in      
      Limit drops : 2644102 normal pak drops, 80 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops   
   No MEMD buf: 0 in      
      Limit drops : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 

• Ici, 544980 paquets Rx-sont avec succès mis en mémoire tampon et 2644182 sont relâchés. 80 paquets hors des 2644182 qui sont lâchés ont eu une Priorité IP de 6 ou de 7.

• 126 paquets Rx-sont actuellement mis en mémoire tampon et ils utilisent 378 particules.

• Tous les paquets Rx-sont mis en mémoire tampon en raison d'un manque de mémoire tampon libre dans le tx-queue dans MEMD. Ceci signifie que l'interface de sortie est congestionnée. Les baisses se produisent parce que le nombre maximal de paquets Rx-mis en mémoire tampon est atteint. La solution typique est d'améliorer la bande passante sortante d'interface, reroutent du trafic de sorte que l'interface sortante moins soit congestionnée, ou d'en activer qui s'aligne pour relâcher le trafic moins important.

Exemple 2 : mémoires tampons de Rx-side sans baisses.

ATM1/0: 
MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps 
No MEMD acc: 85709 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
No MEMD buf: 117795 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 

• Dans cet exemple, 85709 paquets Rx-sont mis en mémoire tampon parce que l'atmosphère 1/0 est congestionnée mais aucun paquet n'est lâché.

• 117795 paquets Rx-sont mis en mémoire tampon parce que le VIP ne peut pas obtenir un tampon MEMD. Aucun paquet n'est lâché. Une solution typique est de diminuer certains des mtu de sorte que plus de mémoires tampons MEMD puissent être allouées. Également aides Un RSP8.

Exemple 3 : Commutation locale.

SRP0/0/0: 

 local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps 

Le txacc local signifie que cette interface de sortie est sur le même VIP que l'interface où les paquets sont reçus. Ces paquets sont commutés localement, mais l'interface sortante (dans ce cas, srp 0/0/0) est congestionnée. 2529 paquets Rx-sont mis en mémoire tampon, et aucun paquet n'est lâché.

Exemple 4 : Files d'attente en avant.

router#show controllers vip 2 accumulator
Buffered RX packets by accumulator: 
 Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps   
   No MEMD buf: 142041 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 3 normal pak drops, 0 high prec pak drops 
 Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps   
   No MEMD buf: 68 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
 Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps   
   No MEMD buf: 414 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
 Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps   
   No MEMD buf: 46 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops

Quelques paquets ne peuvent pas distribuer-être commutés. Dans ce cas, le VIP doit expédier les paquets à la file d'attente de paquets non traités du RSP, qui prend alors la décision de commutation. Quand des paquets ne peuvent pas être copiés immédiatement dans MEMD, les Rx-mémoires tampons de VIP ils et maintient combien de paquets Rx-sont mis en mémoire tampon par interface d'arrivée.

Les files d'attente en avant 0-7 sont pour le premier adaptateur de port (PA) et 8-15 pour la deuxième PA.

Nombre en avant de file d'attente	… affiche le nombre de paquets Rx-mis en mémoire tampon qui sont reçus sur…
0	première bonde du premier adaptateur de port (PA)
8	première bonde de la deuxième PA
9	deuxième bonde de la deuxième PA

D'autres causes de l'utilisation du CPU élevé sur des VIPs

Quand la mise en mémoire tampon de Rx-side s'avère inactive, un de ces facteurs peut entraîner l'utilisation du CPU élevé sur le VIP :

• Utilisation du processeur de 99% sur le VIP, provoqué par la formation distribuée du trafic

  Quand le Formatage du trafic distribué (dTS) est configuré, la CPU de VIP branche à 99% dès qu'un paquet entrera dans la file d'attente de dTS.

  C'est le comportement correct et prévu. Quand le dTS est configuré, la CPU de VIP tourne pour vérifier si la prochaine fois que l'intervalle (comité technique) arrive quand la CPU n'est pas occupée (c'est-à-dire, quand il n'y a aucun trafic). Autrement, la vérification est couverte dans les routines d'interruption tx/rx. Vous tournez la CPU seulement quand elle n'est pas occupée. Par conséquent, la représentation n'est pas affectée.

  Pour comprendre ce que signifie le « prochain intervalle de temps », voyez ce qui est un seau à jetons ?

  Remarque: La formation du trafic devient active seulement quand elle doit mettre un paquet en file d'attente dans la file d'attente de formation. En d'autres termes, quand le niveau de trafic dépasse le taux de mise en forme. Ceci explique pourquoi la CPU de VIP n'est pas toujours 99% quand le dTS est configuré. Pour plus d'informations sur le dTS, voyez :

  • Formatage du trafic distribué

  • Configurer la formation distribuée du trafic

• Utilisation du CPU élevé sur le VIP provoqué par des accès mémoire erratiques et des erreurs de cadrage

  Les erreurs et les accès mémoire erratiques de cadrage sont défectueux des pannes de logiciel qui sont corrigées par le logiciel de Cisco IOS sans nécessité de tomber en panne le VIP. Si ces erreurs apparaissent fréquemment, il fait faire le système d'exploitation beaucoup de corrections qui peuvent mener à l'utilisation du CPU élevé.

  Pour plus d'informations sur des erreurs et des accès mémoire erratiques de cadrage, voir des accès erratiques de dépannage, des erreurs de cadrage, et les fausses interruptions.

  Pour vérifier des accès mémoire erratiques et des erreurs de cadrage, utilisez la commande de show alignment. Un exemple d'une telle erreur ressemble à ceci :

  VIP-Slot1#show alignment
  No alignment data has been recorded.
  No spurious memory references have been recorded.

D'autres causes de l'utilisation du CPU élevé peuvent être la quantité et l'ampleur des caractéristiques distribuées qui sont activées. Si vous suspectez que ceci pourrait être la raison, ou si vous ne pouvez pas identifier des causes l'unes des pour l'utilisation du CPU élevé expliquée dans ce document, ouvrez une demande de service avec le centre d'assistance technique Cisco (TAC).

Informations à collecter si vous ouvrez une demande de service TAC

Si vous avez besoin toujours d'assistance après que vous suiviez les étapes de dépannage ci-dessus et vouliez ouvrir une demande de service (clients enregistrés seulement) avec Cisco TAC, soyez sûr d'inclure ces informations :

Sortez de la commande d'accumulateur de VIP de shows controllers [tout/slot#] Sortie de la commande de Soutien technique d'exposition du RSP et du VIP appropriés Veuillez joindre les données rassemblées à votre demande de service en format non compressé et texte clair (.txt). Afin de relier les informations à votre demande de service, téléchargez-la par l'outil de demande de service TAC (clients enregistrés seulement). Si vous ne pouvez pas accéder à l'outil de demande de service, vous pouvez relier les informations pertinentes à votre demande de service, et l'envoyez à attach@cisco.com avec votre nombre de demande de service dans le champ objet de votre message. Remarque: S'il vous plaît ne rechargez pas manuellement ou arrêt et redémarrage le routeur avant que vous collectiez les informations ci-dessus (à moins que requis pour restaurer l'exploitation réseau), parce que ceci peut causer les informations importantes d'être perdue qui sont nécessaires pour déterminer l'origine du problème.

Informations connexes

• Assistance produit pour les routeurs Cisco
• Dépannez et des alertes : Routeurs de la gamme Cisco 7500
• Support et documentation techniques - Cisco Systems