Fehlerbehebung bei hoher CPU-Auslastung aufgrund des Eingabeprozesses

Einleitung

In diesem Dokument wird die Fehlerbehebung bei hoher CPU-Auslastung aufgrund des IP-Eingabeprozesses beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, bevor Sie mit diesem Dokument fortfahren, die Informationen zur Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern zu lesen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hinweis: In diesem Dokument werden keine Strategien zur Verhinderung verschiedener Arten von Angriffen beschrieben.

IP-Eingang

Der Cisco IOS®^-Softwareprozess mit der Bezeichnung IP Input übernimmt das Prozess-Switching von IP-Paketen. Wenn für den IP-Eingabeprozess ungewöhnlich hohe CPU-Ressourcen verwendet werden, sorgt der Router für ein Prozess-Switching bei einem großen Teil des IP-Datenverkehrs. Überprüfen Sie folgende Probleme:

• Interrupt Switching ist an einer Schnittstelle (oder Schnittstellen) mit hohem Datenverkehr deaktiviert.

  Interrupt Switching bezeichnet die Verwendung anderer Switching-Algorithmen als Process Switching. Beispiele hierfür sind schnelles Switching, optimales Switching, Cisco Express Forwarding usw. (weitere Informationen finden Sie in den Grundlagen zur Leistungsoptimierung). Überprüfen Sie die Ausgabe des show interfaces switching   um zu sehen, welche Schnittstelle durch Datenverkehr belastet ist. Sie können die show ip interface , um zu sehen, welche Switching-Methoden auf den einzelnen Schnittstellen verwendet werden. Erneutes Aktivieren des Unterbrechungswechsels an dieser Schnittstelle Denken Sie daran, dass auf den Ausgangsschnittstellen regelmäßiges Fast Switching konfiguriert ist: Wenn Fast Switching auf einer Schnittstelle konfiguriert ist, werden Pakete, die von dieser Schnittstelle ausgehen, mit Fast Switching weitergeleitet. Cisco Express Forwarding Switching wird an Eingangsschnittstellen konfiguriert. Um Einträge für die Forwarding Information Base (FIB) und die Adjacency-Tabelle auf einer bestimmten Schnittstelle zu erstellen, konfigurieren Sie Cisco Express Forwarding Switching auf allen Schnittstellen, die diese Schnittstelle weiterleiten.

• Fast Switching auf derselben Schnittstelle ist deaktiviert.

  Wenn eine Schnittstelle über zahlreiche sekundäre Adressen oder Subschnittstellen verfügt und viel Datenverkehr von der Schnittstelle stammt und für eine Adresse auf derselben Schnittstelle bestimmt ist, werden alle Pakete prozessgesteuert. In diesem Fall müssen Sie  ip route-cache same-interface an der Schnittstelle. Bei Verwendung von Cisco Express Forwarding Switching müssen Sie Cisco Express Forwarding Switching nicht separat über dieselbe Schnittstelle aktivieren.

• Schnelles Switching an einer Schnittstelle, wenn Richtlinienrouting deaktiviert ist

  Wenn eine Routing-Map auf einer Schnittstelle konfiguriert wurde und ein Großteil des Datenverkehrs von der Route-Map verarbeitet wird, wird dieser Datenverkehr vom Router prozessgesteuert. In diesem Fall müssen Sie ip route-cache policy an der Schnittstelle. Überprüfen Sie die Einschränkungen, die im Abschnitt Enabling Fast-Switched Policy-Based Routing (Aktivieren von schnellem Switching, richtlinienbasiertem Routing) von Configuring Policy-Based Routing (Konfigurieren von richtlinienbasiertem Routing) erwähnt werden.

• Eingehender Datenverkehr, der nicht unterbrochen werden kann

  Dabei kann es sich um eine der aufgeführten Arten von Datenverkehr handeln. Klicken Sie auf die verknüpften Elemente, um weitere Informationen zu erhalten.

  • Pakete, für die noch kein Eintrag im Switching-Cache vorhanden ist

    Selbst wenn Fast, Optimal oder Cisco Express Forwarding Switching (CEF) konfiguriert ist, wird ein Paket verarbeitet, für das im Fast Switching-Cache oder in den FIB- und Adjacency-Tabellen keine Übereinstimmung vorliegt. Anschließend wird ein Eintrag im entsprechenden Cache oder in der entsprechenden Tabelle erstellt, und alle nachfolgenden Pakete, die die gleichen Kriterien erfüllen, sind schnell, optimal oder CEF-geswitcht. Unter normalen Umständen verursachen diese verarbeiteten Pakete keine hohe CPU-Auslastung. Wenn es jedoch ein Gerät im Netzwerk gibt, das 1) Pakete mit einer extrem hohen Rate für Geräte erzeugt, die über den Router erreichbar sind, und 2) unterschiedliche Quell- oder Ziel-IP-Adressen verwendet, gibt es keine Übereinstimmung für diese Pakete im Switching-Cache oder in der Switching-Tabelle, sodass sie durch den IP-Eingabeprozess verarbeitet werden (wenn NetFlow-Switching konfiguriert ist, werden Quell- und Ziel-TCP-Ports auch mit Einträgen im NetFlow-Cache abgeglichen). Bei diesem Quellgerät kann es sich um ein nicht funktionierendes Gerät oder, was wahrscheinlicher ist, um ein Gerät handeln, das einen Angriff versucht.

    (*) Nur bei Glean-Nachbarschaften. Weitere Informationen zu den Cisco Express Forwarding-Nachbarschaften finden Sie unter Understanding Cisco Express Forwarding.

  • Für den Router bestimmte Pakete

    Nachfolgend sind Beispiele für Pakete aufgeführt, die für den Router bestimmt sind:

    • Routing-Updates mit extrem hoher Geschwindigkeit Erhält der Router eine enorme Menge an Routingaktualisierungen, die verarbeitet werden müssen, kann diese Aufgabe die CPU überlasten. Normalerweise kann dies in einem stabilen Netzwerk nicht geschehen. Wie Sie mehr Informationen erfassen können, hängt vom Routing-Protokoll ab, das Sie konfiguriert haben. Sie können jedoch beginnen, die Ausgabe des  show ip route summary periodisch. Werte, die sich schnell ändern, sind ein Zeichen für ein instabiles Netzwerk. Häufige Änderungen der Routing-Tabelle bedeuten eine erhöhte Verarbeitung des Routing-Protokolls, was zu einer höheren CPU-Auslastung führt. Weitere Informationen zur Behebung dieses Problems finden Sie im Abschnitt Fehlerbehebung bei TCP/IP im Internetwork Troubleshooting Guide.

    • Alle anderen für den Router bestimmten Datenverkehrsarten. Überprüfen Sie, wer beim Router angemeldet ist, und welche Benutzeraktionen ausgeführt werden. Wenn jemand angemeldet ist und Befehle ausgibt, die eine lange Ausgabe erzeugen, folgt auf die hohe CPU-Auslastung durch den "IP-Input"-Prozess eine wesentlich höhere CPU-Auslastung durch den Virtual Exec-Prozess.

    • Spoofangriff. Um das Problem zu identifizieren, geben Sie  show ip traffic , um die Menge des IP-Datenverkehrs zu überprüfen. Tritt ein Problem auf, ist die Anzahl der empfangenen Pakete mit einem lokalen Ziel signifikant. Untersuchen Sie anschließend die Ausgabe des  show interfaces  und  show interfaces switching  Befehle, um zu überprüfen, welche Schnittstelle die Pakete empfangen. Sobald Sie die empfangende Schnittstelle identifiziert haben, aktivieren Sie ip accounting auf der ausgehenden Schnittstelle ein, und prüfen Sie, ob ein Muster vorliegt. Im Falle eines Angriffs ist die Quelladresse fast immer unterschiedlich, die Zieladresse jedoch identisch. Eine Zugriffsliste kann so konfiguriert werden, dass das Problem vorübergehend behoben wird (vorzugsweise auf dem Gerät, das der Quelle der Pakete am nächsten liegt). Die eigentliche Lösung besteht jedoch darin, das Quellgerät zu finden und den Angriff zu stoppen.

  • Broadcast-Datenverkehr

    Überprüfen Sie die Anzahl der Broadcast-Pakete im show interfaces Befehlsausgabe. Wenn Sie die Anzahl der Broadcasts mit der Gesamtzahl der Pakete vergleichen, die auf der Schnittstelle empfangen wurden, können Sie eine Vorstellung davon gewinnen, ob ein Overhead für Broadcasts vorliegt. Wenn ein LAN mit mehreren mit dem Router verbundenen Switches vorhanden ist, kann dies auf ein Problem mit Spanning Tree hinweisen.

  • IP-Pakete mit Optionen

  • Pakete, die eine Protokollübersetzung erfordern

  • Multilink Point-to-Point Protocol (wird von Cisco Express Forwarding unterstützt)

  • Komprimierter Datenverkehr

    Wenn im Router kein Compression Service Adapter (CSA) vorhanden ist, müssen komprimierte Pakete prozessgesteuert werden.

  • Verschlüsselter Datenverkehr

    Wenn im Router kein Encryption Service Adapter (ESA) vorhanden ist, müssen verschlüsselte Pakete per Prozess-Switching übertragen werden.

  • Pakete, die serielle Schnittstellen mit X.25-Kapselung durchlaufen

    In der X.25-Protokoll-Suite ist die Flusskontrolle auf der zweiten OSI-Schicht (Open System Interconnection) implementiert.

• Eine Menge Pakete, die eine extrem hohe Rate erreichen, für ein Ziel in einem direkt verbundenen Subnetz, für das es keinen Eintrag in der ARP-Tabelle (Address Resolution Protocol) gibt. Dies wird aufgrund des Fenstermechanismus beim TCP-Datenverkehr nicht erwartet, kann jedoch beim UDP-Datenverkehr (User Datagram Protocol) der Fall sein. Um das Problem zu identifizieren, wiederholen Sie die vorgeschlagenen Aktionen, um einen Spoofangriff aufzuspüren.

• Ein großer Teil des Multicast-Datenverkehrs wird über den Router geleitet. Leider ist es nicht einfach, das Volumen des Multicast-Verkehrs zu untersuchen. Die Fehlermeldung show ip traffic zeigt nur eine Zusammenfassung an. Wenn Sie jedoch Multicast-Routing auf dem Router konfiguriert haben, können Sie das schnelle Switching von Multicast-Paketen mit dem ip mroute-cache Schnittstellenkonfigurationsbefehl (Fast-Switching von Multicast-Paketen ist standardmäßig deaktiviert).

• Router ist überbelegt. Wenn der Router überlastet ist und dieses Datenverkehrsvolumen nicht bewältigen kann, versuchen Sie, die Last auf andere Router zu verteilen, oder erwerben Sie einen High-End-Router.

• Die IP Network Address Translation (NAT) wird auf dem Router konfiguriert, und viele DNS-Pakete (Domain Name System) werden über den Router übertragen. UDP- oder TCP-Pakete mit Quell- oder Ziel-Port 53 (DNS) werden von NAT immer auf die Prozessebene durchgestellt.

• Es gibt andere Pakettypen, die für die Verarbeitung gestempelt werden.

• IP-Datagramm ist fragmentiert. Der CPU- und Arbeitsspeicher-Overhead nimmt aufgrund eines Fragments eines IP-Datagramms geringfügig zu. Weitere Informationen zur Behebung dieses Problems finden Sie unter Beheben von Problemen mit IP-Fragmentierung, MTU, MSS und PMTUD für GRE und IPSEC.

Vorsicht: Unabhängig davon, aus welchem Grund die hohe CPU-Auslastung im IP-Eingabeprozess resultiert, kann die Problemursache beim Debuggen der IP-Pakete ermittelt werden. Da die CPU-Auslastung bereits hoch ist, muss der Debugprozess mit äußerster Vorsicht durchgeführt werden.

Der Debugprozess erzeugt viele Meldungen, daher muss nur die gepufferte Protokollierung konfiguriert werden.

Die Anmeldung bei einer Konsole löst unnötige Unterbrechungen der CPU aus und erhöht die CPU-Auslastung. Die Protokollierung bei einem Host (oder die Überwachungsprotokollierung) erzeugt zusätzlichen Datenverkehr an den Schnittstellen.

Der Debug-Prozess kann mit dem  debug ip packet detail  exec aus. Diese Sitzung darf maximal drei bis fünf Sekunden dauern. Debugging-Meldungen werden in den Protokollierungspuffer geschrieben. Eine Aufzeichnung einer Beispiel-IP-Debugsitzung finden Sie im Abschnitt Beispiel für eine IP-Paketdebugsitzung dieses Dokuments. Sobald das Quellgerät unerwünschter IP-Pakete gefunden wurde, kann dieses Gerät vom Netzwerk getrennt werden, oder es kann eine Zugriffsliste auf dem Router erstellt werden, um Pakete von diesem Ziel zu verwerfen.

Beispiel für eine Sitzung zum Debuggen von IP-Paketen

Konfigurierte Protokollierungsziele müssen zuerst mit dem  show logging command:

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--

Deaktivieren Sie alle Protokollierungsziele mit Ausnahme des Protokollierungspuffers und des leeren Protokollierungspuffers:

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#

Für eine bessere Lesbarkeit der Debugausgabe müssen Datums- und Millisekundenzeitstempel aktiviert sein:

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#

Jetzt kann eine Debugsitzung gestartet werden:

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

Das Debuggen darf maximal drei bis fünf Sekunden dauern. Die Sitzung kann mit dem  undebug all exec command:

router#undebug all 
All possible debugging has been turned off

Die Ergebnisse können mit dem show logging exec command:

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      
... 

Das Protokoll zeigt Folgendes:

• Alle vier Millisekunden wurde ein Paket empfangen.

• Die IP-Quelladresse lautet 192.168.40.53

• Die Pakete sind über die Schnittstelle Ethernet0/1 eingegangen.

• Die Pakete haben unterschiedliche Ziel-IP-Adressen

• Die Pakete wurden über die Schnittstelle Ethernet0/0 gesendet.

• Die Next-Hop-IP-Adresse lautet 10.200.40.1.

• Die Pakete waren ICMP-Anfragen (Typ=8)

  In diesem Beispiel sehen Sie, dass die hohe CPU-Auslastung im IP-Eingabeprozess durch eine Ping-Flut von der IP-Adresse 192.168.40.53 verursacht wurde.

  SYN-Floods können auf diese Weise leicht erkannt werden, da das Vorhandensein eines SYN-Flags in der Debugausgabe angezeigt wird:

*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

Zugehörige Informationen

• Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern
• Befehl „show processes“
• Performance Tuning Basics
• Technischer Support und Downloads von Cisco