Informazioni sulla CPU VIP in esecuzione al 99% e sul buffer lato Rx
Sommario
Introduzione
Questo documento spiega perché la CPU Versatile Interface Processor (VIP) è in esecuzione al 99% e quali sono i buffer lato Rx.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Premesse
Il buffering sul lato Rx è il processo che si verifica quando l'interfaccia in uscita:
-
è congestionato.
-
utilizza la strategia di accodamento FIFO (First in, First out).
Il VIP (Versatile Interface Processor) in entrata non rifiuta il pacchetto immediatamente. Al contrario, memorizza il pacchetto nella sua memoria finché non sono disponibili buffer per l'interfaccia in uscita. A seconda del tipo di VIP, la memoria del pacchetto può essere la RAM statica (SRAM) o la RAM dinamica sincrona (SDRAM).
Nozioni fondamentali sull'architettura Cisco serie 7500
Ogni processore di interfaccia (IP o VIP legacy) dispone di una connessione a un bus di sistema esteso ad alta velocità chiamato CyBus. I processori Route/Switch (RSP) sono collegati a due CyBus (vedere la Figura 1).
Figura 1 - Architettura Cisco serie 7500 
Tipi di buffer di pacchetto
In questa sezione vengono descritti i vari tipi di buffer di pacchetto.
-
Buffer di sistema nella memoria del processore sull'RSP
Questi buffer vengono utilizzati per i pacchetti a commutazione di contesto. È possibile visualizzare questi buffer nell'output del comando show interfaces (code di input e output) e show buffer. Un router Cisco serie 7500 non deve eseguire molta commutazione di contesto. Pertanto, se si verificano problemi con i buffer di sistema, significa che troppi pacchetti vengono inviati a livello di processo. Ciò può essere dovuto a molti fattori, quali:
-
Una tempesta broadcast
-
Instabilità della rete che causa gli aggiornamenti del routing
-
Un attacco "Denial of Service" (DoS)
-
Funzione non supportata nel percorso di commutazione veloce (ad esempio, X.25)
-
Pacchetti IP con opzioni.
Per informazioni su come risolvere i problemi di commutazione di processo eccessiva, fare riferimento a questi documenti:
-
-
Memoria pacchetto su buffer RSP (MEMD)
Le dimensioni MEMD sono fissate a 2 MB su RSP7000, RSP1, RSP2 e RSP4. Su RSP8 e RSP16, le dimensioni MEMD sono di 8 MB. Il protocollo MEMD viene distribuito tra tutte le interfacce al momento dell'avvio, in caso di inserimento e rimozione online (OIR), ricaricamento del microcodice, modifica della MTU (Maximum Transmission Unit) o un complesso bus. Per ulteriori informazioni su cbus complex, vedere Cause di un "%RSP-3-RESTART: cbus complex"?. È possibile utilizzare il comando show controller bus per controllare lo stato dei buffer MEMD.
Quando viene allocato MEMD, vengono create le seguenti strutture:
-
A local free queue (lfreeq): viene assegnata a ciascuna interfaccia e utilizzata per i pacchetti ricevuti su questa interfaccia.
-
Una coda libera globale (gfreeq): viene anche allocata e un'interfaccia può eseguire il fallback a tale coda entro alcuni limiti.
-
Una coda di trasmissione (txqueue o txq): viene assegnata a ciascuna interfaccia e viene utilizzata per i pacchetti in uscita tramite questa interfaccia.
-
L'accumulatore trasmissione (txacc) - Rappresenta il numero di elementi nella coda di trasmissione dell'interfaccia di output (txqueue). Quando l'accumulatore di trasmissione (txacc) è uguale al limite di trasmissione (txlimit), tutti i buffer vengono liberati. Quando il valore di txacc è 0, la coda è piena e non è più consentita la coda.
-
-
Memoria pacchetto
In un VIP, la memoria del pacchetto contiene i buffer (particelle) utilizzati per i pacchetti ricevuti o inviati a un'interfaccia VIP. La Figura 2 rappresenta il flusso del pacchetto.
Figura 2 - Flusso del pacchetto
Questa sezione è incentrata su un VIP dove è abilitata la commutazione distribuita, perché il buffering sul lato Rx si verifica in genere quando un pacchetto segue questo tipo di percorso di commutazione. Sono possibili diversi scenari, descritti di seguito:
Scenario 1: Quando non vi è congestione sull'interfaccia in uscita.
-
Un pacchetto viene ricevuto su un adattatore di porta (PA) e spostato in un buffer di pacchetto nella memoria del pacchetto.
-
Se il VIP non può distribuire il pacchetto-switch, lo inoltra all'RSP, che decide in merito.
-
Se il VIP può prendere la decisione di commutazione e l'interfaccia in uscita si trova sullo stesso VIP, il pacchetto viene inviato sull'interfaccia in uscita. Si dice che il pacchetto sia "commutato localmente" sul VIP, perché non attraversa il bus.
-
Se il VIP può prendere la decisione di commutazione e l'interfaccia in uscita si trova in un altro slot, il VIP cerca di copiare il pacchetto sul bus nella coda di testo (in MEMD) dell'interfaccia in uscita.
-
Il pacchetto viene quindi copiato sull'indirizzo IP (V) in uscita sul bus e inviato sulla linea.
Scenario 2: Quando l'interfaccia in uscita è congestionata.
Esistono due possibilità:
-
Se l'accodamento è configurato sull'interfaccia in uscita, il VIP trasferisce il pacchetto nella coda di testo in MEMD e il pacchetto viene estratto immediatamente dalla coda dal codice di accodamento.
-
Se è stata configurata la coda basata su RSP, il pacchetto viene copiato nei buffer di sistema della memoria del processore sull'RSP.
-
Se si utilizza una coda basata su VIP, il pacchetto viene copiato nella memoria del pacchetto del VIP in uscita.
-
-
Se la strategia di coda dell'interfaccia in uscita è FIFO, l'interfaccia non scarta il pacchetto immediatamente (questo è ciò che normalmente accade con FIFO quando un'interfaccia in uscita è congestionata). Il VIP in ingresso memorizza il pacchetto nella sua memoria finché alcuni buffer non sono di nuovo disponibili per l'interfaccia in uscita. Questo processo è denominato buffering lato Rx.
-
Usare il comando show controller vip accumulator per controllare lo stato del buffering sul lato Rx. Lo stato indica:
-
Numero di interfacce di output presenti nel router.
-
Numero di pacchetti nel buffer RX del VIP per queste interfacce.
-
Perché il VIP ha il buffer Rx.
-
Quanti pacchetti sono stati scartati dal VIP e perché.
Utilizzo CPU al 99% da parte di VIP
Una conseguenza del buffering lato Rx è che il VIP viene eseguito al 99% dell'utilizzo della CPU. Il VIP controlla continuamente lo stato della coda di testo dell'interfaccia in uscita e, non appena c'è un buffer libero, copia il pacchetto sul bus nella coda di testo.
Non c'è nulla di allarmante in sé quando il VIP corre al 99% quando si verifica il buffering Rx. Non significa che il VIP sia sovraccarico. Se il VIP riceve qualcosa di più importante da fare (ad esempio, un altro pacchetto da cambiare), ciò non è influenzato dal livello elevato della CPU.
Di seguito è riportato un semplice test che è possibile eseguire in laboratorio per illustrare questo aspetto:
Serial 2/0/0 ha una velocità di clock di 128 Kbps e riceve il traffico alla velocità della linea. Il traffico viene commutato su Serial 10/0 dove la velocità di clock è 64 Kbps e la strategia di coda è FIFO. L'unica opzione è quella di scartare i pacchetti.
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#
Il valore 2 indica che sono rimasti solo due buffer. La funzione Rx-buffering non mette in coda i pacchetti in MEMD quando il valore txacc è inferiore a 4.
Il comando show controllers vip 2 tech-support inviato dall'indirizzo VIP mostra che l'esecuzione avviene al 99% della CPU:
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%
Il VIP viene eseguito al 99% dell'utilizzo della CPU anche se riceve solo 128 Kbps. Ciò indica che l'utilizzo della CPU non è collegato al numero di pacchetti al secondo. Ciò è dovuto al fatto che un VIP 2 è in grado di scambiare molti più pacchetti di questo. Si tratta semplicemente di un segno di buffering lato Rx.
Per verificare la funzione Rx-side buffering, eseguire i seguenti comandi:
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
| Chiave | Descrizione |
|---|---|
| a | Indirizzo della fattura in MEMD. È disponibile una coda buffer lato Rx per ogni testo nel sistema (fino a 4096). |
| b | Numero di pacchetti con buffer Rx. |
| c | Numero di pacchetti ignorati dal VIP. Se i buffer di memoria del pacchetto sono sufficienti, il VIP può inviare un buffer Rx fino a un secondo di traffico. Tuttavia, se l'interfaccia è continuamente congestionata, non è possibile evitare le cadute. |
| d | Numero di pacchetti attualmente memorizzati nel buffer Rx. |
| s | Numero di particelle attualmente con buffer Rx. Un pacchetto può essere composto da più particelle. |
| f | Limite soft, che è il numero massimo di particelle quando la memoria VIP è bassa. |
| g | Limite rigido, che è il numero massimo di particelle che possono essere utilizzate in qualsiasi momento. |
| h | Velocità dell'interfaccia in uscita in kbps. |
| i | Numero di pacchetti con buffer Rx perché in MEMD non era disponibile alcun testo. Ciò significa che la coda di output era congestionata (non sono più disponibili buffer liberi nella coda tx). Per risolvere questo problema, aumentare la larghezza di banda dell'interfaccia di output (se possibile). |
| j | Numero di pacchetti con precedenza IP diversa da 6 o 7 che non è stato possibile inviare perché non esiste un ACC MEMD e che vengono scartati perché è stato raggiunto il limite soft o hard delle particelle. |
| k | Uguale a j, ma per pacchetti con IP precedence 6 o 7 (internetwork e rete). |
| l | Numero di pacchetti con precedenza IP diversa da 6 o 7 che il VIP desidera ricevere il buffer Rx, ma che vengono scartati a causa della mancanza di buffer liberi nella memoria del pacchetto. Dal software Cisco IOS versione 12.0(13)S e 12.1(4) in avanti, è possibile anche usare il comando show controller vip [all / slot#] packet-memory-drops per verificare il numero di pacchetti scartati. In questo caso, è utile aggiornare la memoria del pacchetto. |
| m | Uguale a l, ma per pacchetti con IP precedence 6 o 7 (internetwork e network). |
| n | Numero di pacchetti che il VIP tenta di inviare al buffer Rx perché non è disponibile un buffer MEMD. Impossibile eseguire l'operazione a causa della mancanza di buffer di memoria dei pacchetti. In questo caso, aggiornare la memoria del pacchetto. Dal software Cisco IOS versione 12.0(13)S e 12.1(4) in avanti, è possibile usare il comando show controller vip [all / slot#] packet-memory-drops per capire perché i pacchetti sono stati scartati. |
| o | Numero di pacchetti con buffer Rx con precedenza IP diversa da 6 o 7 e senza buffer MEMD che vengono scartati perché è stato raggiunto il limite soft (f) o hard (g). In questo caso, un RSP16 è utile perché dispone di una maggiore quantità di memoria MEMD (8 MB rispetto ai 2 MB di RSP1, RSP2, RSP4 e RSP7000). In questo caso, è possibile anche ridurre l'MTU di alcune interfacce (ad esempio ATM, POS o FDDI). Queste interfacce hanno generalmente una MTU di 4470 byte e possono essere allocati meno buffer MEMD perché i buffer devono essere più grandi. |
| p | Uguale a o, ma per pacchetti con IP precedence 6 o 7 (internetwork e rete). |
| d | Numero di pacchetti con precedenza IP diversa da 6 o 7 che il VIP tenta di reindirizzare al buffer perché non è disponibile un buffer MEMD, ma questa operazione non è possibile a causa della mancanza di buffer di memoria del pacchetto. In questo caso, è utile aggiornare la memoria del pacchetto. Dal software Cisco IOS versione 12.0(13)S e 12.1(4) in avanti, è possibile usare il comando show controller vip [all / slot#] packet-memory-drops per capire meglio il motivo per cui i pacchetti sono stati scartati. |
| r | Uguale a q, ma per pacchetti con IP precedence 6 o 7 (internetwork e rete). |
Se il router esegue una versione del software Cisco IOS precedente all'accumulatore 12.0(13)ST, 12.1(04)DB, 12.1(04)DC, 12.0(13)S, 12.1(4)AA 12.1(4)T 012.0(13) o 12.0(13)SC, l'output dell'accumulatore show controller vip [all / slot#] fornisce una versione semplificata di quanto sopra. Non tiene conto delle diverse precedenza IP dei pacchetti scartati a causa del buffering sul lato Rx.
L'output sarà simile al seguente:
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
Esempi di buffer sul lato Rx
Esempio 1: Il VIP nello slot 2 riceve il traffico su un 128Kbps e lo instrada al seriale 10/0 (64Kbps).
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
-
In questo caso, i pacchetti 544980 vengono memorizzati nel buffer Rx e gli indirizzi 2644182 vengono scartati. Su 2644182, 80 pacchetti non elaborati avevano una precedenza IP di 6 o 7.
-
126 pacchetti sono attualmente memorizzati nel buffer Rx e usano 378 particelle.
-
Tutti i pacchetti vengono memorizzati nel buffer Rx a causa della mancanza di buffer libero nella coda tx in MEMD. Ciò significa che l'interfaccia di output è congestionata. Le riduzioni si verificano perché è stato raggiunto il numero massimo di pacchetti nel buffer Rx. La soluzione tipica è aggiornare la larghezza di banda dell'interfaccia in uscita, instradare di nuovo del traffico in modo che l'interfaccia in uscita sia meno congestionata o consentire ad alcune code di eliminare il traffico meno importante.
Esempio 2: Buffer lato Rx senza drop.
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
-
Nell'esempio, i pacchetti 85709 vengono memorizzati nel buffer Rx perché ATM 1/0 è congestionato e non viene scartato alcun pacchetto.
-
I pacchetti 17795 sono memorizzati nel buffer Rx perché l'indirizzo VIP non può ottenere un buffer MEMD. Nessun pacchetto scartato. Una soluzione tipica consiste nel ridurre alcune MTU in modo da poter allocare più buffer MEMD. Anche un RSP8 aiuta.
Esempio 3: Switching locale.
SRP0/0/0: local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps
Il termine txacc locale indica che l'interfaccia di output si trova sullo stesso VIP dell'interfaccia su cui vengono ricevuti i pacchetti. Questi pacchetti vengono commutati localmente, ma l'interfaccia in uscita (in questo caso, srp 0/0/0 ) è congestionata. I pacchetti 2529 vengono memorizzati nel buffer Rx e non vengono scartati.
Esempio 4: Code di inoltro.
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
Alcuni pacchetti non possono essere a commutazione di distribuzione. In questo caso, il VIP deve inoltrare i pacchetti alla coda raw dell'RSP, che a sua volta decide la commutazione. Quando i pacchetti non possono essere copiati immediatamente in MEMD, il VIP Rx li memorizza nel buffer e tiene traccia di quanti pacchetti vengono memorizzati nel buffer Rx per ogni interfaccia in entrata.
Le code di inoltro da 0 a 7 si riferiscono alla prima scheda di porta (PA) e da 8 a 15 alla seconda PA.
| Numero coda di inoltro | ...mostra il numero di pacchetti con buffer Rx ricevuti su... |
|---|---|
| 0 | primo riduttore del primo adattatore di porta (PA) |
| 8 | primo colpo del secondo PA |
| 9 | secondo colpo della seconda PA |
Altre cause di un elevato utilizzo della CPU nei VIP
Quando il buffer lato Rx è inattivo, uno di questi fattori può causare un elevato utilizzo della CPU nell'indirizzo VIP:
-
99% di utilizzo della CPU in VIP, causato da Traffic Shaping distribuito
Quando viene configurato il Traffic Shaping (dTS) distribuito, la CPU VIP passa al 99% non appena un pacchetto entra nella coda dTS.
Si tratta del comportamento corretto e previsto. Quando dTS è configurato, la CPU VIP effettua una rotazione per verificare se l'intervallo di tempo successivo (Tc) arriva quando la CPU non è occupata, ovvero quando non c'è traffico. In caso contrario, la verifica viene eseguita con il piggyback nelle routine di interrupt tx/rx. La CPU viene ruotata solo quando non è occupata. Ciò non influisce sulle prestazioni.
Per informazioni sul significato di "intervallo di tempo successivo", vedere Che cos'è un token bucket?
Nota: il Traffic Shaping diventa attivo solo quando deve accodare un pacchetto nella coda di shaping. In altre parole, quando la quantità di traffico supera la velocità di shaping. Questo spiega perché la CPU VIP non è sempre al 99% quando è configurato dTS. Per ulteriori informazioni su dTS, vedere:
-
Utilizzo elevato della CPU nel VIP causato da accessi di memoria spurie ed errori di allineamento
Gli errori di allineamento e gli accessi alla memoria spurie sono errori software che vengono corretti dal software Cisco IOS senza che sia necessario arrestare il VIP. Se questi errori compaiono frequentemente, il sistema operativo apporta molte correzioni che possono portare a un elevato utilizzo della CPU.
Per ulteriori informazioni sugli errori di allineamento e sugli accessi alla memoria spurie, vedere Risoluzione dei problemi relativi agli accessi spuri, agli errori di allineamento e agli interrupt spuri.
Per verificare la presenza di accessi alla memoria spurie ed errori di allineamento, usare il comando show alignment. Di seguito è riportato un esempio di errore:
VIP-Slot1#show alignment No alignment data has been recorded. No spurious memory references have been recorded.
Altre cause dell'elevato utilizzo della CPU possono essere la quantità e l'estensione delle funzionalità distribuite abilitate. Se si ritiene che questa possa essere la causa, o se non è possibile identificare alcuna delle cause di un elevato utilizzo della CPU spiegate in questo documento, aprire una richiesta di assistenza in Cisco Technical Assistance Center (TAC).
Informazioni da raccogliere se si apre una richiesta di servizio TAC
| Se dopo aver seguito le procedure di risoluzione dei problemi descritte sopra si desidera aprire una richiesta di assistenza (solo utenti registrati) con Cisco TAC, includere le seguenti informazioni: |
|---|
Nota: non ricaricare o spegnere e riaccendere manualmente il router prima di aver raccolto le informazioni sopra indicate (a meno che non siano necessarie per ripristinare il funzionamento della rete), in quanto ciò potrebbe causare la perdita di informazioni importanti necessarie per determinare la causa principale del problema. |
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
07-Jul-2005 |
Versione iniziale |
Feedback