De betekenis van VIP CPU’s bij 99% en RX-Side Buffering

Inleiding

Dit document legt uit waarom de VIP-CPU (Versatile Interface Processor) met 99% draait en wat RX-zijbuffers zijn.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

Rx-zijbuffering is het proces dat optreedt wanneer de uitgaande interface:

• is verstopt.

• gebruikt de wachtstrategie First in, First Out (FIFO).

De inkomende veelzijdige interfaceprocessor (VIP) laat het pakket niet onmiddellijk vallen. In plaats daarvan buffert het pakket in het pakketgeheugen totdat de buffers beschikbaar zijn voor de vertrekkende interface. Gebaseerd op het type VIP, kan het pakketgeheugen Static RAM (SRAM) of Synchronous Dynamic RAM (SDRAM) zijn.

Cisco 7500 Series architectuurbasisproducten

Elke interfaceprocessor (bestaande IP of VIP) heeft één verbinding met een snelle uitgebreide systeembus, genaamd CyBus. Route-/switchprocessors (RSP’s) zijn verbonden met twee CyBuses (zie afbeelding 1).

Afbeelding 1 - Cisco 7500 Series architectuur

Typen pakketbuffers

In deze sectie worden de verschillende soorten pakketbuffers beschreven.

• Systeembuffers in processorgeheugen op RSP

  Deze buffers worden gebruikt voor procesgeschakelde pakketten. U kunt deze buffers zien in de uitvoer van de show interfaces (input- en uitvoerwachtrijen) en de opdrachten van de buffers tonen. Een Cisco 7500 Series router moet niet veel proces-switching doen. Als u problemen heeft met de systeembuffers betekent dit dat er te veel pakketten naar het procesniveau worden verzonden. Dit kan te wijten zijn aan vele factoren, zoals:

  • Een uitzending-storm

  • Installeer in het netwerk dat routingupdates veroorzaakt

  • Een aanval van "denial of service" (DoS)

  • Een optie die niet wordt ondersteund in het snelswitching pad (bijvoorbeeld X.25)

  • IP-pakketten met opties.

  Raadpleeg deze documenten voor informatie over het overzetten van procedures bij problemen oplossen:

  • Gebruik van hoge CPU’s voor probleemoplossing op Cisco-routers

  • Stapels voor probleemoplossing in invoerwachtrij en uitloop

• Packet memory op RSP (MEMD) buffers

  De grootte van de MEMD is vastgesteld op 2 MB op de RSP7000, RSP1, RSP2 en RSP4. Op de RSP8 en RSP16 is de grootte van de MEMD 8 MB. De MEMD wordt over alle interfaces verdeeld op het moment van start, wanneer er een online invoeging en verwijdering (OIR), een microcodeherlading, een maximale transmissieeenheid (MTU) of een buscomplex is. Raadpleeg voor meer informatie over buscomplex Wat veroorzaakt een "%RSP-3-RESTART: buscomplex"?. U kunt de controllers gebruiken om de status van MEMD-buffers te controleren.

  Bij de toewijzing van MEMD worden deze structuren gecreëerd:

  • Een lokale vrije rij (links) wordt aan elke interface toegewezen en wordt gebruikt voor pakketten die op deze interface worden ontvangen.

  • Een mondiale vrije rij (gfreeq) - het wordt ook toegewezen, en een interface kan binnen bepaalde grenzen naar die rij terugvallen.

  • Een rij (wachtrij of xq) verzenden - het wordt aan elke interface toegewezen en wordt gebruikt voor pakketten die door deze interface worden verzonden.

  • De transferaccumulator (txacc)—deze vertegenwoordigt het aantal elementen op de output interface verzenden wachtrij (extra wachtrij). Als de transferaccumulator (txacc) gelijk is aan de verzendlimiet (txlimit), worden alle buffers bevrijd. Als de txacc 0 is, is de rij vol, en er is geen rij meer toegestaan.

• Packet-geheugen

  Op een VIP bevat het pakketgeheugen pakketbuffers (deeltjes) die gebruikt worden voor pakketten die van of naar een VIP interface worden verzonden. Afbeelding 2 vertegenwoordigt pakketstroom.

  Afbeelding 2 - Packet Flow

  

  Deze sectie richt zich op een VIP waar gedistribueerde switching is ingeschakeld, omdat RX-side buffering meestal optreedt wanneer een pakje dit type switching pad volgt. Er zijn verschillende scenario's mogelijk, zoals hier wordt uitgelegd:

  Scenario 1: Wanneer er geen congestie is op de uitgaande interface.

  • Een pakket wordt ontvangen op een poortadapter (PA) en verplaatst naar een pakketbuffer in het pakketgeheugen.

  • Als VIP het pakket niet kan distribueren-schakelen, zendt het pakket naar de RSP door, die de switching-beslissing neemt.

  • Als de VIP de switching beslissing kan nemen en de uitgaande interface op dezelfde VIP is, wordt het pakket op de uitgaande interface verzonden. Het pakket wordt "lokaal geschakeld" op de VIP, omdat het niet de bus oversteekt.

  • Als de VIP de switching beslissing kan nemen en de uitgaande interface in een andere sleuf is, probeert de VIP het pakket via de bus te kopiëren in de wachtrij van de uitgaande interface.

  • Het pakket wordt vervolgens gekopieerd naar de uitgaande (V)IP-telefoon over de bus en op de lijn verzonden.

  Scenario 2: Wanneer de uitgaande interface is geblokkeerd.

  Er zijn twee mogelijkheden:

  • Als de wachtrij op de uitgaande interface wordt ingesteld, wordt het IP-pakket naar de wachtrij in de MEMD overgebracht, en wordt het pakket direct uit de wachtrij getrokken door de wachtcode.

    • Als op RSP gebaseerde wachtrij is ingesteld, wordt het pakket gekopieerd naar de systeembuffers in het processorgeheugen op RSP.

    • Als de op VIP gebaseerde wachtrij wordt gebruikt, wordt het pakket gekopieerd naar het pakketgeheugen van de uitgaande VIP.

  • Als de wachtstrategie van de uitgaande interface FIFO is, laat de interface het pakket niet direct vallen (dit is wat normaal met FIFO gebeurt wanneer een uitgaande interface wordt geblokkeerd). In plaats daarvan buffert de inkomende VIP het pakket in zijn pakketgeheugen tot sommige buffers opnieuw beschikbaar zijn voor de uitgaande interface. Dit heet RX-side buffering.

Gebruik de opdracht showcontrollers-apparatuur om de status van Rx-zijbuffering te controleren. De status geeft aan:

• Het aantal uitvoerinterfaces dat in de router aanwezig is.

• Hoeveel pakketten heeft de VIP RX-buffered voor deze interfaces.

• Waarom de VIP RX-gebufferd heeft.

• Hoeveel pakketten de VIP liet vallen, en waarom.

VIP wordt uitgevoerd op 99% CPU-gebruik

Een gevolg van Rx-side buffering is dat de VIP bij 99% CPU-gebruik draait. De VIP controleert voortdurend de status van de extra wachtrij van de uitgaande interface en, zodra er een vrije buffer is, kopieert deze de pakketjes via de bus in de wachtrij.

Er is op zichzelf niets alarmerend als de VIP 99% bedraagt als Rx-buffering optreedt. Dit betekent niet dat de VIP is overbelast. Als de VIP iets belangrijkers te doen krijgt (bijvoorbeeld een ander pakket om te schakelen), wordt dit niet beïnvloed door de hoge CPU.

Hier is een simpele test die je in het lab kunt doen om dit te illustreren:

Seriële 2/0/0 heeft een kloksnelheid van 128 Kbps en ontvangt verkeer met lijnsnelheid. Het verkeer is overgeschakeld op Serial 10/0 waar de kloksnelheid 64 Kbps is, en de wachtstrategie is FIFO. De enige optie is pakketten te laten vallen.

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# 

De waarde 2 betekent dat er slechts twee buffers over zijn. Rx-buffering vormt geen wachtrij voor pakketten in de MEMD wanneer de belasting minder dan 4 bedraagt.

De opdracht Show controllers vip 2 tech-support van de VIP laat zien dat deze op 99% CPU's draait:

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% 

De VIP draait op 99% CPU-gebruik, ook al wordt er slechts 128 Kbps gebruikt. Dit toont aan dat het gebruik van CPU niet aan het aantal pakketten per seconde is gekoppeld. Dit komt doordat een VIP 2 in staat is om veel meer pakketten in te schakelen dan dit. Het is gewoon een teken van Rx-zijbuffering.

Om te controleren wat Rx-zijbuffering doet, voert u deze opdrachten uit:

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

Sleutel	Beschrijving
a	Adres van de technische dienst in MEMD. Er is één RX-side bufferrij voor elke txacc in het systeem (tot 4096).
b	Aantal pakketten die Rx-gebufferd zijn.
c	Aantal pakketten die de VIP heeft laten vallen. Als er genoeg pakketgeheugenbuffers zijn, kan VIP tot één seconde van het verkeer RX-buffer bevatten. Als de interface echter continu wordt verstopt, is het niet mogelijk om druppels te vermijden.
d	Aantal pakketten die momenteel RX-buffered zijn.
e	Aantal deeltjes die momenteel Rx-gebufferd zijn. Een pakje kan van meerdere deeltjes bestaan.
f	Zachte limiet, dit is het maximale aantal deeltjes bij een laag VIP-geheugen.
g	Harde limiet, dat is het maximale aantal deeltjes dat op ieder moment kan worden gebruikt.
h	De snelheid van de uitgaande interface in kbps.
i	Het aantal RX-gebufferde pakketten omdat er geen txacc beschikbaar was in de MEMD. Dit betekent dat de uitvoerwachtrij was geblokkeerd (er zijn geen vrije buffers meer beschikbaar in de wachtrij). De oplossing voor dit probleem is om de bandbreedte van de uitvoerinterface te verhogen (indien mogelijk).
j	Het aantal pakketten met een IP-voorrang anders dan 6 of 7 die niet verzonden konden worden omdat er geen MEMD-acc is, en worden verzonden omdat de zachte of harde limiet van de deeltjes is bereikt.
k	Dit is hetzelfde als j, maar voor pakketten met IP voorrang 6 of 7 (internetwork en netwerk).
l	Het aantal pakketten met een andere IP voorrang dan 6 of 7 die de VIP aan RX-buffer wil verbinden, maar daalt wegens een gebrek aan vrije buffers in het pakketgeheugen. Vanaf Cisco IOS-softwarereleases 12.0(13)S en 12.1(4) kunt u de opdracht Show Controller ook gebruiken [all / sleuf#] pakketgeheugen-drops om het aantal pakketten te zien laten vallen. In dit geval helpt een upgrade van het pakketgeheugen.
m	Dit is hetzelfde als l, maar voor pakketten met IP voorrang 6 of 7 (internetwork en netwerk).
n	Het aantal pakketten dat de VIP probeert te verbinden met RX-buffer omdat er geen MEMD-buffer is, maar dit kan niet door een gebrek aan pakketgeheugenbuffers. upgrade het pakketgeheugen in dit geval. Vanaf Cisco IOS-softwarereleases 12.0(13)S en 12.1(4) kunt u de opdracht all/sleuf#] pakketgeheugen-drops ook gebruiken om te begrijpen waarom de pakketten zijn gevallen.
o	Het aantal Rx-gebufferde pakketten met een IP-voorrang anders dan 6 of 7 zonder MEMD-buffer die zijn gevallen omdat de zachte (f) of harde (g) limiet is bereikt. In deze situatie helpt een RSP16 omdat het meer media-geheugen heeft (8 MB vergeleken met 2 MB voor de RSP1, RSP2, RSP4 en RSP7000). U kunt ook de MTU van bepaalde interfaces beperken (zoals ATM, POS of FDDI). Deze interfaces hebben doorgaans een MTU van 4470 bytes en er kunnen minder MMD-buffers worden toegewezen omdat de buffers groter moeten zijn.
p	Dit is hetzelfde als Opslaan, maar voor pakketten met IP-voorrang 6 of 7 (internetwerk en netwerk).
q	Het aantal pakketten met een IP voorrang anders dan 6 of 7 die VIP probeert te RX-buffer omdat er geen MEMD-buffer is, maar kan dit niet doen door een gebrek aan pakketgeheugenbuffers. Een upgrade van het pakketgeheugen helpt in dit geval. Vanaf Cisco IOS-softwarereleases 12.0(13)S en 12.1(4) kunt u ook de opdracht all / sleuf#] pakketgeheugen-drops gebruiken om beter te begrijpen waarom de pakketten zijn gevallen.
r	Dit is hetzelfde als q, maar voor pakketten met IP voorrang 6 of 7 (internetwork en netwerk).

Als de router een Cisco IOS-softwarerelease eerder dan 12.0(13)ST, 12.1(04)DB, 12.1(04)DC, 12.0(13)S, 12.1(4)A 12.1(4)T 012.0(13) draait, of 12.0(13)SC levert de uitvoer van tooncontrollers vip [all / sleuf#]-accu een vereenvoudigde versie van het bovenstaande. Er wordt geen rekening gehouden met de verschillende IP-voorrang van de geworpen pakketten vanwege RX-side-buffering.

De output ziet er zo uit:

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 

Voorbeelden van buffers op Rx-zijde

Voorbeeld 1: De VIP in sleuf 2 ontvangt verkeer op een 128 Kbps en routeert het naar seriële 10/0 (64 Kbps).

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 

• Hier worden 544980 pakketten met succes met een RX-bufferoplossing geconverteerd en 2644182 gevallen. 80 pakketten van de 264182 die worden gedropt, hadden een IP-voorrang van 6 of 7.

• 126 pakketten zijn momenteel Rx-gebufferd en zij gebruiken 378 deeltjes.

• Alle pakketten worden RX-gebufferd door een gebrek aan vrije buffer in de belastingwachtrij in de MEMD. Dit betekent dat de uitvoerinterface verstopt is. De druppels treden op omdat het maximale aantal Rx-gebufferde pakketten wordt bereikt. De typische oplossing is om de uitgaande interfacebandbreedte te verbeteren, wat verkeer opnieuw te routeren zodat de uitgaande interface minder verstopt is, of wat een wachtrij toe te laten om het minder belangrijke verkeer te laten vallen.

Voorbeeld 2: RX-side Buffers zonder druppels.

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 

• In dit voorbeeld worden 85709 pakketten RX-buffered omdat ATM 1/0 wordt geblokkeerd maar geen pakketten worden gedropt.

• 17795 pakketten worden RX-buffered omdat de VIP geen MEMD-buffer kan krijgen. Er worden geen pakketten verzonden. Een typische oplossing is het verlagen van een aantal MTU's, zodat meer MKZ-buffers kunnen worden toegewezen. Een RSP8 helpt ook.

Voorbeeld 3: Local Switching.

SRP0/0/0: 

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

Lokale tekst betekent dat deze uitvoerinterface op dezelfde VIP staat als de interface waar de pakketten worden ontvangen. Deze pakketten zijn lokaal geschakeld, maar de uitgaande interface (in dit geval, srp 0/0/0) is verstopt. 2529 pakketten worden RX-gebufferd en er worden geen pakketten verzonden.

Voorbeeld 4: Wachtrijen voorwaarts.

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

Sommige pakketten kunnen niet worden gedistribueerd. In dit geval moet VIP de pakketten naar de ruwe rij van RSP doorsturen, die dan het overschakelingsbesluit neemt. Wanneer pakketten niet onmiddellijk kunnen worden gekopieerd naar een MEMD, buffert de VIP RX-buffers ze en houdt u bij hoeveel pakketten RX-gebufferd per inkomende interface zijn.

Doorsturen wachtrijen 0-7 zijn voor de eerste poortadapter (PA) en 8-15 voor de tweede PA.

Wachtrij doorsturen	...toont het aantal RX-gebufferde pakketten die op de... worden ontvangen.
0	eerste gat van de eerste poortadapter (PA)
8	eerste gat van de tweede PA
9	tweede gat van de tweede PA

Andere oorzaken van het gebruik van hoge CPU’s op VIP’s

Wanneer een Rx-zijbuffering inactief blijkt te zijn, kan een van deze factoren een hoog CPU-gebruik op VIP veroorzaken:

• 99% CPU-gebruik op VIP, veroorzaakt door gedistribueerde traffic shaping

  Wanneer Distributed Traffic Shaping (dTS) is geconfigureerd, springt de VIP CPU naar 99% zodra een pakket in de dTS-wachtrij komt.

  Dit is het juiste en verwachte gedrag. Wanneer dTS is geconfigureerd, centrifugeert VIP CPU’s om te controleren of het volgende interval (Tc) arriveert wanneer de CPU niet bezig is (dat wil zeggen, wanneer er geen verkeer is). Anders is de verificatie verstopt in de stks/rx-interrupte routines. U centrifugeert de CPU alleen wanneer deze niet bezig is. Daarom wordt de prestatie niet beïnvloed.

  Om te begrijpen wat het "volgende interval" betekent, zie Wat een Token Bucket is?

  Opmerking: Traffic Shaping wordt alleen actief wanneer u een pakje in de vormende rij moet opgeven. Met andere woorden, wanneer de hoeveelheid verkeer de vormsnelheid overschrijdt. Dit verklaart waarom de VIP CPU niet altijd 99% is wanneer dTS wordt geconfigureerd. Zie voor meer informatie over dTS:

  • Gedistribueerde traffic shaping

  • Gedistribueerde traffic shaping configureren

• Gebruik van hoge CPU’s op VIP veroorzaakt door onheilspellende geheugentoegang en uitlijtingsfouten

  Uitlijning fouten en foutieve geheugentoegang zijn softwarefouten die door de Cisco IOS-software zijn gecorrigeerd zonder dat u het VIP hoeft te crashen. Als deze fouten vaak verschijnen, veroorzaakt het dat het besturingssysteem veel correcties uitvoert die kunnen leiden tot een hoog CPU-gebruik.

  Zie Problemen oplossen bij kennelijke toegangsfouten en foutieve onderbrekingen voor meer informatie over uitlijning van fouten en foutieve geheugentoegang.

  Om te controleren op onheilspellende geheugentoegangen en uitlijning fouten, gebruik de opdracht uitlijning tonen. Een voorbeeld van zo'n fout ziet er zo uit:

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

Andere oorzaken van een hoog CPU-gebruik kunnen de hoeveelheid en de omvang van gedistribueerde functies zijn die worden ingeschakeld. Als u vermoedt dat dit de reden kan zijn, of als u geen van de oorzaken voor gebruik van hoge CPU’s kunt identificeren die in dit document worden toegelicht, opent u een serviceaanvraag bij het Cisco Technical Assistance Center (TAC).

Te verzamelen informatie als u een TAC-serviceaanvraag opent

Als u nog steeds assistentie nodig hebt nadat u de bovenstaande stappen voor het oplossen van problemen hebt gevolgd en een serviceaanvraag wilt openen (alleen geregistreerde klanten) bij de Cisco TAC, zorg er dan voor dat u deze informatie bevat:

Uitvoer van de show controllers vip [all / sleuf#] accu-opdracht Uitvoer uit de opdracht Technische ondersteuning van de desbetreffende RSP- en VIP-indeling Voeg de verzamelde gegevens in niet-zipped, onbewerkte tekstindeling (.txt) aan uw servicecontract toe. Om informatie aan uw servicetoepassing toe te voegen, kunt u deze uploaden via het TAC Service Application Tool (alleen geregistreerde klanten). Als u geen toegang hebt tot het servicetoepassingsprogramma, kunt u de relevante informatie aan uw serviceaanvraag toevoegen en naar attach@cisco.com sturen met uw servicetoepassingsnummer in de onderwerpregel of in uw bericht. N.B.: Laad de router niet handmatig of stroomcyclus voordat u de bovenstaande informatie verzamelt (tenzij dit nodig is om de netwerkwerking te herstellen), omdat dit belangrijke informatie kan veroorzaken om verloren te gaan die nodig is om de oorzaak van het probleem te bepalen.

Gerelateerde informatie

• Productondersteuning voor Cisco Routers
• Probleemoplossing en meldingen: Cisco 7500 Series routers
• Technische ondersteuning en documentatie – Cisco Systems