Catalyst 6500/6000 Switch Hohe CPU-Auslastung
Inhalt
Einleitung
Dieses Dokument beschreibt die Ursachen für eine hohe CPU-Auslastung auf Cisco Catalyst Switches der Serien 6500/6000 und auf Virtual Switching System (VSS) 1440 basierten Systemen. Wie Cisco Router verwenden Switches den Befehl show processes cpu, um die CPU-Auslastung für den Supervisor Engine-Prozessor des Switches anzuzeigen. Aufgrund der Unterschiede bei der Architektur und den Weiterleitungsmechanismen zwischen Cisco Routern und Switches unterscheidet sich die typische Ausgabe des Befehls show processes cpu erheblich. Auch die Bedeutung der Ausgabe ist unterschiedlich. Dieses Dokument erläutert diese Unterschiede und beschreibt die CPU-Auslastung auf den Switches sowie die Interpretation der Ausgabe des Befehls show processes cpu.
Hinweis: In diesem Dokument beziehen sich die Begriffe "Switch" und "Switches" auf Catalyst 6500/6000 Switches.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den Software- und Hardwareversionen der Catalyst 6500/6000 Switches und der auf VSS (Virtual Switching System) 1440 basierenden Systeme.
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 Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.
Hinweis: Die unterstützte Software für Systeme, die auf Virtual Switching System (VSS) 1440 basieren, ist Cisco IOS® Softwareversion 12.2(33)SXH1 oder höher.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Unterschiede zwischen CatOS- und Cisco IOS-Systemsoftware
Catalyst OS (CatOS) auf der Supervisor Engine und Cisco IOS® Software auf der Multilayer Switch Feature Card (MSFC) (Hybrid): Sie können ein CatOS-Image als Systemsoftware verwenden, um die Supervisor Engine auf Catalyst 6500/6000-Switches auszuführen. Wenn die optionale MSFC installiert ist, wird ein separates Cisco IOS Software-Image verwendet, um die MSFC auszuführen.
Cisco IOS-Software auf Supervisor-Engine und MSFC (nativ): Sie können ein einzelnes Cisco IOS Software-Image als Systemsoftware verwenden, um sowohl die Supervisor Engine als auch MSFC auf Catalyst 6500/6000 Switches auszuführen.
Hinweis: Weitere Informationen finden Sie unter Vergleich der Cisco Catalyst- und Cisco IOS-Betriebssysteme für den Cisco Switch der Catalyst 6500-Serie.
Verständnis der CPU-Auslastung auf Catalyst 6500/6000 Switches
Softwarebasierte Router von Cisco verwenden Software, um Pakete zu verarbeiten und weiterzuleiten. Die CPU-Auslastung auf einem Cisco Router steigt tendenziell, da der Router eine höhere Anzahl an Paketverarbeitungs- und Routingvorgängen durchführt. Daher kann der Befehl show processes cpu eine ziemlich genaue Angabe der Datenverkehrsverarbeitungslast auf dem Router liefern.
Catalyst 6500/6000-Switches verwenden die CPU nicht in gleicher Weise. Diese Switches treffen Weiterleitungsentscheidungen in der Hardware und nicht in der Software. Wenn die Switches daher die Weiterleitungs- oder Switching-Entscheidung für die meisten Frames treffen, die den Switch passieren, ist die Supervisor Engine-CPU nicht am Prozess beteiligt.
Für Catalyst Switches der Serien 6500/6000 sind zwei CPUs erforderlich. Eine CPU ist die Supervisor Engine-CPU, die als Network Management Processor (NMP) oder Switch Processor (SP) bezeichnet wird. Die andere CPU ist die Layer 3-Routing-Engine-CPU, die als MSFC oder Routing-Prozessor (RP) bezeichnet wird.
Die SP-CPU führt folgende Funktionen aus:
-
Unterstützt das Lernen und Altern von MAC-Adressen
Hinweis: MAC-Adresslernen wird auch als Pfadeinrichtung bezeichnet.
-
Ausführung von Protokollen und Prozessen für die Netzwerkkontrolle
Beispiele sind Spanning Tree Protocol (STP), Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), Dynamic Trunking Protocol (DTP) und Port Aggregation Protocol (PAgP).
-
Verarbeitung des Netzwerkmanagement-Datenverkehrs, der an die CPU des Switches gerichtet ist
Beispiele hierfür sind Telnet-, HTTP- und SNMP-Datenverkehr (Simple Network Management Protocol).
Die RP-CPU führt folgende Funktionen aus:
-
Erstellung und Aktualisierung von Layer-3-Routing- und ARP-Tabellen (Address Resolution Protocol)
-
Erstellung der Cisco Express Forwarding (CEF) Forwarding Information Base (FIB)- und Adjacency-Tabellen und Download der Tabellen in die Policy Feature Card (PFC)
-
Verarbeitung des Netzwerkmanagement-Datenverkehrs, der an den RP gerichtet ist
Beispiele sind Telnet-, HTTP- und SNMP-Datenverkehr.
Situationen und Funktionen, die den Datenverkehr zur Software auslösen
Pakete, die für den Switch bestimmt sind
Jedes Paket, das für den Switch bestimmt ist, wird an die Software weitergeleitet. Zu diesen Paketen gehören:
-
Kontrollpakete
Steuerungspakete werden für STP, CDP, VTP, Hot Standby Router Protocol (HSRP), PAgP, Link Aggregation Control Protocol (LACP) und UniDirectional Link Detection (UDLD) empfangen.
-
Routing-Protokoll-Updates
Beispiele für diese Protokolle sind RIP (Routing Information Protocol), EIGRP (Enhanced Interior Gateway Routing Protocol), Border Gateway Protocol (BGP) und OSPF (Open Shortest Path First Protocol).
-
SNMP-Datenverkehr, der an den Switch gerichtet ist
-
Telnet- und SSH-Datenverkehr (Secure Shell Protocol) zum Switch.
Eine hohe CPU-Auslastung aufgrund von SSH wird wie folgt betrachtet:
00:30:50.793 SGT Tue Mar 20 2012 CPU utilization for five seconds: 83%/11%; one minute: 15%; five minutes: 8% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 3 6468 8568 754 69.30% 7.90% 1.68% 1 SSH Process
Fügen Sie die folgenden Befehle in das EEM-Skript ein, um die Anzahl der SSH-Sitzungen zu überprüfen, die bei einem hohen CPU-Durchsatz eingerichtet werden:
-
ARP-Antworten auf ARP-Anforderungen
Pakete und Bedingungen, die eine besondere Verarbeitung erfordern
Diese Liste enthält spezifische Pakettypen und -bedingungen, die die Verarbeitung von Paketen in der Software erzwingen:
-
Pakete mit IP-Optionen, einer abgelaufenen Time to Live (TTL)-Kapselung oder einer nicht Advanced Research Projects Agency (ARPA)-Kapselung
-
Pakete mit speziellem Handling, wie z.B. Tunneling
-
IP-Fragmentierung
-
Pakete, die ICMP-Nachrichten (Internet Control Message Protocol) vom RP oder SP erfordern
-
Maximum Transmission Unit (MTU)-Prüffehler
-
Pakete mit IP-Fehlern, darunter IP-Prüfsummen- und Längenfehler
-
Wenn die Eingangspakete einen Bitfehler zurückgeben (z. B. den Einzelbitfehler (SBE)), werden die Pakete zur Softwareverarbeitung an die CPU gesendet und korrigiert. Das System ordnet ihnen einen Puffer zu und verwendet die CPU-Ressource, um diesen zu korrigieren.
-
Befinden sich PBR und die reflexive Zugriffsliste im Pfad eines Datenverkehrsflusses, wird das Paket per Software-Switching weitergeleitet, was einen zusätzlichen CPU-Zyklus erfordert.
-
Adjacency, gleiche Schnittstelle
-
Pakete, die die RPF-Prüfung (Reverse Path Forwarding) nicht bestehen - rpf-failure
-
Erfassen/Empfangen
Glean bezieht sich auf Pakete, die eine ARP-Auflösung erfordern, und Receive auf Pakete, die in den Empfangsfall fallen.
-
Softwaregesteuerter Internetwork Packet Exchange (IPX)-Datenverkehr auf der Supervisor Engine 720 sowohl in Cisco IOS als auch in CatOS
IPX-Datenverkehr wird ebenfalls über die Software auf die Supervisor Engine 2/Cisco IOS-Software umgeschaltet, der Datenverkehr erfolgt jedoch über die Hardware auf die Supervisor Engine 2/CatOS. IPX-Datenverkehr wird auf der Supervisor Engine 1A für beide Betriebssysteme hardwaregesteuert.
-
AppleTalk-Datenverkehr
-
Vollständige Bedingungen für Hardware-Ressourcen
Zu diesen Ressourcen gehören FIB, Content-Addressable Memory (CAM) und Ternary CAM (TCAM).
ACL-basierte Funktionen
-
Bei aktivierter Funktion "ICMP Unreachables" (Unerreichbare ICMP) wird durch die Zugriffskontrollliste (ACL) abgelehnter Datenverkehr ausgeführt.
Hinweis: Dies ist die Standardeinstellung.
Einige Pakete mit abgelehnter ACL werden an die MSFC weitergeleitet, wenn nicht erreichbare IP aktiviert sind. Pakete, für die ICMP nicht erreichbar sein muss, werden mit einer vom Benutzer konfigurierbaren Rate geleakt. Standardmäßig beträgt die Rate 500 Pakete pro Sekunde (pps).
-
IPX-Filterung auf der Grundlage nicht unterstützter Parameter, z. B. Quell-Host
Auf der Supervisor Engine 720 ist der Prozess des Layer-3-IPX-Datenverkehrs immer in der Software enthalten.
-
Zugriffskontrolleinträge (ACEs), die eine Protokollierung erfordern, mit dem Schlüsselwort log
Dies gilt für ACL-Protokoll- und VLAN ACL-Protokollfunktionen (VACL). ACEs in derselben ACL, die keine Protokollierung erfordern, werden weiterhin in der Hardware verarbeitet. Die Supervisor Engine 720 mit PFC3 unterstützt die Durchsatzbegrenzung für Pakete, die zur ACL- und VACL-Protokollierung an die MSFC umgeleitet werden. Die Supervisor Engine 2 unterstützt die Durchsatzbegrenzung für Pakete, die zur VACL-Protokollierung an die MSFC umgeleitet werden. Die ACL-Protokollierung auf der Supervisor Engine 2 ist für die Cisco IOS Software-Version 12.2S geplant.
-
Von Richtlinien weitergeleiteter Datenverkehr mit Übereinstimmungslänge, festgelegter IP-Rangfolge oder anderen nicht unterstützten Parametern
Der Parameter set interface unterstützt die Software. Der Parameter set interface null 0 ist jedoch eine Ausnahme. Dieser Datenverkehr wird in der Hardware auf der Supervisor Engine 2 mit PFC2 und der Supervisor Engine 720 mit PFC3 verarbeitet.
-
Nicht-IP- und Nicht-IPX-Router-ACLs (RACLs)
Nicht-IP-RACLs gelten für alle Supervisor Engines. Die Nicht-IPX-RACLs gelten nur für die Supervisor Engine 1a mit PFC und die Supervisor Engine 2 mit PFC2.
-
In einer RACL abgelehnter Broadcast-Datenverkehr
-
Datenverkehr, der bei einer Unicast-RPF-Prüfung (uRPF) abgelehnt wird, ACL ACE
Diese uRPF-Prüfung gilt für die Supervisor Engine 2 mit PFC2 und die Supervisor Engine 720 mit PFC3.
-
Authentifizierungs-Proxy
Der Datenverkehr, der dem Authentifizierungsproxy unterliegt, kann auf der Supervisor Engine 720 mit einer Durchsatzbegrenzung versehen werden.
-
Cisco IOS Software IP Security (IPsec)
Datenverkehr, der einer Cisco IOS-Verschlüsselung unterliegt, kann über die Supervisor Engine 720 in der Durchsatzrate begrenzt werden.
NetFlow-basierte Funktionen
Die in diesem Abschnitt beschriebenen NetFlow-basierten Funktionen gelten nur für die Supervisor Engine 2 und die Supervisor Engine 720.
-
NetFlow-basierte Funktionen müssen immer das erste Paket eines Softwaredatenflusses sehen. Sobald das erste Paket des Datenflusses die Software erreicht, werden nachfolgende Pakete für denselben Datenfluss hardwaregesteuert.
Diese Ablaufanordnung gilt für reflexive Zugriffskontrolllisten, das Web Cache Communication Protocol (WCCP) und den Cisco IOS Server Load Balancing (SLB).
Hinweis: Auf der Supervisor Engine 1 sind reflexive Zugriffskontrolllisten auf dynamische TCAM-Einträge angewiesen, um Hardware-Verknüpfungen für einen bestimmten Datenfluss zu erstellen. Das Prinzip ist dasselbe: Das erste Paket eines Datenflusses wird an die Software übertragen. Die nachfolgenden Pakete für diesen Datenfluss werden per Hardware-Switching weitergeleitet.
-
Mit der TCP Intercept-Funktion werden der Drei-Wege-Handshake und das Schließen von Sitzungen in der Software verarbeitet. Der restliche Datenverkehr wird in der Hardware verarbeitet.
Hinweis: Synchronize (SYN)-, SYN acknowledged (SYN ACK)- und ACK-Pakete bilden den Drei-Wege-Handshake. Das Beenden der Sitzung erfolgt mit "Finish" (FIN) oder "Reset" (RST).
-
Network Address Translation (NAT) verarbeitet den Datenverkehr wie folgt:
-
Auf der Supervisor Engine 720:
Datenverkehr, der NAT erfordert, wird nach der Erstübersetzung in der Hardware verarbeitet. Die Übersetzung des ersten Pakets eines Datenflusses erfolgt in der Software, und nachfolgende Pakete für diesen Datenfluss werden per Hardware-Switching weitergeleitet. Bei TCP-Paketen wird nach Abschluss des TCP-Drei-Wege-Handshakes eine Hardware-Verknüpfung in der NetFlow-Tabelle erstellt.
-
Auf der Supervisor Engine 2 und der Supervisor Engine 1:
Sämtlicher Datenverkehr, der NAT erfordert, wird über Software weitergeleitet.
-
-
Die kontextbasierte Zugriffskontrolle (CBAC) verwendet NetFlow-Verknüpfungen zur Klassifizierung von Datenverkehr, der überprüft werden muss. Anschließend sendet CBAC nur diesen Datenverkehr an die Software. CBAC ist eine reine Software-Funktion. überprüfter Datenverkehr nicht hardwarebasiert ist.
Hinweis: Der zu überprüfende Datenverkehr kann auf die Supervisor Engine 720 ratenbeschränkt werden.
Multicast-Datenverkehr
-
Protocol Independent Multicast (PIM) Snooping
-
Internet Group Management Protocol (IGMP)-Snooping (TTL = 1)
Dieser Datenverkehr ist für den Router bestimmt.
-
Multicast Listener Discovery (MLD) Snooping (TTL = 1)
Dieser Datenverkehr ist für den Router bestimmt.
-
FIB-Fehler
-
Zur Registrierung bestimmte Multicast-Pakete, die eine direkte Verbindung zur Multicast-Quelle aufweisen
Diese Multicast-Pakete werden über Tunnel an den Rendezvous-Point geleitet.
-
IP Version 6 (IPv6) Multicast
Weitere Funktionen
-
Network-Based Application Recognition (NBAR)
-
ARP-Inspektion, nur mit CatOS
-
Port-Sicherheit, nur mit CatOS
-
DHCP-Snooping
IPv6-Situationen
-
Pakete mit einem Hop-by-Hop-Optionsheader
-
Pakete mit derselben Ziel-IPv6-Adresse wie die von Routern
-
Pakete, die die Überprüfung der Bereichsdurchsetzung nicht bestehen
-
Pakete, die die MTU der Ausgangsverbindung überschreiten
-
Pakete mit einer TTL kleiner oder gleich 1
-
Pakete mit einem Eingangs-VLAN, das dem Ausgangs-VLAN entspricht
-
IPv6 uRPF
Die Software führt diese uRPF für alle Pakete aus.
-
Reflexive IPv6-Zugriffskontrolllisten
Die Software verarbeitet diese reflexiven Zugriffskontrolllisten.
-
6to4-Präfixe für IPv6 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)-Tunnel
Die Software übernimmt dieses Tunneling. Der gesamte restliche Datenverkehr, der in einen ISATAP-Tunnel eingeht, ist hardwarebasiert.
LCP-Modul und DFC-Modul
Bei einer Distributed Forwarding Card (DFC) stellt der geplante Prozess lcp, der auf einer hohen CPU ausgeführt wird, kein Problem dar und wirft keine Probleme für den Betrieb auf. Der LCP-Zeitplan ist Teil des Firmware-Codes. Auf allen Modulen, die keine DFC erfordern, wird die Firmware auf einem bestimmten Prozessor ausgeführt, der als Line Card Processor (LCP) bezeichnet wird. Dieser Prozessor wird zur Programmierung der ASIC-Hardware und für die Kommunikation mit dem zentralen Supervisor-Modul verwendet.
Bei der Initiierung des lcp-Zeitplans nutzt es die gesamte Prozesszeit. Wenn ein neuer Prozess jedoch Prozessorzeit benötigt, gibt lcp schedular die Prozesszeit für den neuen Prozess frei. Die Leistungsfähigkeit des Systems wird durch diese hohe CPU-Auslastung nicht beeinträchtigt. Der Prozess erfasst einfach alle ungenutzten CPU-Zyklen, solange diese nicht für Prozesse mit höherer Priorität erforderlich sind.
DFC#show process cpu PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 22 0 1 0 0.00% 0.00% 0.00% 0 SCP ChilisLC Lis 23 0 1 0 0.00% 0.00% 0.00% 0 IPC RTTYC Messag 24 0 9 0 0.00% 0.00% 0.00% 0 ICC Slave LC Req 25 0 1 0 0.00% 0.00% 0.00% 0 ICC Async mcast 26 0 2 0 0.00% 0.00% 0.00% 0 RPC Sync 27 0 1 0 0.00% 0.00% 0.00% 0 RPC rpc-master 28 0 1 0 0.00% 0.00% 0.00% 0 Net Input 29 0 2 0 0.00% 0.00% 0.00% 0 Protocol Filteri 30 8 105 76 0.00% 0.00% 0.00% 0 Remote Console P 31 40 1530 26 0.00% 0.00% 0.00% 0 L2 Control Task 32 72 986 73 0.00% 0.02% 0.00% 0 L2 Aging Task 33 4 21 190 0.00% 0.00% 0.00% 0 L3 Control Task 34 12 652 18 0.00% 0.00% 0.00% 0 FIB Control Task 35 9148 165 55442 1.22% 1.22% 1.15% 0 Statistics Task 36 4 413 9 0.00% 0.00% 0.00% 0 PFIB Table Manag 37 655016 64690036 10 75.33% 77.87% 71.10% 0 lcp schedular 38 0 762 0 0.00% 0.00% 0.00% 0 Constellation SP
Häufige Ursachen und Lösungen bei Problemen mit der CPU-Auslastung
IP nicht erreichbar
Wenn eine Zugriffsgruppe ein Paket ablehnt, sendet die MSFC Nachrichten über ICMP Unreachable (Nicht erreichbar). Diese Aktion tritt standardmäßig auf.
Mit der Standardaktivierung des Befehls ip unreachables verwirft die Supervisor Engine die meisten abgelehnten Pakete in der Hardware. Anschließend sendet die Supervisor Engine nur eine kleine Anzahl von Paketen (maximal 10 pps) zur MSFC, die dann verworfen werden. Durch diese Aktion werden Meldungen generiert, dass ICMP nicht erreichbar ist.
Durch das Verwerfen abgelehnter Pakete und das Generieren von Nachrichten, die nicht über ICMP erreichbar sind, wird die CPU der MSFC belastet. Um die Last zu reduzieren, können Sie den Schnittstellenkonfigurationsbefehl no ip unreachables eingeben. Mit diesem Befehl werden Nachrichten deaktiviert, bei denen "ICMP nicht erreichbar" ist. Dadurch können alle Pakete, die von einer Zugriffsgruppe abgelehnt werden, in der Hardware gelöscht werden.
Wenn eine VACL ein Paket ablehnt, werden keine Nachrichten gesendet, die nicht über ICMP erreichbar sind.
NAT-Übersetzungen
NAT nutzt sowohl Hardware- als auch Softwareweiterleitung. Die Ersteinrichtung der NAT-Übersetzungen muss softwaremäßig erfolgen und die Weiterleitung erfolgt hardwaremäßig. NAT verwendet auch die NetFlow-Tabelle (max. 128 KB). Wenn die NetFlow-Tabelle voll ist, wendet der Switch daher auch die NAT-Weiterleitung über eine Software an. Dies geschieht normalerweise bei hohen Datenverkehrsspitzen und führt zu einem Anstieg der CPU auf 6500.
Verwendung des CEF-FIB-Tabellenbereichs in der Flow Cache-Tabelle
Die Supervisor Engine 1 verfügt über eine Flow Cache-Tabelle, die 128.000 Einträge unterstützt. Aufgrund der Effizienz des Hash-Algorithmus liegen diese Einträge jedoch zwischen 32.000 und 120.000. Auf der Supervisor Engine 2 wird die FIB-Tabelle generiert und in die PFC programmiert. Die Tabelle enthält bis zu 256.000 Einträge. Die Supervisor Engine 720 mit PFC3-BXL unterstützt bis zu 1.000.000 Einträge. Sobald dieser Speicherplatz überschritten wird, werden die Pakete über die Software weitergeleitet. Dies kann zu einer hohen CPU-Auslastung auf dem RP führen. Um die Anzahl der Routen in der CEF-FIB-Tabelle zu überprüfen, verwenden Sie die folgenden Befehle:
Router#show processes cpu
CPU utilization for five seconds: 99.26%
one minute: 100.00%
five minutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- --- ---------------
1 0 0 0 0.74% 0.00% 0.00% -2 Kernel and Idle
2 2 245 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
5 653 11737 1000 0.00% 0.00% 0.00% -2 SynDi
!--- Output is suppressed.
26 10576 615970 1000 0.00% 0.00% 0.00% 0 L3Aging
27 47432 51696 8000 0.02% 0.00% 0.00% 0 NetFlow
28 6758259 1060831 501000 96.62% 96.00% 96.00% 0 Fib
29 0 1 0 0.00% 0.00% 0.00% -2 Fib_bg_task
!--- Output is suppressed.
CATOS% show mls cef
Total L3 packets switched: 124893998234
Total L3 octets switched: 53019378962495
Total route entries: 112579
IP route entries: 112578
IPX route entries: 1
IPM route entries: 0
IP load sharing entries: 295
IPX load sharing entries: 0
Forwarding entries: 112521
Bridge entries: 56
Drop entries: 2
IOS% show ip cef summary
IP Distributed CEF with switching (Table Version 86771423), flags=0x0
112564 routes, 1 reresolve, 0 unresolved (0 old, 0 new)
112567 leaves, 6888 nodes, 21156688 bytes, 86771426
inserts, 86658859
invalidations
295 load sharing elements, 96760 bytes, 112359 references
universal per-destination load sharing algorithm, id 8ADDA64A
2 CEF resets, 2306608 revisions of existing leaves
refcounts: 1981829 leaf, 1763584 node
!--- You see these messages if the TCAM space is exceeded:
%MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
%MLSCEF-SP-7-END_FIB_EXCEPTION: FIB TCAM exception cleared, all CEF entries will be
hardware switched
Auf der Supervisor Engine 2 wird die Anzahl der FIB-Einträge auf die Hälfte reduziert, wenn Sie die RPF-Prüfung für die Schnittstellen konfiguriert haben. Diese Konfiguration kann dazu führen, dass mehr Pakete per Software umgeschaltet werden und die CPU-Auslastung daher hoch ist.
Um das Problem mit der hohen CPU-Auslastung zu beheben, aktivieren Sie die Routenzusammenfassung. Durch die Routenzusammenfassung kann die Latenz in einem komplexen Netzwerk minimiert werden, indem Prozessor-Workloads, Speicheranforderungen und Bandbreitenanforderungen reduziert werden.
Weitere Informationen zur TCAM-Nutzung und -Optimierung finden Sie unter Understanding ACL on Catalyst 6500 Series Switches.
Optimierte ACL-Protokollierung
Optimized ACL Logging (OAL) bietet Hardware-Unterstützung für die ACL-Protokollierung. Wenn Sie OAL nicht konfigurieren, findet der Prozess der Pakete, die protokolliert werden müssen, vollständig in der Software auf der MSFC3 statt. OAL lässt Pakete in der Hardware auf der PFC3 zu oder verwirft sie. OAL verwendet eine optimierte Routine, um Informationen an die MSFC3 zu senden, um die Protokollierungsnachrichten zu generieren.
Hinweis: Weitere Informationen zu OAL finden Sie im Abschnitt Optimized ACL Logging with a PFC3 (Optimierte ACL-Protokollierung mit einer PFC3) unter Understanding Cisco IOS ACL Support.
Durchsatzbegrenzer für Pakete an die CPU
Auf der Supervisor Engine 720 können Durchsatzbegrenzer die Geschwindigkeit steuern, mit der Pakete an die Software übertragen werden. Diese Durchsatzsteuerung hilft, Denial-of-Service-Angriffe zu verhindern. Sie können auf der Supervisor Engine 2 auch einige der folgenden Ratenlimitierungen verwenden:
Router#show mls rate-limit
Rate Limiter Type Status Packets/s Burst
--------------------- ---------- --------- -----
MCAST NON RPF Off - -
MCAST DFLT ADJ On 100000 100
MCAST DIRECT CON Off - -
ACL BRIDGED IN Off - -
ACL BRIDGED OUT Off - -
IP FEATURES Off - -
ACL VACL LOG On 2000 1
CEF RECEIVE Off - -
CEF GLEAN Off - -
MCAST PARTIAL SC On 100000 100
IP RPF FAILURE On 500 10
TTL FAILURE Off - -
ICMP UNREAC. NO-ROUTE On 500 10
ICMP UNREAC. ACL-DROP On 500 10
ICMP REDIRECT Off - -
MTU FAILURE Off - -
LAYER_2 PDU Off - -
LAYER_2 PT Off - -
IP ERRORS On 500 10
CAPTURE PKT Off - -
MCAST IGMP Off - -
Router(config)#mls rate-limit ?
all Rate Limiting for both Unicast and Multicast packets
layer2 layer2 protocol cases
multicast Rate limiting for Multicast packets
unicast Rate limiting for Unicast packets
Hier ein Beispiel:
Router(config)#mls rate-limit layer2 l2pt 3000
Führen Sie den folgenden Befehl aus, um die Durchsatzrate aller Pakete mit CEF-Test auf die MSFC zu begrenzen:
Router(config)#mls ip cef rate-limit 50000
Führen Sie den folgenden Befehl aus, um die Anzahl der Pakete zu reduzieren, die aufgrund von TTL=1 an die CPU gesendet werden:
Router(config)#mls rate-limit all ttl-failure 15
!--- where 15 is the number of packets per second with TTL=1. !--- The valid range is from 10 to 1000000 pps.
Dies ist z. B. die Ausgabe von netdr capture, die anzeigt, dass die IPv4-TTL 1 ist:
Source mac 00.00.50.02.10.01 3644 Dest mac AC.A0.16.0A.B0.C0 4092 Protocol 0800 4094 Interface Gi1/8 3644 Source vlan 0x3FD(1021) 3644 Source index 0x7(7) 3644 Dest index 0x380(896) 3654 L3 ipv4 source 211.204.66.117 762 ipv4 dest 223.175.252.49 3815 ipv4 ttl 1 3656 ipv6 source - 0 ipv6 dest - 0 ipv6 hoplt - 0 ipv6 flow - 0 ipv6 nexthdr - 0
Eine hohe CPU kann auch durch Pakete mit TTL=1 verursacht werden, die an die CPU durchgesickert sind. Um die Anzahl der Pakete zu begrenzen, die an die CPU durchgesickert sind, konfigurieren Sie einen Hardware-Ratenbegrenzer. Durchsatzbegrenzer können Pakete begrenzen, die vom Hardwaredatenpfad bis zum Softwaredatenpfad durchlaufen werden. Ratenlimitierungen schützen den Software-Steuerungspfad vor Überlastung, indem sie den Datenverkehr, der die konfigurierte Rate überschreitet, verwerfen. Die Ratenbeschränkung wird mit dem Befehl mls rate-limit all ttl-failure konfiguriert.
Physische Verschmelzung von VLANs aufgrund falscher Verkabelung
Eine hohe CPU-Auslastung kann auch durch das Zusammenführen von zwei oder mehr VLANs aufgrund einer falschen Verkabelung erzielt werden. Wenn STP auf den Ports deaktiviert wird, auf denen die VLAN-Fusion stattfindet, kann es außerdem zu einer hohen CPU-Auslastung kommen.
Um dieses Problem zu beheben, identifizieren Sie die Verkabelungsfehler, und beheben Sie diese. Wenn Ihre Anforderungen dies zulassen, können Sie STP auch auf diesen Ports aktivieren.
Broadcast-Sturm
Ein LAN-Broadcast-Sturm tritt auf, wenn Broadcast- oder Multicast-Pakete das LAN überfluten, was zu übermäßigem Datenverkehr führt und die Netzwerkleistung herabsetzt. Fehler in der Protokoll-Stack-Implementierung oder in der Netzwerkkonfiguration können einen Broadcast-Sturm verursachen.
Aufgrund des architektonischen Designs der Catalyst 6500-Plattform werden Broadcast-Pakete nur und immer auf Softwareebene verworfen.
Die Unterdrückung von Broadcasts verhindert die Unterbrechung der LAN-Schnittstellen durch einen Broadcast-Sturm. Die Broadcast-Unterdrückung verwendet eine Filterung, die die Broadcast-Aktivität in einem LAN über einen Zeitraum von 1 Sekunde misst und die Messung mit einem vordefinierten Grenzwert vergleicht. Wird der Grenzwert erreicht, werden weitere Broadcast-Aktivitäten für die Dauer eines vorgegebenen Zeitraums unterdrückt. Die Unterdrückung von Broadcasts ist standardmäßig deaktiviert.
Hinweis: VRRP-Flapping von Backup zu Master, das durch Broadcast-Stürme verursacht wird, kann eine hohe CPU-Auslastung verursachen.
Informationen zur Funktionsweise der Unterdrückung von Broadcasts und zum Aktivieren der Funktion finden Sie unter:
-
Konfigurieren der Unterdrückung des Broadcasts (Cisco IOS-Systemsoftware)
-
Konfigurieren der Unterdrückung von Broadcasts (CatOS-Systemsoftware)
BGP Next-Hop-Adressenverfolgung (BGP-Scanner-Prozess)
Der BGP-Scanner-Prozess leitet die BGP-Tabelle weiter und bestätigt die Erreichbarkeit der nächsten Hops. Bei diesem Prozess wird auch die bedingte Ankündigung überprüft, um festzustellen, ob BGP Bedingungspräfixe ankündigen und/oder eine Routen-Dampening-Funktion ausführen soll. Standardmäßig werden alle 60 Sekunden Scans durchgeführt.
Der BGP Scanner-Prozess auf einem Router, der über eine große Internet-Routing-Tabelle verfügt, sorgt für eine hohe CPU-Auslastung für kurze Zeiträume. Einmal pro Minute durchläuft der BGP Scanner die RIB-Tabelle (BGP Routing Information Base) und führt wichtige Wartungsaufgaben durch. Zu diesen Aufgaben gehören:
-
Prüfung des nächsten Hop, der in der Router-BGP-Tabelle referenziert wird
-
Überprüfung, ob die Next-Hop-Geräte erreicht werden können
Daher dauert es bei einer großen BGP-Tabelle ähnlich lange, bis sie durchlaufen und validiert wird. Der BGP-Scanner-Prozess durchläuft die BGP-Tabelle, um Datenstrukturen zu aktualisieren, und durchläuft die Routing-Tabelle zu Zwecken der Routen-Neuverteilung. Beide Tabellen werden separat im Router-Speicher abgelegt. Beide Tabellen können sehr groß sein und verbrauchen daher CPU-Zyklen.
Weitere Informationen zur CPU-Auslastung durch den BGP Scanner-Prozess finden Sie im Abschnitt Hohe CPU-Auslastung aufgrund von BGP Scanner im Abschnitt Fehlerbehebung Hohe CPU-Auslastung durch den BGP Scanner- oder BGP Router-Prozess.
Weitere Informationen zur BGP Next-Hop Address Tracking-Funktion und zum Verfahren zum Aktivieren/Deaktivieren oder Anpassen des Scan-Intervalls finden Sie unter BGP Support for Next-Hop Address Tracking (BGP-Unterstützung für Next-Hop-Adresstracking).
Nicht-RPF-Multicast-Datenverkehr
Multicast-Routing (im Gegensatz zu Unicast-Routing) betrifft nur die Quelle eines bestimmten Multicast-Datenstroms. Dies ist die IP-Adresse des Geräts, von dem der Multicast-Verkehr stammt. Das Grundprinzip ist, dass das Quellgerät den Stream an eine undefinierte Anzahl von Empfängern (innerhalb seiner Multicast-Gruppe) "herausschiebt". Alle Multicast-Router erstellen Distribution Trees, die den Pfad steuern, über den Multicast-Datenverkehr durch das Netzwerk geleitet wird, um Datenverkehr an alle Empfänger weiterzuleiten. Die beiden grundlegenden Typen von Multicast Distribution Trees sind Source Trees und Shared Trees. RPF ist ein Schlüsselkonzept für die Multicast-Weiterleitung. Router können Multicast-Datenverkehr korrekt über den Distribution Tree weiterleiten. RPF verwendet die vorhandene Unicast-Routing-Tabelle, um die Upstream- und Downstream-Nachbarn zu bestimmen. Ein Router leitet Multicast-Pakete nur dann weiter, wenn sie von der Upstream-Schnittstelle empfangen werden. Diese RPF-Prüfung trägt dazu bei, dass der Distribution Tree schleifenfrei ist.
Multicast-Datenverkehr ist gemäß IEEE 802.3 CSMA/CD-Spezifikation für jeden Router in einem überbrückten (Layer 2) LAN sichtbar. Beim 802.3-Standard wird Bit 0 des ersten Oktetts verwendet, um einen Broadcast- und/oder Multicast-Frame anzugeben, und jeder Layer-2-Frame mit dieser Adresse wird geflutet. Dies gilt auch dann, wenn CGMP- oder IGMP-Snooping konfiguriert sind. Der Grund hierfür ist, dass Multicast-Router den Multicast-Datenverkehr sehen müssen, wenn von ihnen eine korrekte Weiterleitungsentscheidung erwartet wird. Wenn mehrere Multicast-Router über Schnittstellen zu einem gemeinsamen LAN verfügen, leitet nur ein Router die Daten weiter (wird durch einen Auswahlprozess ausgewählt). Aufgrund der Überflutung von LANs erhält der redundante Router (der den Multicast-Verkehr nicht weiterleitet) diese Daten über die Ausgangsschnittstelle für das LAN. Der redundante Router verwirft diesen Datenverkehr normalerweise, da er an der falschen Schnittstelle angekommen ist und daher die RPF-Prüfung nicht besteht. Dieser bei der RPF-Prüfung nicht erfolgreiche Datenverkehr wird als Nicht-RPF-Datenverkehr oder RPF-Fehlerpakete bezeichnet, da er rückwärts an den Fluss von der Quelle übertragen wurde.
Catalyst 6500 mit MSFC kann als vollwertiger Multicast-Router konfiguriert werden. Bei Verwendung von Multicast Multi-Layer Switching (MMLS) wird RPF-Datenverkehr in der Regel von der Hardware innerhalb des Switches weitergeleitet. Die ASICs erhalten Informationen aus dem Multicast-Routing-Zustand ( z. B. (*,G) und (S,G) ), sodass eine Hardware-Verknüpfung in die NetFlow- und/oder FIB-Tabelle programmiert werden kann. Dieser Nicht-RPF-Datenverkehr ist in einigen Fällen weiterhin erforderlich und wird von der MSFC-CPU (auf Prozessebene) für den PIM-Assert-Mechanismus benötigt. Andernfalls wird sie vom Software-Fast-Switching-Pfad gelöscht (hierbei wird davon ausgegangen, dass das Software-Fast-Switching auf der RPF-Schnittstelle nicht deaktiviert ist).
Der redundante Catalyst 6500 kann in bestimmten Topologien Datenverkehr ohne RPF möglicherweise nicht effizient verarbeiten. Für Nicht-RPF-Datenverkehr liegt in der Regel kein (*,G)- oder (S,G)-Status im redundanten Router vor. Daher können keine Hardware- oder Software-Verknüpfungen zum Verwerfen des Pakets erstellt werden. Jedes Multicast-Paket muss vom MSFC-Routingprozessor einzeln geprüft werden. Dies wird häufig als CPU-Interrupt-Datenverkehr bezeichnet. Mit Layer-3-Hardware-Switching und mehreren Schnittstellen/VLANs, die denselben Router verbinden, wird der Nicht-RPF-Datenverkehr, der die CPU der redundanten MSFC erreicht, um das "N"-fache der ursprünglichen Quellrate erhöht (wobei "N" die Anzahl der LANs ist, mit denen der Router redundant verbunden ist). Wenn die Rate des Nicht-RPF-Datenverkehrs die Paketverwerfungskapazität des Systems übersteigt, kann dies zu einer hohen CPU-Auslastung, Pufferüberläufen und einer allgemeinen Netzwerkinstabilität führen.
Der Catalyst 6500 verfügt über eine Zugriffslisten-Engine, die eine Filterung mit Leitungsgeschwindigkeit ermöglicht. Diese Funktion kann in bestimmten Situationen zur effizienten Verarbeitung von Nicht-RPF-Datenverkehr für Sparse Mode-Gruppen verwendet werden. Sie können das ACL-basierte Verfahren nur in Sparse-Mode-Stub-Netzwerken verwenden, in denen es keine Downstream-Multicast-Router (und die entsprechenden Empfänger) gibt. Aufgrund des Designs für die Paketweiterleitung des Catalyst 6500 können intern redundante MSFCs diese Implementierung nicht verwenden. Dies ist in der Cisco Bug-ID CSCdr74908 beschrieben (nur für registrierte Kunden). Bei Gruppen im Dense-Modus müssen Nicht-RPF-Pakete auf dem Router sichtbar sein, damit der PIM-Assert-Mechanismus ordnungsgemäß funktioniert. Verschiedene Lösungen wie CEF oder NetFlow-basierte Durchsatzratenbegrenzung und QoS werden zur Kontrolle von RPF-Ausfällen in Netzwerken mit hoher Dichte und Sparse-Mode-Transitnetzwerken eingesetzt.
Der Catalyst 6500 verfügt über eine Zugriffslisten-Engine, die eine Filterung mit Leitungsgeschwindigkeit ermöglicht. Mit dieser Funktion kann Nicht-RPF-Datenverkehr für Sparse Mode-Gruppen effizient verarbeitet werden. Um diese Lösung zu implementieren, platzieren Sie eine Zugriffsliste auf der Eingangsschnittstelle des `Stub-Netzwerks', um Multicast-Datenverkehr zu filtern, der nicht vom `Stub-Netzwerk' stammt. Die Zugriffsliste wird auf die Switch-Hardware übertragen. Diese Zugriffsliste verhindert, dass die CPU das Paket jemals sieht, und ermöglicht der Hardware, den Nicht-RPF-Datenverkehr zu verwerfen.
Hinweis: Platzieren Sie diese Zugriffsliste nicht auf einer Übertragungsschnittstelle. Es ist nur für Stub-Netzwerke bestimmt (nur Netzwerke mit Hosts).
Weitere Informationen finden Sie in folgenden Dokumenten:
show-Befehle
Die CPU-Auslastung bei Ausgabe des Befehls show beträgt immer fast 100 %. Es ist normal, eine hohe CPU-Auslastung zu haben, wenn Sie einen show-Befehl ausgeben und dieser normalerweise nur für einige Sekunden beibehalten wird.
Es ist z. B. normal, dass der Virtual Exec-Prozess einen hohen Wert aufweist, wenn Sie den Befehl show tech-support eingeben, da diese Ausgabe interruptgesteuert ist. Ihre einzige Sorge ist die hohe CPU in anderen Prozessen als show-Befehlen.
Der Befehl show cef not-cef-switched gibt an, warum Pakete an die MSFC gesendet werden (Empfangen, IP-Option, keine Adjacency usw.) und wie viele. Beispiele:
Switch#show cef not-cef-switched CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag RP 6222 0 136 0 60122 0 0 0 5 0 0 0 0 0 0 0 0 IPv6 CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access MTU RP 0 0 0 0 0 0 0 0
Die Befehle show ibc und show ibc brief zeigen die CPU-Warteschlange an und können verwendet werden, wenn Sie den CPU-Status überwachen.
Prozesse der Führungskräfte
Der Exec-Prozess in der Cisco IOS-Software ist für die Kommunikation auf den TTY-Leitungen (Konsole, Hilfsaggregat, asynchron) des Routers verantwortlich. Der Virtual Exec-Prozess ist für die VTY-Leitungen (Telnet-Sitzungen) zuständig. Die Exec- und Virtual Exec-Prozesse sind Prozesse mit mittlerer Priorität. Wenn es also andere Prozesse gibt, die eine höhere Priorität haben (hoch oder kritisch), erhalten die Prozesse mit höherer Priorität die CPU-Ressourcen.
Wenn viele Daten über diese Sitzungen übertragen werden, erhöht sich die CPU-Auslastung für den Exec-Prozess. Der Grund hierfür ist, dass der Router einige CPU-Ressourcen verwendet, wenn er ein einfaches Zeichen über diese Zeilen senden möchte:
-
Für die Konsole (Exec) verwendet der Router einen Interrupt pro Zeichen.
-
Für die VTY-Leitung (Virtual Exec) muss die Telnet-Sitzung ein TCP-Paket pro Zeichen erstellen.
In dieser Liste werden einige mögliche Gründe für die hohe CPU-Auslastung im Exec-Prozess aufgeführt:
-
Es werden zu viele Daten über den Konsolenport gesendet.
-
Überprüfen Sie mit dem Befehl show debugging, ob Debugging auf dem Router gestartet wurde.
-
Deaktivieren Sie die Konsolenprotokollierung auf dem Router, indem Sie keine Form des Befehls logging console eingeben.
-
Überprüfen Sie, ob eine lange Ausgabe auf der Konsole ausgegeben wird. Beispielsweise ein Befehl show tech-support oder ein Befehl show memory.
-
-
Der Befehl exec wird für asynchrone und Hilfslinien konfiguriert.
-
Wenn eine Leitung nur ausgehenden Datenverkehr enthält, deaktivieren Sie den Executive-Prozess für diese Leitung. Wenn nämlich das Gerät (z. B. ein Modem), das an diese Leitung angeschlossen ist, unerwünschte Daten sendet, beginnt der Prozess auf dieser Leitung.
-
Wenn der Router als Terminalserver (für Telnet-Reverse-Verbindungen zu anderen Gerätekonsolen) verwendet wird, wird empfohlen, den Befehl no exec auf den Leitungen zu konfigurieren, die mit der Konsole der anderen Geräte verbunden sind. Daten, die von der Konsole zurückkommen, können andernfalls einen Exec-Prozess starten, der CPU-Ressourcen verwendet.
-
Ein möglicher Grund für die hohe CPU-Auslastung im Virtual Exec-Prozess ist:
-
Es werden zu viele Daten über die Telnet-Sitzungen gesendet.
Der häufigste Grund für die hohe CPU-Auslastung im Virtual Exec-Prozess ist, dass zu viele Daten vom Router zur Telnet-Sitzung übertragen werden. Dies kann passieren, wenn Befehle mit langen Ausgaben wie show tech-support, show memory usw. von der Telnet-Sitzung aus ausgeführt werden. Die Menge der über jede VTY-Sitzung übertragenen Daten kann mit dem Befehl show tcp vty <Zeilennummer> überprüft werden.
L3-Alterungsprozess
Wenn der L3-Alterungsprozess eine große Anzahl von Ifindex-Werten mithilfe von NetFlow Data Export (NDE) exportiert, kann die CPU-Auslastung 100 % erreichen.
Wenn dieses Problem auftritt, überprüfen Sie, ob diese beiden Befehle aktiviert sind:
set mls nde destination-ifindex enable
set mls nde source-ifindex enable
Wenn Sie diese Befehle aktivieren, muss der Prozess alle Ziel- und Quellindexwerte mithilfe von NDE exportieren. Die Auslastung des L3-Alterungsprozesses ist hoch, da für alle Ziel- und Quell-Ifindex-Werte eine FIB-Suche durchgeführt werden muss. Dadurch ist die Tabelle voll, der L3-Alterungsprozess ist erfolgreich, und die CPU-Auslastung erreicht 100 %.
Um dieses Problem zu beheben, deaktivieren Sie die folgenden Befehle:
set mls nde destination-ifindex disable
set mls nde source-ifindex disable
Verwenden Sie die folgenden Befehle, um die Werte zu überprüfen:
BPDU-Sturm
Spanning Tree unterhält eine schleifenfreie Layer-2-Umgebung in redundanten Switching- und Bridge-Netzwerken. Ohne STP schleifen und/oder multiplizieren Frames unbegrenzt. Dieses Ereignis verursacht einen Netzwerkzusammenbruch, da hoher Datenverkehr alle Geräte in der Broadcast-Domäne unterbricht.
STP ist in mancher Hinsicht ein frühes Protokoll, das ursprünglich für langsame softwarebasierte Bridge-Spezifikationen (IEEE 802.1D) entwickelt wurde. STP kann jedoch kompliziert sein, um es erfolgreich in großen Switch-Netzwerken mit folgenden Funktionen zu implementieren:
-
Viele VLANs
-
Viele Switches in einer STP-Domäne
-
Unterstützung unterschiedlicher Anbieter
-
Neuere IEEE-Erweiterungen
Wenn das Netzwerk häufigen Spanning-Tree-Berechnungen ausgesetzt ist oder der Switch mehr BPDUs verarbeiten muss, kann dies zu einer hohen CPU-Auslastung und BPDU-Verlusten führen.
Um diese Probleme zu umgehen, führen Sie einen oder alle der folgenden Schritte aus:
-
Trennen Sie die VLANs von den Switches.
-
Verwenden Sie eine erweiterte Version von STP, z. B. MST.
-
Aktualisieren Sie die Switch-Hardware.
Beachten Sie auch die Best Practices zur Implementierung des Spanning Tree Protocol im Netzwerk.
SPAN-Sitzungen
Auf der Grundlage der Architektur der Catalyst Switches der Serien 6000/6500 haben SPAN-Sitzungen keinen Einfluss auf die Switch-Leistung. Wenn die SPAN-Sitzung jedoch einen Port für hohen Datenverkehr/Uplink oder einen EtherChannel enthält, kann dies die Prozessorlast erhöhen. Wenn dann ein bestimmtes VLAN ausgewählt wird, erhöht sich die Arbeitslast noch weiter. Wenn die Verbindung fehlerhaften Datenverkehr enthält, kann dies die Arbeitslast weiter erhöhen.
In einigen Szenarien kann die RSPAN-Funktion Schleifen verursachen, und die Last auf dem Prozessor nimmt zu. Weitere Informationen finden Sie unter Why Does the SPAN Session Create a Bridging Loop?
Der Switch kann den Datenverkehr wie gewohnt weiterleiten, da alles in der Hardware enthalten ist. Die CPU kann jedoch einige Schläge hinnehmen, wenn sie versucht herauszufinden, welcher Datenverkehr durchgeleitet werden soll. Es wird empfohlen, SPAN-Sitzungen nur dann zu konfigurieren, wenn dies erforderlich ist.
%CFIB-SP-STBY-7-CFIB_EXCEPTION: FIB TCAM-Ausnahme, einige Einträge werden softwareumgeschaltet
%CFIB-SP-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched
Diese Fehlermeldung wird angezeigt, wenn der verfügbare TCAM-Speicherplatz überschritten wird. Dies führt zu einer hohen CPU-Auslastung. Hierbei handelt es sich um eine FIB-TCAM-Einschränkung. Sobald der TCAM voll ist, wird eine Markierung gesetzt, und es wird eine FIB-TCAM-Ausnahme empfangen. Dadurch wird verhindert, dass dem TCAM neue Routen hinzugefügt werden. Daher wird alles Software-Switching sein. Das Entfernen von Routen hilft nicht, das Hardware-Switching wieder aufzunehmen. Sobald der TCAM in den Ausnahmezustand wechselt, muss das System neu geladen werden, um diesen Zustand zu beenden. Die maximale Anzahl von Routen, die im TCAM installiert werden können, wird durch den Befehl mls cef maximum-routes erhöht.
Catalyst 6500/6000 mit hoher CPU-Auslastung verfügt über eine IPv6-ACL mit L4-Ports
Aktivieren Sie mls ipv6 acl compress address unicast . Dieser Befehl ist erforderlich, wenn die IPv6-ACL mit den L4-Protokoll-Portnummern übereinstimmt. Wenn dieser Befehl nicht aktiviert ist, wird der IPv6-Datenverkehr zur Softwareverarbeitung an die CPU gesendet. Dieser Befehl ist nicht standardmäßig konfiguriert.
Kupfer-SPFs
Bei Cisco Ethernet-Switches der Serie ME 6500 erfordern SFPs mit Kupferverbindung mehr Firmware-Interaktion als andere SFPs, was die CPU-Auslastung erhöht.
Die Softwarealgorithmen zur Verwaltung von Kupfer-SFPs wurden in den Cisco IOS SXH-Versionen verbessert.
Modulares IOS
Bei Cisco Catalyst Switches der Serie 6500, auf denen modulare IOS-Software ausgeführt wird, ist die normale CPU-Auslastung etwas höher als bei nicht modularer IOS-Software.
Modulare IOS-Software zahlt pro Aktivität einen höheren Preis als pro Paket. Die modulare IOS-Software erhält die Prozesse aufrecht, indem sie eine bestimmte CPU verbraucht, selbst wenn nicht viele Pakete vorhanden sind. Der CPU-Verbrauch basiert daher nicht auf dem tatsächlichen Datenverkehr. Wenn jedoch Pakete mit hoher Geschwindigkeit verarbeitet werden, sollte die in der modularen IOS-Software verbrauchte CPU nicht höher als die in der nicht modularen IOS-Software sein.
CPU-Auslastung überprüfen
Wenn die CPU-Auslastung hoch ist, geben Sie zuerst den Befehl show processes cpu ein. Die Ausgabe zeigt Ihnen die CPU-Auslastung auf dem Switch sowie den CPU-Verbrauch pro Prozess.
Router#show processes cpu CPU utilization for five seconds: 57%/48%; one minute: 56%; five minutes: 48% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 5 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 12 18062 0 0.00% 0.00% 0.00% 0 Load Meter 4 164532 13717 11994 0.00% 0.21% 0.17% 0 Check heaps 5 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager !--- Output is suppressed. 172 0 9 0 0.00% 0.00% 0.00% 0 RPC aapi_rp 173 243912 2171455 112 9.25% 8.11% 7.39% 0 SNMP ENGINE 174 68 463 146 0.00% 0.00% 0.00% 0 RPC pm-mp !--- Output is suppressed.
In dieser Ausgabe beträgt die CPU-Auslastung insgesamt 57 Prozent und die Interrupt-CPU-Auslastung 48 Prozent. Diese Prozentsätze werden hier fett dargestellt. Der Interrupt-Wechsel des Datenverkehrs durch die CPU verursacht die Interrupt-CPU-Auslastung. In der Befehlsausgabe werden die Prozesse aufgeführt, die den Unterschied zwischen den beiden Auslastungen verursachen. In diesem Fall ist die Ursache der SNMP-Prozess.
Auf der Supervisor Engine, die CatOS ausführt, sieht die Ausgabe wie folgt aus:
Switch> (enable) show processes cpu
CPU utilization for five seconds: 99.72%
one minute: 100.00%
five minutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- --- ---------------
1 0 0 0 0.28% 0.00% 0.00% -2 Kernel and Idle
2 2 261 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
!--- Output is suppressed.
61 727295 172025 18000 0.82% 0.00% 0.00% -2 SptTimer
62 18185410 3712736 106000 22.22% 21.84% 21.96% -2 SptBpduRx
63 845683 91691 105000 0.92% 0.00% 0.00% -2 SptBpduTx
In dieser Ausgabe lautet der erste Prozess "Kernel and Idle" (Kernel und Idle) und zeigt die CPU-Auslastung im Leerlauf an. Dieser Prozess ist normalerweise sehr hoch, es sei denn, einige andere Prozesse beanspruchen CPU-Zyklen. In diesem Beispiel verursacht der SptBpduRx-Prozess eine hohe CPU-Auslastung.
Wenn die CPU-Auslastung aufgrund eines dieser Prozesse hoch ist, können Sie eine Fehlerbehebung durchführen und feststellen, warum dieser Prozess hoch ist. Wenn die CPU jedoch aufgrund von Datenverkehr, der an die CPU gesendet wird, hoch ist, müssen Sie bestimmen, warum der Datenverkehr gesendet wird. Diese Bestimmung kann Ihnen helfen, den Datenverkehr zu identifizieren.
Verwenden Sie zur Fehlerbehebung dieses EEM-Skriptbeispiel, um die Ausgabe des Switches bei hoher CPU-Auslastung zu erfassen:
event manager applet cpu_stats event snmp oid "1.3.6.1.4.1.9.9.109.1.1.1.1.3.1" get-type exact entry-op gt entry-val "70" exit-op lt exit-val "50" poll-interval 5 action 1.01 syslog msg "------HIGH CPU DETECTED----, CPU:$_snmp_oid_val%" action 1.02 cli command "enable" action 1.03 cli command "show clock | append disk0:cpu_stats" action 1.04 cli command "show proc cpu sort | append disk0:cpu_stats" action 1.05 cli command "Show proc cpu | exc 0.00% | append disk0:cpu_stats" action 1.06 cli command "Show proc cpu history | append disk0:cpu_stats" action 1.07 cli command "show logging | append disk0:cpu_stats " action 1.08 cli command "show spanning-tree detail | in ieee|occurr|from|is exec | append disk0:cpu_stats" action 1.09 cli command "debug netdr cap rx | append disk0:cpu_stats" action 1.10 cli command "show netdr cap | append disk0:cpu_stats" action 1.11 cli command "undebug all" !
Hinweis: Der Befehl debug netdr capture rx ist hilfreich, wenn die CPU aufgrund von Prozess-Switching von Paketen und nicht aufgrund von Hardware sehr hoch ist. Er erfasst 4096 Pakete, die bei Ausführung des Befehls an die CPU eingehen. Der Befehl ist absolut sicher und ist das bequemste Werkzeug für hohe CPU-Probleme auf dem 6500. Die CPU wird nicht zusätzlich belastet.
Utilitys und Tools zur Bestimmung des Datenverkehrs, der an die CPU gesendet wird
In diesem Abschnitt werden einige Dienstprogramme und Tools beschrieben, die Ihnen helfen können, diesen Datenverkehr zu analysieren.
Cisco IOS-Systemsoftware
In der Cisco IOS Software wird der Switch-Prozessor in der Supervisor Engine als SP bezeichnet, und die MSFC wird als RP bezeichnet.
Der Befehl show interface liefert grundlegende Informationen zum Status der Schnittstelle und zur Datenverkehrsrate auf der Schnittstelle. Der Befehl stellt außerdem Fehlerindikatoren bereit.
Router#show interface gigabitethernet 4/1
GigabitEthernet4/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000a.42d1.7580 (bia 000a.42d1.7580)
Internet address is 100.100.100.2/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 5/75/1/24075 (size/max/drops/flushes); Total output drops: 2
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 7609000 bits/sec, 14859 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 0 pkt, 184954624 bytes - mcast: 1 pkt, 500 bytes
L3 in Switched: ucast: 2889916 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
2982871 packets input, 190904816 bytes, 0 no buffer
Received 9 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 1 CRC, 0 frame, 28 overrun, 0 ignored
0 input packets with dribble condition detected
1256 packets output, 124317 bytes, 0 underruns
2 output errors, 1 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
In dieser Ausgabe sehen Sie, dass der eingehende Datenverkehr über Layer 3 geleitet wird und nicht über Layer 2. Dies zeigt an, dass der Datenverkehr an die CPU gesendet wird.
Der Befehl show processes cpu gibt an, ob es sich bei diesen Paketen um reguläre Datenverkehrspakete oder Kontrollpakete handelt.
Router#show processes cpu | exclude 0.00 CPU utilization for five seconds: 91%/50%; one minute: 89%; five minutes: 47% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 5 881160 79142 11133 0.49% 0.19% 0.16% 0 Check heaps 98 121064 3020704 40 40.53% 38.67% 20.59% 0 IP Input 245 209336 894828 233 0.08% 0.05% 0.02% 0 IFCOM Msg Hdlr
Wenn die Pakete prozessgesteuert sind, stellen Sie fest, dass der IP-Eingabeprozess sehr umfangreich ist. Geben Sie diesen Befehl ein, um die folgenden Pakete anzuzeigen:
show buffers Eingabeschnittstelle
Router#show buffers input-interface gigabitethernet 4/1 packet Buffer information for Small buffer at 0x437874D4 data_area 0x8060F04, refcount 1, next 0x5006D400, flags 0x280 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x505BC20C (GigabitEthernet4/1), if_output 0x0 (None) inputtime 00:00:00.000 (elapsed never) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x8060F7A, datagramsize 60, maximum size 308 mac_start 0x8060F7A, addr_start 0x8060F7A, info_start 0x0 network_start 0x8060F88, transport_start 0x8060F9C, caller_pc 0x403519B4 source: 100.100.100.1, destination: 100.100.100.2, id: 0x0000, ttl: 63, TOS: 0 prot: 17, source port 63, destination port 63 08060F70: 000A 42D17580 ..BQu. 08060F80: 00000000 11110800 4500002E 00000000 ........E....... 08060F90: 3F11EAF3 64646401 64646402 003F003F ?.jsddd.ddd..?.? 08060FA0: 001A261F 00010203 04050607 08090A0B ..&............. 08060FB0: 0C0D0E0F 101164 ......d
Wenn der Datenverkehr Interrupt Switched ist, können Sie diese Pakete mit dem Befehl show buffers input-interface nicht sehen. Um die Pakete anzuzeigen, die an den RP gesendet werden, um das Switching zu unterbrechen, können Sie eine SPAN-Erfassung (Switched Port Analyzer) des RP-Ports durchführen.
Hinweis: Weitere Informationen zur CPU-Auslastung mit Interrupt-Switching und der CPU-Auslastung mit Prozess-Switching finden Sie in diesem Dokument:
-
Hohe CPU-Auslastung aufgrund des Abschnitts "Interrupts" zur Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern
SPAN RP-Inband und SP-Inband
Ein SPAN für den RP- oder SP-Port der Cisco IOS Software ist in Version 12.1(19)E der Cisco IOS Software und höher verfügbar.
Dies ist die Befehlssyntax:
test monitor session 1-66 add {rp-inband | sp-inband} [rx | tx | both]
Verwenden Sie diese Syntax für die Cisco IOS Software 12.2 SX-Versionen:
test monitor add {1..66} {rp-inband | sp-inband} {rx | tx | both}
Hinweis: Für die SXH-Version müssen Sie den Befehl monitor session verwenden, um eine lokale SPAN-Sitzung zu konfigurieren, und dann diesen Befehl verwenden, um die SPAN-Sitzung mit der CPU zu verknüpfen:
source {cpu {rp | sp}} | single_interface | interface_list |
interface_range | mixed_interface_list | single_vlan |
vlan_list | vlan_range | mixed_vlan_list} [rx | tx | both]
Hinweis: Weitere Informationen zu diesen Befehlen finden Sie unter Configuring Local SPAN (SPAN Configuration Mode) im Catalyst 6500 Release 12.2SX Software Configuration Guide.
Hier ein Beispiel für eine RP-Konsole:
Router#monitor session 1 source interface fast 3/3 !--- Use any interface that is administratively shut down. Router#monitor session 1 destination interface 3/2
Wechseln Sie jetzt zur SP-Konsole. Hier ein Beispiel:
Router-sp#test monitor session 1 add rp-inband rx
Hinweis: In Cisco IOS 12.2 SX-Versionen wurde der Befehl test monitor add 1 rp-inband rx geändert.
Router#show monitor Session 1 --------- Type : Local Session Source Ports : Both : Fa3/3 Destination Ports : Fa3/2 SP console: Router-sp#test monitor session 1 show Ingress Source Ports: 3/3 15/1 Egress Source Ports: 3/3 Ingress Source Vlans: <empty> Egress Source Vlans: <empty> Filter Vlans: <empty> Destination Ports: 3/2
Hinweis: In Cisco IOS 12.2 SX-Versionen wurde der Befehl test monitor show 1 (Testmonitor anzeigen) geändert.
Hier ist ein Beispiel für eine SP-Konsole:
Router-sp#test monitor session 1 show Ingress Source Ports: 3/3 15/1 Egress Source Ports: 3/3 Ingress Source Vlans: <empty> Egress Source Vlans: <empty> Filter Vlans: <empty> Destination Ports: 3/2
CatOS-Systemsoftware
Auf Switches, auf denen die CatOS-Systemsoftware ausgeführt wird, wird CatOS in der Supervisor Engine und Cisco IOS Software in MSFC ausgeführt.
Wenn Sie den Befehl show mac ausführen, können Sie die Anzahl der Frames anzeigen, die an die MSFC gesendet werden. Port 15/1 ist die Verbindung der Supervisor Engine zur MSFC.
Hinweis: Der Port ist 16/1 für Supervisor Engines in Steckplatz 2.
Console> (enable) show mac 15/1 Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast -------- -------------------- -------------------- -------------------- 15/1 193576 0 1 Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast -------- -------------------- -------------------- -------------------- 15/1 3 0 0 Port Rcv-Octet Xmit-Octet -------- -------------------- -------------------- 15/1 18583370 0 MAC Dely-Exced MTU-Exced In-Discard Out-Discard -------- ---------- ---------- ---------- ----------- 15/1 0 - 0 0
Ein schneller Anstieg dieser Zahl zeigt an, dass Pakete an die MSFC gesendet werden, was zu einer hohen CPU-Auslastung führt. Sie können die Pakete dann folgendermaßen betrachten:
SPAN MSFC-Port 15/1 oder 16/1
Richten Sie eine SPAN-Sitzung ein, bei der die Quelle der MSFC-Port 15/1 (oder 16/1) und das Ziel ein Ethernet-Port ist.
Hier ein Beispiel:
Console> (enable) set span 15/1 5/10 Console> (enable) show span Destination : Port 5/10 Admin Source : Port 15/1 Oper Source : None Direction : transmit/receive Incoming Packets: disabled Learning : enabled Multicast : enabled Filter : - Status : active
Wenn Sie eine Sniffer-Ablaufverfolgung auf Port 5/10 sammeln, zeigt die Sniffer-Ablaufverfolgung Pakete an, die an die MSFC gesendet bzw. von dieser gesendet werden. Konfigurieren Sie die SPAN-Sitzung als tx, um Pakete zu erfassen, die nur an die MSFC und nicht an die MSFC gerichtet sind.
SPAN sc0
Richten Sie eine SPAN-Sitzung mit der sc0-Schnittstelle als Quelle ein, um Frames zu erfassen, die an die Supervisor Engine-CPU gehen.
Console> (enable) set span ? disable Disable port monitoring sc0 Set span on interface sc0 <mod/port> Source module and port numbers <vlan> Source VLAN numbers
Hinweis: Bei optischen Dienstmodulen (OSMs) kann keine SPAN-Erfassung des Datenverkehrs durchgeführt werden.
Empfehlungen
Die CPU-Auslastung der Supervisor Engine spiegelt nicht die Hardware-Weiterleitungsleistung des Switches wider. Dennoch müssen Sie die CPU-Auslastung der Supervisor Engine als Baseline festlegen und überwachen.
-
Die CPU-Auslastung der Supervisor Engine für den Switch wird in einem Netzwerk mit konstantem Zustand und normalen Datenverkehrsmustern und normaler Auslastung als Ausgangswert berechnet.
Beachten Sie, welche Prozesse die höchste CPU-Auslastung generieren.
-
Bei der Fehlerbehebung bei der CPU-Auslastung sollten Sie folgende Fragen berücksichtigen:
-
Welche Prozesse generieren die höchste Auslastung? Unterscheiden sich diese Prozesse von Ihrer Ausgangsbasis?
-
Ist die CPU über die Baseline hinweg konstant erhöht? Oder gibt es Spitzen bei hoher Auslastung und dann eine Rückkehr zu den Basiswerten?
-
Sind Benachrichtigungen zu Topologieänderungen (TCNs) im Netzwerk vorhanden?
Hinweis: Flapping-Ports oder Host-Ports mit deaktiviertem STP PortFast verursachen TCNs.
-
Ist in den Management-Subnetzen/VLAN übermäßiger Broadcast- oder Multicast-Verkehr vorhanden?
-
Ist auf dem Switch übermäßiger Verwaltungsdatenverkehr wie SNMP Polling vorhanden?
-
-
Erfassen Sie während der hohen CPU-Zeit (wenn die CPU 75 % oder mehr beträgt) die Ausgabe der folgenden Befehle:
-
Isolieren Sie, falls möglich, das Management-VLAN von den VLANs durch Benutzerdatenverkehr, insbesondere starken Broadcast-Verkehr.
Beispiele für diese Art von Datenverkehr sind IPX RIP/Service Advertising Protocol (SAP), AppleTalk und anderer Broadcast-Verkehr. Dieser Datenverkehr kann sich auf die CPU-Nutzung der Supervisor Engine auswirken und in Extremfällen den normalen Betrieb des Switches beeinträchtigen.
-
Wenn die CPU aufgrund des geringen Datenverkehrs zum RP sehr hoch läuft, ermitteln Sie, um was es sich bei dem Datenverkehr handelt und warum dieser Datenverkehr unterbrochen wird.
Verwenden Sie für diese Bestimmung die Dienstprogramme, die im Abschnitt Dienstprogramme und Tools zum Ermitteln des Datenverkehrs, der an die CPU gesendet wird, beschrieben werden.
Zugehörige Informationen
- Nützliche Befehle zur Fehlerbehebung bei hohen CPU-Auslastungen an Catalyst 6500 mit Sup720
- Häufige CatOS-Fehlermeldungen bei Switches der Catalyst 6000/6500-Serie
- Allgemeine Fehlermeldungen zu Catalyst Switches der Serien 6500/6000 mit Cisco IOS Software
- Fehlerbehebung bei Hardware und allgemeinen Problemen mit Catalyst Switches der Serien 6500/6000 mit Cisco IOS-Systemsoftware
- Unicast Flooding in Switched Campus-Netzwerken
- Produktsupport für Cisco Catalyst Switches der Serie 6500
- EEM-Skript zum Sammeln von Daten während eines zeitweilig hohen CPU-Problems
- LAN-Produkt-Support
- Support für LAN-Switching-Technologie
- Technischer Support und Dokumentation für Cisco Systeme
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
11-Feb-2005
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)