Fehlerbehebung bei Abstürzen der Linecard auf dem Cisco Internet Router der Serie 12000

 

Einleitung

Dieses Dokument enthält Informationen zur Fehlerbehebung bei Abstürzen von Line Cards auf dem Cisco Internet Router der Serie 12000.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Alle Cisco Internet Router der Serie 12000, einschließlich der Router 12008, 12012, 12016, 12404, 12406, 12410 und 12416

• Alle Cisco IOS® Softwareversionen, die den Cisco Internet Router der Serie 12000 unterstützen.

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.

Konventionen

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

Hintergrundinformationen

Dieser Abschnitt enthält Hintergrundinformationen zum Identifizieren eines Absturzes einer Linecard.

Identifizieren eines Line Card-Absturzes

Um einen Absturz einer Linecard schnell zu erkennen, verwenden Sie den Befehl show context summary:

   Router#show context summary 
       CRASH INFO SUMMARY 
         Slot 0 : 0 crashes 
         Slot 1 : 0 crashes 
         Slot 2 : 0 crashes 
         Slot 3 : 0 crashes 
         Slot 4 : 1 crashes 
           1 - crash at 04:28:56 EDT Tue Apr 20 1999 
         Slot 5 : 0 crashes 
         Slot 6 : 0 crashes 
         Slot 7 : 0 crashes 
         Slot 8 : 0 crashes 
         Slot 9 : 0 crashes 
         Slot 10: 0 crashes 
         Slot 11: 0 crashes

Wenn der Absturz den Router selbst betrifft (und nicht nur die Linecard), lesen Sie Troubleshooting Router Crashes (Fehlerbehebung bei Router-Abstürzen).

Sammeln von Informationen über den Absturz

Um die relevanten Daten über den Absturz zu sammeln, verwenden Sie die Befehle in Tabelle 1.

Tabelle 1: Befehle zum Sammeln von Daten über den Absturz

Command	Beschreibung
show version	Enthält allgemeine Informationen zur Hardware- und Softwarekonfiguration des Systems.
show logging	Zeigt die allgemeinen Protokolle des Routers an.
Diag anzeigen [Steckplatz Nr.]	Stellt spezifische Informationen zu einem bestimmten Steckplatz bereit: Modultyp, Hardwareversionen, Speicherkonfiguration usw.
show context slot [Steckplatz Nr.]	Stellt Kontextinformationen über den/die letzten Absturz(e) bereit. Dies ist häufig der nützlichste Befehl zur Behebung von Abstürzen von Linecards.
Kernablagerung	Ein Core Dump einer Linecard ist der vollständige Inhalt des Speichers zum Zeitpunkt des Absturzes. Diese Daten werden normalerweise nicht für eine erste Fehlerbehebung benötigt. Es kann später erforderlich sein, wenn sich herausstellt, dass das Problem ein neuer Softwarefehler ist. Weitere Informationen hierzu finden Sie unter Konfigurieren eines Core Dump auf einer GSR Line Card.

Wenn Sie die Ausgabe eines Befehls show tech-support (aus dem privilegierten Modus) von Ihrem Cisco Gerät haben, können Sie Folgendes verwenden: um potenzielle Probleme und Korrekturen anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, eingeloggt sein und JavaScript aktivieren.

Analysieren der erfassten Daten

Überprüfen Sie den Wert des Felds sig= in der Ausgabe von show context slot [slot#]:

       Router#show context slot 4 
       CRASH INFO: Slot 4, Index 1, Crash at 04:28:56 EDT Tue Apr 20 1999 

       VERSION: 
       GS Software (GLC1-LC-M), Version 11.2(15)GS1a, EARLY DEPLOYMENT RELEASE 
       SOFTWARE (fc1) 
       Compiled Mon 28-Dec-98 14:53 by tamb 
       Card Type: 1 Port Packet Over SONET OC-12c/STM-4c, S/N CAB020500AL 
       System exception: SIG=20, code=0xA414EF5A, context=0x40337424 

       Traceback Using RA 
       STACK TRACE: 
         traceback 4014CFC0 40141AB8 40143944 4014607C 4014A7EC 401499D4 40149BB4 
       40149FD4 40080118 40080104 
       CONTEXT: 
       $0 : 00000000, AT : 40330000, v0 : 00000000, v1 : 00000038 
       a0 : 4094EF58, a1 : 00000120, a2 : 00000002, a3 : 00000001 
       t0 : 00000010, t1 : 3400BF01, t2 : 34008D00, t3 : FFFF00FF 
       t4 : 400A1410, t5 : 00000002, t6 : 00000000, t7 : 4041783C 
       s0 : 4093F980, s1 : 4093F980, s2 : 4094EEF0, s3 : 4094EF00 
       s4 : 00000000, s5 : 00000001, s6 : 00000000, s7 : 00000000 
       t8 : 34008000, t9 : 00000000, k0 : 404D1860, k1 : 400A2F68 
       gp : 402F3070, sp : 4082BFB0, s8 : 00000000, ra : 400826FC 
       EPC : 0x40098824, SREG : 0x3400BF04, Cause : 0x00000000 
       ErrorEPC : 0x4015B7E4

In Tabelle 2 finden Sie die Fehlerursache, die mit dem von Ihnen aufgezeichneten SIG-Wert übereinstimmt.

Tabelle 2: Identifizieren des Fehlers, der mit dem SIG-Wert übereinstimmt

SIG-Wert	SIG-Name	Fehlergrund
2	UNTERZEICHNEN	Unerwartete Hardware-Unterbrechung.
3	SIQUIT	Abbruch wegen Schlüssel-Bruch.
4	SIGILL	Unzulässige opcode-Ausnahme.
5	SIGTRAP	Abbruch aufgrund eines Unterbrechungspunkts oder einer arithmetischen Ausnahme.
8	SIGFPE	Gleitkommaeinheit (FPU)-Ausnahme.
9	SIGKILL	Reservierte Ausnahme.
10	SIGBUS	Bus-Fehlerausnahme.
11	SIGSEGV	SegV-Ausnahme.
20	SIGCACHE	Cache-Paritätsausnahme.
21	SIGWBERR	Schreibbusfehler-Interrupt.
22	SIGERROR	Schwerwiegender Hardwarefehler.
23	SIGRELOAD	Software-erzwungener Absturz.

Hinweis: Mehr als 95 % der Linecard-Abstürze sind auf Cache-Paritätsausnahmen (SIG=20), Busfehlerausnahmen (SIG=10) und softwareerzwungene Abstürze (SIG=23) zurückzuführen.

Der Befehl diag exec

Die Cisco Serie 12000 unterstützt den Befehl diag [slot#] zum Testen der verschiedenen Mainboard-Komponenten. Dieser Befehl ist nützlich, um Hardwareabstürze zu beheben und fehlerhafte Platinen zu identifizieren.

Die Option verbose bewirkt, dass der Router die Liste der ausgeführten Tests anzeigt. Andernfalls wird lediglich die Meldung "PASSED" (erfolgreich) oder "FAILURE" (Fehler) angezeigt.

Hinweis: Bei dieser Diagnose werden alle Aktivitäten der Linecard für die Dauer der Tests (in der Regel etwa fünf Minuten) gestoppt.

Ab Version 12.0(22)S der Cisco IOS-Software hat Cisco das Linecard-Image für die Felddiagnose des Cisco Internet Routers der Serie 12000 aus dem Cisco IOS-Software-Image entbündelt. In früheren Versionen konnte die Diagnose über die Befehlszeile gestartet werden, und das integrierte Image wurde gestartet. Um Kunden mit 20-MB-Flash-Speicherkarten zu unterstützen, wird die Linecard-Felddiagnose jetzt als separates Image gespeichert und verwaltet, das auf einer Flash-Speicherkarte oder einem TFTP-Boot-Server (Trivial File Transfer Protocol) verfügbar sein muss, bevor die Felddiagnosebefehle verwendet werden können. Die Felddiagnose für Router-Prozessor und Switch-Fabric ist weiterhin in Paketen verfügbar und muss nicht von einem separaten Image gestartet werden. Weitere Informationen finden Sie unter Felddiagnose für den Cisco Internet Router der Serie 12000.

Hier ist ein Beispiel für eine Diag-Befehlsausgabe [slot#]:

Router#diag 3 verbose 
Running DIAG config check 
Running Diags will halt ALL activity on the requested slot. 
[confirm] 
CR1.LND10# 
Launching a Field Diagnostic for slot 3 
Downloading diagnostic tests to slot 3 (timeout set to 400 sec.) 
Field Diag download COMPLETE for slot 3 
FD 3> ***************************************************** 
FD 3> GSR Field Diagnostics V3.0 
FD 3> Compiled by award on Tue Aug 3 15:58:13 PDT 1999 
FD 3> view: award-bfr_112.FieldDiagRelease 
FD 3> ***************************************************** 
FD 3> BFR_CARD_TYPE_OC48_1P_POS testing... 
FD 3> running in slot 3 (128 tests) 

Executing all diagnostic tests in slot 3 
(total/indiv. timeout set to 600/200 sec.) 
FD 3> Verbosity now (0x00000001) TESTSDISP 

FDIAG_STAT_IN_PROGRESS: test #1 R5K Internal Cache 
FDIAG_STAT_IN_PROGRESS: test #2 Burst Operations 
FDIAG_STAT_IN_PROGRESS: test #3 Subblock Ordering 
FDIAG_STAT_IN_PROGRESS: test #4 Dram Marching Pattern 
FDIAG_STAT_DONE_FAIL test_num 4, error_code 6 
Field Diagnostic: ****TEST FAILURE**** slot 3: last test run 4, 
Dram Marching Pattern, error 6 
Field Diag eeprom values: run 2 fail mode 1 (TEST FAILURE) slot 3 
last test failed was 4, error code 6 
Shutting down diags in slot 3 

slot 3 done, will not reload automatically

Je nach aufgetretenem Fehler wird der Steckplatz möglicherweise nicht automatisch neu geladen. Ist dies nicht der Fall, befindet sich die Komponente möglicherweise in einem blockierten oder inkonsistenten Zustand (überprüfen Sie dies mit dem Befehl show diag [slot #]), bis sie manuell neu geladen wird. Das ist normal. Um die Karte manuell neu zu laden, verwenden Sie den Befehl hw-module slot [slot#] reload.

Cache-Paritätsausnahmen

Sie können Cache-Paritätsausnahmen anhand von SIG=20 in der Ausgabe von show context [slot #] identifizieren.

Wenn Sie die Ausgabe eines Befehls show tech-support (aus dem privilegierten Modus) von Ihrem Cisco Gerät haben, können Sie Folgendes verwenden: um potenzielle Probleme und Korrekturen anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, eingeloggt sein und JavaScript aktivieren.

Es gibt zwei verschiedene Arten von Paritätsfehlern:

• Weiche Paritätsfehler - Diese treten auf, wenn sich der Energiepegel innerhalb des Chips (z. B. eine Eins oder Null) ändert. Im Falle eines weichen Paritätsfehlers müssen Sie die Platine oder eine der Komponenten nicht austauschen.

• Harte Paritätsfehler - Diese treten auf, wenn ein Chip- oder Platinenfehler vorliegt, der zu einer Beschädigung der Daten führt. In diesem Fall sollten Sie die betroffene Komponente wieder einsetzen oder austauschen, in der Regel einen Speicherchip-Austausch oder einen Motherboard-Austausch. Wenn mehrere Paritätsfehler an derselben Adresse auftreten, liegt ein schwerwiegender Paritätsfehler vor. Es gibt kompliziertere Fälle, die schwieriger zu erkennen sind, aber im Allgemeinen kann, wenn in einem bestimmten Speicherbereich in relativ kurzer Zeit (mehrere Wochen bis Monate) mehr als ein Paritätsfehler festgestellt wird, dies als harter Paritätsfehler betrachtet werden.

Studien haben gezeigt, dass weiche Paritätsfehler 10 bis 100 Mal häufiger auftreten als harte Paritätsfehler.

Um diese Fehler zu beheben, rufen Sie ein Wartungsfenster auf, in dem Sie den Befehl diag für diesen Steckplatz ausführen können.

• Wenn die Diagnose zu einem Fehler führt, ersetzen Sie die Linecard.

• Wenn kein Fehler auftritt, handelt es sich wahrscheinlich um einen weichen Paritätsfehler, und die Linecard muss nicht ausgetauscht werden (es sei denn, sie stürzt nach kurzer Zeit ein zweites Mal mit einem Paritätsfehler ab).

Bus-Fehlerausnahmen

Busfehlerausnahmen können Sie anhand von SIG=10 in der Ausgabe von show context [slot #] identifizieren.

Wenn Sie die Ausgabe eines Befehls show tech-support (aus dem privilegierten Modus) von Ihrem Cisco Gerät haben, können Sie Folgendes verwenden: um potenzielle Probleme und Korrekturen anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, eingeloggt sein und JavaScript aktivieren.

Diese Art von Absturz ist normalerweise softwarebezogen, aber wenn Sie aus irgendeinem Grund (z. B. weil es sich um eine brandneue Karte handelt oder die Abstürze nach einem Stromausfall beginnen) denken, dass das Problem hardwarebezogen sein könnte, führen Sie den Befehl diag für diesen Steckplatz aus.

Hinweis: Einige Software-Bugs verursachen bekanntermaßen diag-Befehle, um Fehler zu melden, obwohl es kein Problem mit der Hardware gibt. Wenn eine Karte bereits ausgetauscht wurde, aber beim gleichen Test in der Diagnose immer noch fehlschlägt, ist dieses Problem möglicherweise für Sie relevant. Behandeln Sie den Absturz in diesem Fall als Softwareproblem.

Durch ein Upgrade auf die neueste Version Ihrer Cisco IOS-Software-Version werden alle behobenen Fehler vermieden, die zu Line Card-Bus-Fehlern führen. Wenn der Absturz auch nach dem Upgrade noch auftritt, sammeln Sie die relevanten Informationen (siehe Sammeln von Informationen über den Absturz), zeigen Sie technischen Support und alle Informationen, die Sie für nützlich halten (z. B. kürzlich erfolgte Topologieänderungen oder kürzlich implementierte neue Funktionen), und wenden Sie sich an Ihren Cisco Support-Ansprechpartner.

Software-erzwungene Abstürze

Software-erzwungene Abstürze können Sie in der Ausgabe von show context [slot #] mit SIG=23 identifizieren. Trotz des Namens sind diese Abstürze nicht immer softwarebezogen.

Wenn Sie die Ausgabe eines Befehls show tech-support (aus dem privilegierten Modus) von Ihrem Cisco Gerät haben, können Sie Folgendes verwenden: um potenzielle Probleme und Korrekturen anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, eingeloggt sein und JavaScript aktivieren.

Der häufigste Grund für Software-erzwungene Abstürze ist das "Fabric Ping Timeout". Im normalen Router-Betrieb pingt der Route Processor (RP) kontinuierlich die Line Cards an. Wenn eine Linecard nicht antwortet, entscheidet der Routingprozessor, sie zurückzusetzen. Dies führt zu einem Software-erzwungenen Absturz (SIG=23) der betroffenen Linecard. Sie sollten diese Fehler in den Routerprotokollen sehen:

Mar 12 00:42:48: %GRP-3-FABRIC_UNI: 
Unicast send timed out (4) 
Mar 12 00:42:50: %GRP-3-COREDUMP: Core dump incident on slot 4, error: Fabric ping failure

Um Fabric-Ping-Timeouts zu beheben, müssen Sie herausfinden, warum die Linecard nicht auf den Ping reagiert hat. Dies kann mehrere Ursachen haben:

• Die Linecard weist eine hohe CPU-Auslastung auf - Dies kann mit dem Befehl execute-on slot [slot #] show proc cpu überprüft werden. Wenn die CPU-Auslastung wirklich hoch ist (über 95 %), finden Sie weitere Informationen unter Troubleshooting High CPU Utilization on Cisco Routers (Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern).

• Bei Inter Process Communication (IPC) gibt es Softwarefehler, oder auf der Linecard sind keine IPC-Puffer mehr vorhanden. Meistens werden diese Software-erzwungenen Neuladevorgänge durch Software-Fehler verursacht.

  Durch ein Upgrade auf die neueste Version Ihrer Cisco IOS Software-Release Train werden alle behobenen Fehler vermieden, die Fabric-Ping-Timeouts verursachen. Wenn der Absturz auch nach dem Upgrade noch auftritt, sammeln Sie die relevanten Informationen (siehe Informationen über den Absturz), zeigen Sie technischen Support, show ipc Status und alle Informationen, die Sie für nützlich halten (z. B. kürzlich erfolgte Topologieänderung oder kürzlich implementierte neue Funktion), und wenden Sie sich an Ihren Cisco Support-Ansprechpartner.

• Hardwarefehler - Wenn die Karte lange Zeit fehlerfrei ausgeführt wurde und keine kürzlich erfolgten Topologie-, Software- oder Funktionsänderungen vorgenommen wurden oder wenn die Probleme nach einem Umzug oder einem Stromausfall begannen, kann defekte Hardware die Ursache sein. Führen Sie den Befehl diag auf der betroffenen Linecard aus. Ersetzen Sie die Linecard, falls defekt. Wenn mehrere Linecards betroffen sind oder die Diagnose funktioniert, ersetzen Sie das Fabric.

%GSRSPA-6-ERRORRECOVER: Hardware- oder Softwarefehler im Substeckplatz 0.Reason Marvel: Automatische TXECCERR-Fehlerwiederherstellung initiieren

TXECCERR/RXECCERR-Fehler tritt auf, wenn RxFIFO oder TxFIFO nicht wiederherstellbare ECC-Fehler-Unterbrechung tritt in MAC mehr als der Schwellenwert innerhalb des Zeitintervalls. Nicht behebbare ECC-Fehler können von der ECC-Logik nicht korrigiert werden. Wenn während des Lesens von RxFIFO ein nicht behebbarer Fehler auftritt, wird das Paket, zu dem die Daten gehören, auf der SPI4-Empfangsschnittstelle mit EOP/Abort markiert und von den oberen Schichten verworfen.

Dies ist auf die Hardware zurückzuführen und wird korrigiert, sobald SIP/SPA neu geladen wurde. Die permanente Lösung besteht darin, das SIP/SPA zu ersetzen, um die Fehler zu vermeiden.

Andere Abstürze

Andere Crashtypen sind bei weitem weniger verbreitet als die beiden oben genannten. In den meisten Fällen sollte der Befehl diag angeben, ob die Karte ersetzt werden muss oder nicht. Wenn die Karte den Diagnosetest erfolgreich besteht, sollten Sie ein Upgrade der Software in Betracht ziehen.

Zu erfassende Informationen, wenn Sie eine TAC-Serviceanfrage stellen

Wenn Sie nach dem Durchführen der oben genannten Schritte zur Fehlerbehebung weiterhin Unterstützung benötigen und eine Serviceanfrage (nur für registrierte Kunden) beim Cisco TAC eröffnen möchten, stellen Sie sicher, dass Sie die folgenden Informationen angeben:

Fehlerbehebung vor dem Öffnen der Serviceanfrage durchgeführt. Ausgabe des technischen Supports anzeigen (möglichst im Aktivierungsmodus). Zeigt die Protokollausgabe oder Konsolenerfassungen an, falls verfügbar. execute-on slot [slot #] show tech für den slot, bei dem die Line Card abstürzte. Hängen Sie die gesammelten Daten in nicht gezippter Textform (.txt) an Ihre Serviceanfrage an. Sie können Ihrer Serviceanfrage Informationen hinzufügen, indem Sie sie mit dem TAC Service Request Tool hochladen (nur für registrierte Kunden). Wenn Sie nicht auf das Service Request Tool zugreifen können, können Sie die Informationen in einem E-Mail-Anhang an attach@cisco.com senden, wobei Ihre Service Request-Nummer in der Betreffzeile Ihrer Nachricht angegeben ist. Hinweis: Bevor Sie die oben genannten Informationen erfassen, sollten Sie den Router nicht manuell neu laden oder aus- und wieder einschalten, es sei denn, dies ist erforderlich, um einen Absturz der Linecards auf dem Cisco Internet Router der Serie 12000 zu beheben, da dies dazu führen kann, dass wichtige Informationen verloren gehen, die zur Bestimmung der Ursache des Problems erforderlich sind.

Zugehörige Informationen

• Fehlerbehebung: Router stürzt ab
• Konfigurieren eines Core Dump auf einer GSR Line Card
• Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern
• Technischer Support und Dokumentation für Cisco Systeme