Risoluzione dei problemi di utilizzo elevato della CPU nel processo di input IP

Introduzione

Questo documento spiega come risolvere i problemi relativi all'elevato utilizzo della CPU dovuto al processo di input IP.

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

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.

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 sulla regolazione delle prestazioni). Esaminare l'output del comando show interfaces switching per verificare quale interfaccia è piena di traffico. È possibile controllare il comando show ip interface per verificare i metodi di commutazione usati su ciascuna interfaccia. Riattivare la commutazione di interrupt sull'interfaccia. Tenere presente che sulle interfacce di output è configurata la commutazione veloce regolare: se sull'interfaccia è configurata l'opzione di 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 questa situazione, abilitare ip route-cache stessa interfaccia 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 commuta il traffico. In questo caso, abilitare i criteri ip route-cache sull'interfaccia. Verificare le restrizioni menzionate 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ò essere uno dei tipi di traffico elencati. Fare clic sugli elementi collegati per ulteriori informazioni.

  • 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 inoltro Cisco Express, fare riferimento a 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 potrebbe 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 periodicamente l'output del comando show ip route summary. 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, fare riferimento alla sezione Risoluzione dei problemi relativi a TCP/IP nella Guida per la risoluzione dei problemi di Internet.

    • 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 Virtual Exec.

    • Attacco parodia. Per identificare il problema, usare 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 dei comandi show interfaces e show interfaces switching per verificare l'interfaccia a cui stanno arrivando i pacchetti. Dopo aver identificato l'interfaccia ricevente, attivare 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

    Verificare il numero di pacchetti broadcast nell'output del comando show interfaces. 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 compresso

    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 a commutazione di contesto.

  • 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). Ciò non dovrebbe verificarsi con il traffico TCP a causa del meccanismo di windowing, ma può verificarsi 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. Il comando show ip traffic visualizza solo le informazioni di riepilogo. Tuttavia, se sul router è stato configurato il routing multicast, è possibile abilitare la commutazione rapida dei pacchetti multicast con il comando di configurazione dell'interfaccia ip route-cache (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. Il sovraccarico di CPU e memoria aumenta leggermente a causa del frammento di un datagramma IP. Per ulteriori informazioni su come risolvere il problema, consultare il documento sulla risoluzione dei problemi di frammentazione IP, MTU, MSS e PMTUD con GRE e IPSEC.

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 il comando debug ip packet detail exec. La durata della 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 pacchetto 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

Per controllare le destinazioni di registrazione configurate, usare prima il comando show logging:

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 abilitare 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 arrestata con il comando undebug all exec:

router#undebug all 
All possible debugging has been turned off

Per controllare i risultati, usare il comando show logging exec:

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=144.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=144.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=144.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=144.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
• Elevato utilizzo della CPU sugli switch Catalyst 2900XL/3500XL
• Nozioni di base sull'ottimizzazione delle prestazioni
• Documentazione e supporto tecnico – Cisco Systems

Cronologia delle revisioni