Risoluzione dei problemi di CPU elevata su router ASR serie 1000

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