Risoluzione dei problemi di utilizzo elevato della CPU a causa del processo di input

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a un utilizzo elevato della CPU dovuto al processo di input IP.

Prerequisiti

Requisiti

Cisco consiglia di consultare la sezione Risoluzione dei problemi di utilizzo elevato della CPU sui router Cisco prima di procedere con 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.

Nota: questo documento non fornisce strategie per prevenire diversi tipi di attacchi.

Ingresso IP

Il processo software Cisco IOS^® chiamato IP input si occupa dei pacchetti IP di commutazione di contesto. Se il processo di input IP utilizza risorse CPU insolitamente elevate, il router sta commutando molti dati del traffico IP. Verificare i seguenti problemi:

• La commutazione di interrupt è disabilitata su una o più interfacce che hanno molto traffico

  La commutazione di interrupt si riferisce all'uso di algoritmi di commutazione diversi dalla commutazione di contesto. Gli esempi includono la commutazione rapida, la commutazione ottimale, la commutazione Cisco Express Forwarding e così via (per ulteriori informazioni, fare riferimento a Nozioni fondamentali sul tuning delle prestazioni). Esaminare l'output del show interfaces switching   per verificare quale interfaccia è sovraccarica di traffico. È possibile controllare la show ip interface per verificare i metodi di commutazione utilizzati su ciascuna interfaccia. Riattivare la commutazione di interrupt sull'interfaccia. Tenere presente che sulle interfacce di output è configurata la commutazione veloce regolare: se su un'interfaccia è configurata la commutazione veloce, i pacchetti che escono dall'interfaccia vengono commutati rapidamente. La commutazione di inoltro rapido di Cisco è configurata sulle interfacce di input. Per creare le voci Forwarding Information Base (FIB) e la tabella adiacente su un'interfaccia specifica, configurare la commutazione Cisco Express Forwarding su tutte le interfacce che indirizzano a tale interfaccia.

• L'opzione di commutazione veloce sulla stessa interfaccia è disabilitata

  Se un'interfaccia ha molti indirizzi secondari o sottointerfacce e c'è molto traffico proveniente dall'interfaccia e destinato a un indirizzo sulla stessa interfaccia, allora tutti quei pacchetti sono a commutazione di contesto. In questo caso, è necessario attivare  ip route-cache same-interface sull'interfaccia. Quando si usa la commutazione di inoltro Cisco Express, non è necessario abilitare la commutazione di inoltro Cisco Express sulla stessa interfaccia separatamente.

• Commutazione rapida di un'interfaccia che fornisce il routing delle policy disabilitato

  Se su un'interfaccia è stata configurata una mappa dei percorsi e la mappa dei percorsi gestisce molto traffico, il processo del router modifica questo traffico. In questo caso, è necessario attivare ip route-cache policy sull'interfaccia. Verificare le restrizioni indicate nella sezione Abilitazione del routing basato su criteri Fast-Switched in Configurazione del routing basato su criteri.

• Arriva traffico che non può essere interrotto

  Può corrispondere a uno dei tipi di traffico elencati. Per ulteriori informazioni, fare clic sugli elementi collegati.

  • Pacchetti per i quali non vi è ancora una voce nella cache di commutazione

    Anche se è stata configurata la commutazione CEF (Fast, Optimum, or Cisco Express Forwarding Switching), viene elaborato un pacchetto per il quale non esiste corrispondenza nella cache o nelle tabelle FIB di commutazione rapida e nelle adiacenze. Viene quindi creata una voce nella cache o nella tabella appropriata e tutti i pacchetti successivi che soddisfano gli stessi criteri sono fast, optimum o CEF-switched. In circostanze normali, questi pacchetti elaborati non causano un elevato utilizzo della CPU. Tuttavia, se in rete è presente un dispositivo che 1) genera pacchetti a una velocità estremamente elevata per i dispositivi raggiungibili tramite il router e 2) utilizza indirizzi IP di origine o di destinazione diversi, la cache o la tabella di commutazione non contiene una corrispondenza per questi pacchetti, quindi i pacchetti vengono elaborati dal processo di input IP (se è configurata la commutazione NetFlow, le porte TCP di origine e di destinazione vengono confrontate anche con le voci della cache NetFlow). Il dispositivo di origine può essere un dispositivo non funzionante o, più probabilmente, un dispositivo che tenta un attacco.

    (*) Solo con adiacenze di guaina. Per ulteriori informazioni sulle adiacenze di Cisco Express Forwarding, fare riferimento a Descrizione di Cisco Express Forwarding.

  • Pacchetti destinati al router

    Di seguito sono riportati alcuni esempi di pacchetti destinati al router:

    • Aggiornamenti di routing che arrivano a una velocità estremamente elevata. Se il router riceve una quantità enorme di aggiornamenti di routing da elaborare, questa operazione può sovraccaricare la CPU. Normalmente, ciò non accade in una rete stabile. Il modo in cui raccogliere più informazioni dipende dal protocollo di routing configurato. Tuttavia, è possibile iniziare a controllare l'output del  show ip route summary periodicamente. I valori che cambiano rapidamente sono il segno di una rete instabile. Frequenti modifiche alla tabella di routing implicano un aumento dell'elaborazione del protocollo di routing, con conseguente aumento dell'utilizzo della CPU. Per ulteriori informazioni su come risolvere questo problema, consultare la sezione Risoluzione dei problemi relativi a TCP/IP nella Guida per la risoluzione dei problemi di interrete.

    • Qualsiasi altro tipo di traffico destinato al router. Controllare chi è connesso al router e le azioni dell'utente. Se un utente è connesso ed esegue comandi che producono un output lungo, l'elevato utilizzo della CPU da parte del processo di "input IP" è seguito da un maggiore utilizzo della CPU da parte del processo di esecuzione virtuale.

    • Attacco per scherno. Per identificare il problema, utilizzare il comando  show ip traffic per controllare la quantità di traffico IP. In caso di problemi, il numero di pacchetti ricevuti con una destinazione locale è significativo. Esaminare quindi l'output del  show interfaces  e  show interfaces switching  comandi per controllare l'interfaccia di arrivo dei pacchetti. Dopo aver identificato l'interfaccia ricevente, accenderla ip accounting sull'interfaccia in uscita e verificare se è presente un modello. In caso di attacco, l'indirizzo di origine è quasi sempre diverso, ma l'indirizzo di destinazione è lo stesso. È possibile configurare un elenco degli accessi per risolvere il problema temporaneamente (preferibilmente sul dispositivo più vicino all'origine dei pacchetti), ma la vera soluzione è rintracciare il dispositivo di origine e fermare l'attacco.

  • Traffico broadcast

    Controllare il numero di pacchetti broadcast nella show interfaces output del comando. Se si confronta la quantità di trasmissioni con la quantità totale di pacchetti ricevuti sull'interfaccia, è possibile stabilire se esiste un sovraccarico di trasmissioni. Se al router sono collegati più switch LAN, potrebbe essersi verificato un problema con lo Spanning Tree.

  • Pacchetti IP con opzioni

  • Pacchetti che richiedono la traduzione del protocollo

  • Protocollo Multilink Point-to-Point (supportato nella commutazione Cisco Express Forwarding)

  • Traffico ridotto

    Se il router non contiene un CSA (Compression Service Adapter), i pacchetti compressi devono essere a commutazione di contesto.

  • Traffico crittografato

    Se il router non contiene un Encryption Service Adapter (ESA), i pacchetti crittografati devono essere commutati a livello di processo.

  • Pacchetti che passano attraverso interfacce seriali con incapsulamento X.25

    Nella suite di protocolli X.25, il controllo del flusso è implementato sul secondo livello OSI (Open System Interconnection).

• Un sacco di pacchetti che arrivano a una velocità estremamente elevata per una destinazione in una subnet collegata direttamente, per la quale non esiste alcuna voce nella tabella ARP (Address Resolution Protocol). Questa situazione non è prevista per il traffico TCP a causa del meccanismo di windowing, ma può verificarsi anche con il traffico UDP (User Datagram Protocol). Per identificare il problema, ripetere le azioni suggerite per individuare un attacco spoof.

• Molto traffico multicast attraversa il router. Sfortunatamente, non c'è un modo semplice per esaminare la quantità di traffico multicast. OSPF (Open Shortest Path First) show ip traffic Il comando visualizza solo informazioni di riepilogo. Tuttavia, se è stato configurato il routing multicast sul router, è possibile abilitare la commutazione rapida dei pacchetti multicast con il ip mroute-cache comando interface configuration (la commutazione rapida dei pacchetti multicast è disattivata per impostazione predefinita).

• Il router ha una sottoscrizione eccessiva. Se il router è sovrautilizzato e non è in grado di gestire questa quantità di traffico, provare a distribuire il carico tra altri router o acquistare un router di fascia alta.

• Sul router è configurato IP Network Address Translation (NAT) e molti pacchetti DNS (Domain Name System) passano attraverso il router. I pacchetti UDP o TCP con porta di origine o di destinazione 53 (DNS) vengono sempre elaborati a livello di processo da NAT.

• Esistono altri tipi di pacchetti che possono essere elaborati.

• In questo caso, il datagramma IP è frammentato. Si verifica un piccolo aumento del sovraccarico della CPU e della memoria a causa del frammento di un datagramma IP. Per ulteriori informazioni su come risolvere il problema, consultare il documento sulla risoluzione dei problemi di IP Fragmentation, MTU, MSS e PMTUD con GRE e IPSEC.

Attenzione: indipendentemente dalla causa dell'elevato utilizzo della CPU nel processo di input IP, è possibile individuare l'origine del problema durante il debug dei pacchetti IP. Poiché l'utilizzo della CPU è già elevato, il processo di debug deve essere eseguito con estrema cautela.

Il processo di debug genera molti messaggi, quindi è necessario configurare solo la registrazione nel buffer.

La registrazione su una console provoca interruzioni non necessarie alla CPU e ne aumenta l'utilizzo. La registrazione su un host (o la registrazione del monitoraggio) genera traffico aggiuntivo sulle interfacce.

Il processo di debug può essere avviato con  debug ip packet detail  exec La durata di questa sessione non deve superare i tre-cinque secondi. I messaggi di debug vengono scritti nel buffer di registrazione. L'acquisizione di una sessione di debug IP di esempio è disponibile nella sezione Sessione di debug pacchetti IP di esempio di questo documento. Una volta individuata la periferica di origine dei pacchetti IP indesiderati, è possibile disconnettere la periferica dalla rete oppure creare un elenco degli accessi sul router per rilasciare i pacchetti da quella destinazione.

Sessione di debug pacchetti IP di esempio

Le destinazioni di logging configurate devono essere controllate prima con il comando  show logging comando:

router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: level debugging, 52 messages logged 
    Monitor logging: level debugging, 0 messages logged 
    Buffer logging: level debugging, 148 messages logged 
    Trap logging: level informational, 64 message lines logged 
        Logging to 192.168.100.100, 3 message lines logged 
        Logging to 192.168.200.200, 3 message lines logged 
 --More--

Disabilitare tutte le destinazioni di registrazione ad eccezione del buffer di registrazione e cancellare il buffer di registrazione:

router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#no logging console 
router(config)#no logging monitor 
router(config)#no logging 192.168.100.100 
router(config)#no logging 192.168.200.200 
router(config)#^Z 
router#clear logging 
Clear logging buffer [confirm]
router#

Per una migliore leggibilità dell'output di debug, è necessario attivare i timestamp datetime e millisecondi:

router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#service timestamps log datetime msec 
router(config)#service timestamps debug datetime msec 
router(config)#end 
router#

È ora possibile avviare una sessione di debug:

router#debug ip packet detail 
IP packet debugging is on (detailed)

La durata del debug non deve superare i tre-cinque secondi. La sessione può essere interrotta con  undebug all exec comando:

router#undebug all 
All possible debugging has been turned off

I risultati possono essere controllati con il show logging exec comando:

router#show logging 
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: disabled 
    Monitor logging: disabled 
    Buffer logging: level debugging, 145 messages logged 
    Trap logging: level informational, 61 message lines logged 
Log Buffer (64000 bytes): 

*Mar  3 03:43:27.320: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.204 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.324: ICMP type=8, code=0      
*Mar  3 03:43:27.324: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.205 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.324: ICMP type=8, code=0      
*Mar  3 03:43:27.328: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.206 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.328: ICMP type=8, code=0      
... 

Dal registro risulta che:

• È stato ricevuto un pacchetto ogni quattro millisecondi

• L'indirizzo IP di origine è 192.168.40.53

• I pacchetti sono arrivati sull'interfaccia Ethernet0/1

• I pacchetti hanno indirizzi IP di destinazione diversi

• I pacchetti sono stati inviati sull'interfaccia Ethernet0/0

• L'indirizzo IP dell'hop successivo è 10.200.40.1

• I pacchetti erano richieste ICMP (tipo=8)

  Nell'esempio, è possibile notare che l'elevato utilizzo della CPU nel processo di input IP è stato causato da un'inondazione del ping proveniente dall'indirizzo IP 192.168.40.53.

  I flood SYN possono essere facilmente rilevati in questo modo perché la presenza del flag SYN è indicata nell'output di debug:

*Mar 3 03:54:40.436: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.204 
   (Ethernet0/0), g=10.200.40.1, len 44, forward     
*Mar 3 03:54:40.440: TCP src=11004, dst=53, 
   seq=280872555, ack=0, win=4128 SYN

Informazioni correlate

• Risoluzione dei problemi relativi all'utilizzo elevato della CPU nei router Cisco
• Il comando show processes
• Nozioni di base sull'ottimizzazione delle prestazioni
• Supporto tecnico e download Cisco