Sommario

Introduzione

Prerequisito

Requisiti

Descrizione

Procedura di risoluzione dei problemi

Fase 1 - Identificazione del modulo con CPU elevata

Fase 2 - Analisi del modulo

Fase 3 - Processi IOS

Fase 4 - Processi Linux

Fase 5 - Processi FECP

Fase 6 - Utilizzo QFP

Passaggio 7 - Determinare la causa principale e identificare la correzione

Esempio di risoluzione dei problemi

Comandi aggiuntivi

Route Processor

Embedded Services Processor

Introduzione

In questo documento viene descritto come risolvere i problemi relativi alla CPU su un router serie ASR1000.

Prerequisito

Requisiti

Cisco consiglia di comprendere l'architettura ASR1000 per interpretare e utilizzare questo documento.

Descrizione

Per CPU alta su un router Cisco si intende la condizione in cui l'utilizzo della CPU sul router è superiore all'utilizzo normale. In alcuni scenari si prevede un maggiore utilizzo della CPU, mentre in altri potrebbe indicare un problema. È possibile ignorare l'elevato utilizzo temporaneo della CPU sul router a causa di modifiche alla rete o alla configurazione e il comportamento previsto.

Tuttavia, un router che ha un elevato utilizzo della CPU per periodi prolungati senza modifiche alla rete o alla configurazione è insolito e deve essere analizzato. Pertanto, quando viene sovrautilizzato, la CPU non è in grado di servire attivamente tutti gli altri processi, il che si traduce in una riga di comando lenta, in una latenza del control plane, in perdite di pacchetti e in un errore dei servizi.

Le cause dell'utilizzo elevato della CPU sono:

1. La CPU del Control Plane riceve troppo traffico punt

2. Processo che si comporta in modo imprevisto e determina un sovrautilizzo della CPU

3. Il processore Data Plane è sovrautilizzato/sovrascritto

4. Troppi interrupt del processore

L'uso elevato della CPU non è sempre un problema dei router della serie ASR1000 in quanto l'utilizzo della CPU del router è direttamente proporzionale al carico sul router.  Ad esempio, in caso di modifica della rete, il traffico del control plane risulterà molto elevato, in quanto la rete sarà nuovamente convergente. È quindi necessario determinare la causa principale del sovrautilizzo della CPU per determinare se si tratta di un comportamento previsto o di un problema.

Di seguito è riportato un diagramma che illustra un processo dettagliato per la risoluzione di un problema relativo alla CPU:

Procedura di risoluzione dei problemi

Fase 1 - Identificazione del modulo con CPU elevata

ASR1000 ha diverse CPU nei diversi moduli. Pertanto, è necessario individuare il modulo che presenta un utilizzo superiore al normale. Questa condizione può essere rilevata tramite il valore Idle, poiché più basso è il valore idle, maggiore è l'utilizzo della CPU del modulo. Queste CPU diverse riflettono tutte il piano di controllo dei moduli.

Determinare quale modulo all'interno del dispositivo rileva un'elevata CPU. Indica se il parametro è RP, ESP o SIP con il comando seguente

show platform software status control-processor brief

Fare riferimento all'output riportato di seguito per visualizzare la colonna evidenziata

Se il RP ha un valore di inattività basso, procedere al punto 2 1

Se l'ESP ha un valore di inattività basso, procedere al punto 3.2

Se il SIP ha un valore di inattività basso, procedere con il passaggio 4, punto 3

Router#show platform software status control-processor brief

Carico medio

Stato Dello Slot 1-Min 5-Min 15-Min

RP0 Integro 0,00 0,02 0,00

ESP0 Integro 0,01 0,02 0,00

SIP0 Integro 0,00 0,01 0,00

Memoria (KB)

Stato Slot Totale Utilizzato (Pct) Senza Impegno (Pct)

RP0 Integro 2009376 1879196 (94%) 130180 ( 6%) 1432748 (71%)

ESP0 Integro 2009400 692100 (34%) 1317300 (66%) 472536 (24%)

SIP0 Integro 471804 284424 (60%) 187380 (40%) 193148 (41%)

Utilizzo CPU

Slot CPU User System Nice Idle IRQ SIRQ IOwait

RP0 0 2,59 2,49 0,00 94,80 0,00 0,09 0,00

ESP0 0 2,30 17,90 0,00 79,80 0,00 0,00 0,00

SIP0 0 1,29 4,19 0,00 94,41 0,09 0,00 0,00

Se tutti i valori Idle sono relativamente alti, potrebbe non trattarsi di un problema relativo al control plane. Per risolvere i problemi del piano dati, è necessario osservare il QFP dell’ESP. I sintomi di "CPU elevata" possono ancora essere osservati a causa di un QFP sovrautilizzato, che non si traduce in un'elevata CPU sui processori del control plane. Procedere al PASSO 6.

Fase 2 - Analisi del modulo

- Route Processor

Confermare all'interno dell'RP quale processore presenta un elevato utilizzo della CPU con il comando seguente. È il processo Linux o IOS?

show platform software process slot RP active monitor

Se la percentuale di CPU IOS è elevata (linux_iosd-image), si tratta dell'RP IOS. Andare al PUNTO 3

Se la percentuale di CPU di altri processi è elevata, è probabile che si tratti del processo Linux. Andare al PUNTO 4

- Embedded Services Processor

Verificare all'interno dell'ESP se il processore del control plane è caratterizzato da un elevato utilizzo della CPU. È la FECP?

show platform software process slot monitor attivo FP

Se i processi sono elevati, si tratta del FECP, quindi passare al PUNTO 5

Se non si tratta della FECP, non si tratta di un control plane che elabora i problemi correlati all'interno della ESP. Se si osservano ancora sintomi quali la latenza di rete o le perdite di coda, potrebbe essere necessario rivedere il piano dati per verificarne un sovrautilizzo. Andare al PUNTO 6

- SPA Interface Processor

Se si rileva che il SIP ha un elevato utilizzo della CPU, si osserverà che l'IOCP ha una CPU elevata. Determinare quali processi nell'IOCP hanno un elevato utilizzo della CPU.

Eseguire l'acquisizione di un pacchetto e identificare il traffico più alto del solito e i processi associati a questo tipo di traffico. Andare al PASSO 7

Fase 3 - Processi IOS

Fare riferimento all'output riportato di seguito, la prima percentuale è l'utilizzo totale della CPU e la seconda percentuale è l'utilizzo della CPU degli interrupt, ovvero la quantità di CPU utilizzata per elaborare i pacchetti persi.

Se la percentuale di interrupt è elevata, significa che una grande quantità di traffico viene indirizzata all'RP, (ciò può essere confermato con il comando show platform software infrastructure punt)

Se la percentuale di interrupt è bassa, ma il totale della CPU è alto, allora ci sarà uno o più processi che saranno osservati per utilizzare la CPU per un periodo esteso.

Con il comando seguente, verificare all'interno del sistema operativo IOS quali processi hanno un elevato utilizzo della CPU.

mostra processi in base a cpu

Identificare la percentuale elevata (CPU totale o CPU di interrupt) e, se necessario, identificare i singoli processi. Andare al PASSO 7

Router#show processes cpu sort

Utilizzo CPU per cinque secondi:0% / 0%; un minuto: 1%; cinque minuti: 1%

Runtime PID (ms) Richiamato uSec 5Sec 1Min 5Min Processo TTY

Runtime PID (ms) Richiamato uSec 5Sec 1Min 5Min Processo TTY

188 8143 434758 18 0,15% 0,18% 0,19% 0 Ethernet Msec Ti

515 380 7050 53 0,07% 0,00% 0,00% 0 SBC processo principale

3 2154 215 10018 0,07% 0,00% 0,19% 0 Exec

380 1783 5002 32 0,07% 0,06% 0,06% 0 MMA DB TIMER

63 3132 11143 281 0,07% 0,07% 0,07% 0 IOSD ipc task

5 1 2 500 0,00% 0,00% 0,00% 0 IPC ISSU Dispatch

6 19 12 1583 0,00% 0,00% 0,00% 0 RF Slave Main Th

8 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timer

7 0 1 0 0,00% 0,00% 0,00% 0 EDDRI_MAIN

10 6 75 80 0,00% 0,00% 0,00% 0 Pool Manager

9 5671 538 10540 0,00% 0,14% 0,12% 0 Check heap

Fase 4 - Processi Linux

Se si rileva che il sistema operativo IOS ha sovrautilizzato la CPU, è necessario osservare l'utilizzo della CPU per il singolo processo linux. Questi processi sono gli altri processi elencati dal monitor attivo show platform software process slot RP. Identificare il processo o i processi osservati per rilevare un'elevata CPU, quindi passare al PASSO 7.

Fase 5 - Processi FECP

Se uno o più processi sono elevati, è probabile che siano i processi all'interno di FECP a essere responsabili dell'elevato utilizzo della CPU, procedere al PASSO 7

Fase 6 - Utilizzo QFP

Quantum Flow Processor è l'ASIC di inoltro. Per determinare il carico sul motore di inoltro, è possibile monitorare QFP. Il comando seguente elenca i pacchetti di input e output (priorità e non priorità) in pacchetti al secondo e bit al secondo. Nell'ultima riga viene visualizzata la quantità totale di carico della CPU dovuto all'inoltro dei pacchetti in percentuale.

mostra utilizzo percorso dati attivo qfp hardware della piattaforma

Identificare se l'input o l'output sono elevati, visualizzare il carico del processo e quindi procedere al PASSO 7

Router#show platform hardware qfp utilizzo datapath attivo

CPP 0: Deviazione secondaria 0 5 sec 1 min 5 min 60 min

Ingresso:  Priorità (ps) 0 0 0 0

(bps) 208 176 176 176

Non prioritario (SPA) 0 2 2 2

(bps) 64 784 784 784

Totale (pps) 0 2 2 2

(bps) 272 960 960 960

Uscita: Priorità (ps) 0 0 0 0

(bps) 192 160 160 160

Non prioritario (ps) 0 1 1 1

(bps) 0 6488 6496 6488

Totale (pps) 0 1 1 1

(bps) 192 648 6656 6648

Elaborazione: Carico (pct) 0 0 0

Passaggio 7 - Determinare la causa principale e identificare la correzione

Quando viene identificato un sovrautilizzo della CPU da parte di uno o più processi, è più chiaro perché si è verificato un sovrautilizzo della CPU. Per continuare, ricercare le funzioni eseguite dal processo identificato. Ciò contribuirà a definire un piano d'azione su come affrontare il problema. Ad esempio, se il processo è responsabile di un particolare protocollo, è possibile esaminare la configurazione relativa a questo protocollo.

Se si verificano ancora problemi relativi alla CPU, si consiglia di contattare TAC per consentire a un tecnico di risolvere ulteriormente il problema. La procedura di risoluzione dei problemi descritta in precedenza consente al tecnico di isolare il problema in modo più efficiente.

Esempio di risoluzione dei problemi

In questo esempio viene analizzato il processo per risolvere i problemi e si cerca di individuare con precisione la causa principale dell'elevato livello di CPU del router. Per iniziare, determinare quale modulo rileva un elevato livello di CPU, è disponibile l'output riportato di seguito.

Router#show platform software status control-processor brief

Carico medio

Stato Dello Slot 1-Min 5-Min 15-Min

RP0 Integro 0,66 0,15 0,05

ESP0 Integro 0,00 0,00 0,00

SIP0 Integro 0,00 0,00 0,00

Memoria (KB)

Stato Slot Totale Utilizzato (Pct) Senza Impegno (Pct)

RP0 Integro 2009376 1879196 (94%) 130180 ( 6%) 1432756 (71%)

ESP0 Integro 2009400 692472 (34%) 1316928 (66%) 472668 (24%)

SIP0 Integro 471804 284556 (60%) 187248 (40%) 193148 (41%)

Utilizzo CPU

Slot CPU User System Nice Idle IRQ SIRQ IOwait

RP0 0 57,11 14,42 0,00 0,00 28,25 0,19 0,00

ESP0 0 2,10 17,91 0,00 79,97 0,00 0,00 0,00

SIP0 0 1,20 6,00 0,00 92,80 0,00 0,00 0,00

Poiché la quantità di inattività all'interno di RP0 è molto bassa, suggerisce un problema elevato della CPU all'interno del processore di routing. Pertanto, per risolvere ulteriormente i problemi, identificheremo quale processore all'interno del RP è osservato per sperimentare una CPU elevata.

Router#show processes cpu sort

Utilizzo CPU per cinque secondi: 84% / 36%; un minuto: 34%; cinque minuti: 9%

Runtime PID (ms) Richiamato uSec 5Sec 1Min 5Min Processo TTY

107 303230 50749 5975 46,69% 18,12% 4,45% 0 IOSXE-RP Punt Se

63 105617 540091 195 0,23% 0,10% 0,08% 0 IOSD attività ipc

159 74792 2645991 28 0,15% 0,06% 0,06% 0 VRRS Filettatura principale

116 53685 169683 316 0,15% 0,05% 0,01% 0 processi al secondo

9 305547 26511 11525 0,15% 0,28% 0,16% 0 Check heap

188 362507 20979154 17 0,15% 0,15% 0,19% 0 Ethernet Msec Ti

3 147 186 790 0,07% 0,08% 0,02% 0 Exec

2 32126 33935 946 0,07% 0,03% 0,00% 0 Load Meter

446 416 3932 12 0,07% 0,00% 0,00% 0 VDC

164 5945 5261819 11 0,07% 0,04% 0,02% 0 Validità tentativi IP ARP

43 1703 16969 100 0,07% 0,00% 0,00% 0 IPC Keep Alive M

Da questo output, è possibile osservare che la percentuale totale di CPU e la percentuale di interrupt sono più alte del previsto. Il processo principale che utilizza la CPU è il "IOSXE-RP Punt Se", che è il processo che gestisce il traffico per la CPU RP, quindi possiamo esaminare ulteriormente questo traffico che viene puntato all'RP.

Router#show platform software infrastructure punt

Stati interni interfaccia LSMPI:

enabled=0, disabled=0, throttled=0, unthrottled=0, lo stato è ready

Buffer di input = 90100722

Buffer di output = 100439

conteggio rxdone = 90100722

conteggio txdone = 100436

Rx no particletype count = 0

Tx no particletype count = 0

Txbuf da conteggio ombreggiature = 0

Nessun inizio pacchetto = 0

Nessuna fine del pacchetto = 0

Statistiche rilascio punt:

Versione 0 non valida

Tipo 0 non valido

Intestazione caratteristica 0

Con intestazione piattaforma 0

Intestazione funzionalità mancante 0

Intestazione comune non corrispondente 0

Lunghezza totale 0 non valida

Lunghezza pacchetto non valida 0

Offset di rete 0 non valido

Non punt header 0

Tipo di collegamento sconosciuto 0

Nessun swidb 1

Intestazione caratteristica ESS 0 non valida

Nessuna funzionalità ESS 0

Nessuna funzionalità SSLVPN 0

Tipo Punt For Us sconosciuto 0

Causa punta non compresa nell'intervallo 0

IOSXE-RP Punt packet cause:

62210226 Pacchetti di controllo Layer2 e legacy

147 Pacchetti richiesta o risposta ARP

27801234 Pacchetti dati For-us

8426 RP<->QFP keepalive pacchetti

6 Pacchetti adiacenti alla griglia

1647 Pacchetti di controllo For-us

FOR_US Controlla lo stato del protocollo IPv4:

Pacchetti 1647 OSPF

Istogramma del pacchetto (500 byte/bin), dimensioni medie in 92, out 56:

Conteggio In Ingresso Dimensioni Pak Esaurito

0+:    90097805 98790

Oltre 500:           0 7

Da questo output, possiamo vedere che ci sono una grande quantità di pacchetti nei "For-us data packets" che indica il traffico diretto al router. È stato confermato che questo contatore è aumentato dall'osservazione del comando più volte nell'arco di diversi minuti. Ciò conferma che la CPU è sovrautilizzata da una grande quantità di traffico punted, che spesso controlla il traffico aereo. Il traffico del control plane può includere ARP, SSH, SNMP, aggiornamenti delle route (BGP, EIGRP, OSPF), ecc. Sulla base di queste informazioni, siamo in grado di identificare la possibile causa dell'elevato utilizzo di CPU e ciò consente di risolvere i problemi relativi alla causa principale. Ad esempio, potrebbe essere implementata l'acquisizione di un pacchetto o un monitoraggio di traffico diverso per vedere l'esatto traffico puntato al RP, che consentirebbe di identificare e risolvere la causa principale per prevenire un problema simile in futuro.

Una volta completata l'acquisizione di un pacchetto, alcuni esempi di potenziale traffico puntato sono:

- ARP Questa situazione potrebbe essere causata da un numero eccessivo di richieste ARP, che si verificherebbero se più indirizzi IP inviassero richieste ARP tramite la configurazione di una route IP a un'interfaccia di broadcast. Ciò può essere dovuto anche alle voci scaricate dalla tabella ARP e dovrà essere riacquisito in base alle voci dell'indirizzo MAC che scadono, o interfacciano il "su/giù".

- SSH: Ciò potrebbe causare un elevato livello di CPU a causa di un comando show di grandi dimensioni (show tech-support) o quando sono abilitati molti comandi di debug, che forza l'invio di una grande quantità di CLI sulla sessione SSH.

- SNMP: Ciò può essere dovuto al fatto che l'agente SNMP impiega molto tempo per elaborare una richiesta e di conseguenza causa un utilizzo elevato della CPU. Spesso due cause probabili sono i MIB sottoposti a polling o le tabelle route e/o ARP sottoposte a polling dal sistema NMS.

- Aggiornamenti route: Spesso un flusso di aggiornamenti di route è dovuto a una riconvergenza di rete o a link flap. Ciò potrebbe indicare percorsi non attivi all'interno della rete o interi dispositivi non attivi che forzano la convergenza della rete e il ricalcolo dei percorsi migliori, a seconda del protocollo di routing in uso.

In questo modo viene evidenziato come la root cause possa essere isolata attraverso l'identificazione della causa dell'elevata CPU, quando si riduce a un singolo livello di processo. Da qui è possibile analizzare il singolo processo o protocollo in modo isolato per stabilire se si tratta di un problema di configurazione, di software, di progettazione della rete o di una procedura prevista.

Comandi aggiuntivi

Di seguito è riportato un elenco di altri comandi utili da utilizzare, ordinati in base al processore a cui si riferiscono:

Route Processor

- <mostra cronologia cpu processo>

- Fornisce un grafico della cronologia della CPU negli ultimi 60 secondi, minuti e 72 ore

- <show process ID_processo>

- Informazioni dettagliate sulle allocazioni di memoria e CPU dei singoli processi

- <show platform software infrastructure punt>

- Fornisce informazioni su tutto il traffico puntato all'RP

- <show platform software status control-processor brief>

- Fornisce dettagli sul carico e sullo stato della CPU, nonché sulle statistiche della memoria e del modulo

- <show platform software process slot r0|r1 monitor>

- Dettagli sui diversi processi e sulle relative allocazioni di CPU e memoria nel modulo selezionato

- <monitor platform software process r0|r1>

- Fornisce un feed in tempo reale che aggiorna i processi quando utilizzano la CPU

- Per il corretto funzionamento, è necessario innanzitutto immettere il comando "terminal-type" in modalità di configurazione globale

Embedded Services Processor

- <show platform software process list fp riepilogo attivo>

- Visualizza in dettaglio un riepilogo di tutti i processi eseguiti sulla CPU, nonché il carico medio

- <show platform software process slot f0|f1 monitor>

- Dettagli sui diversi processi e sulle relative allocazioni di CPU e memoria nel modulo selezionato

- <processo software piattaforma monitor f0|f1>

- Fornisce un feed in tempo reale che aggiorna i processi che utilizzano la CPU

- Per il corretto funzionamento, è necessario innanzitutto immettere il comando "terminal-type" in modalità di configurazione globale