Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundinformationen

Identifizieren eines Line Card-Crash

Sammeln von Informationen zum Crash

Analyse der erfassten Daten

Der Befehl diag Exec

Cache Parity-Ausnahmen

Busfehler-Ausnahmen

Software-erzwungene Abstürze

%GSRSPA-6-FEHLERWIEDERHERSTELLUNG: Ein Hardware- oder Software-Fehler ist in Untersteckplatz 0 aufgetreten.Grund: Bemerkung: Automatische Fehlerwiederherstellung von TXECCERR initiiert

Andere Abstürze

Informationen, die beim Öffnen einer TAC-Serviceanfrage gesammelt werden müssen

Zugehörige Informationen

Einführung

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

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

- Alle Cisco Internet Router der Serie 1200, 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 wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

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

Hintergrundinformationen

In diesem Abschnitt finden Sie Hintergrundinformationen zum Identifizieren eines Line Card-Crashs.

Identifizieren eines Line Card-Crash

Um einen Line Card-Crash schnell zu identifizieren, 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 sich der Absturz auf den Router selbst (und nicht nur auf die Linecard) auswirkt, finden Sie weitere Informationen unter Fehlerbehebung bei Router-Abstürzen.

Sammeln von Informationen zum Crash

Verwenden Sie zum Erfassen der relevanten Daten zum Absturz die in Tabelle 1 aufgeführten Befehle.

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

Befehl

Beschreibung

Anzeigeversion

Bietet allgemeine Informationen zu den Hardware- und Softwarekonfigurationen des Systems.

Anzeigeprotokollierung

Zeigt die allgemeinen Protokolle des Routers an.

show diag [Steckplatz #]

Enthält spezifische Informationen zu einem bestimmten Steckplatz: Engine, Hardware-Revisionen, Speicherkonfiguration usw.

show context slot [Steckplatz #]

Stellt Kontextinformationen zu den letzten Abstürzen bereit. Dies ist häufig der nützlichste Befehl zur Fehlerbehebung bei Abstürzen von Linecards.

Core Dump

Ein Core-Dump einer Line Card ist der vollständige Inhalt des Arbeitsspeichers zum Zeitpunkt des Absturzes. Diese Daten werden normalerweise für eine erste Fehlerbehebung nicht benötigt. Es kann später erforderlich sein, wenn sich das Problem als neuer Softwarefehler herausstellt. In diesem Fall finden Sie weitere Informationen unter Konfigurieren eines Core Dump auf einer GSR Line Card.

Wenn der Befehl show tech-support (im Aktivierungsmodus) von Ihrem Cisco Gerät ausgegeben wird, können Sie um potenzielle Probleme und Bugfixes anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Sie können Output Interpreter verwenden, um potenzielle Probleme und Fixes anzuzeigen. Um Output Interpreter verwenden zu können, müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Analyse der erfassten Daten

Überprüfen Sie den Wert des sig=-Felds im Anzeigekontextslot [slot#] Ausgabe:

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 erfahren Sie, warum der Fehler mit dem von Ihnen erfassten SIG-Wert übereinstimmt.

Tabelle 2: Ermitteln des Fehlers, der dem SIG-Wert entspricht

SIG-Wert

SIG-Name

Fehlerursache

2

UNTERZEICHNEN

Unerwartete Hardware-Unterbrechung.

1

SIGNIEREN

Abbrechen aufgrund von Unterbrechungstaste.

4

UNTERZEICHNEN

Illegale Opcode-Ausnahme.

5

UNTERZEICHNEN

Wird aufgrund von Break Point oder einer arithmetischen Ausnahme abgebrochen.

8

SIGNFPE

Floating Point Unit (FPU)-Ausnahme.

9

SCHILD

Reservierte Ausnahme.

10

SIGBUS

Busfehler-Ausnahme.

11

SIGSEGV

SegV-Ausnahme.

20

SIGCACHE

Cache-Paritätsausnahme.

21

SIGWBERR

Busfehler unterbrechen.

22

GEFÄLSCHER

Schwerwiegender Hardwarefehler.

23

SIGNRELOAD

Software-erzwungener Crash.

Hinweis: Die Ausnahme für Cache Parity (SIG=20), die Ausnahme für Busfehler (SIG=10) und Software-erzwungene Abstürze (SIG=23) machen mehr als 95 % der Line Card-Abstürze aus.

Der Befehl diag Exec

Die Cisco Serie 12000 unterstützt den Befehl diag [slot#] zum Testen der verschiedenen Motherboard-Komponenten. Dieser Befehl ist hilfreich, um Hardware-bezogene Abstürze zu beheben und die fehlerhafte Platine zu identifizieren.

Die ausführliche Option veranlasst den Router, die Liste der Tests während der Ausführung anzuzeigen. Andernfalls wird nur die Meldung "PASSED" (GEHÖRT) oder "FAILURE" (AUSFALL) angezeigt.

Hinweis: Bei dieser Diagnose werden alle Aktivitäten der Linecard während der Testdauer (in der Regel etwa fünf Minuten) gestoppt.

Ab der Cisco IOS Software-Version 12.0(22)S hat Cisco das Line Card-Image für die Felddiagnose des Cisco Internet Routers der Serie 1200 vom Cisco IOS Software-Image entpackt. In früheren Versionen konnte die Diagnose über die Befehlszeile gestartet werden, und das eingebettete Bild wurde gestartet. Um Kunden mit 20 MB Flash-Speicherkarten zu ermöglichen, werden die Linecard-Felddiagnosen jetzt als separates Image gespeichert und verwaltet, das auf einer Flash-Speicherkarte oder einem TFTP-Bootserver (Trivial File Transfer Protocol) verfügbar sein muss, bevor die Felddiagnosebefehle verwendet werden können. Die Felddiagnosen für Router-Prozessor und Switch-Fabric werden weiterhin gebündelt und müssen nicht von einem separaten Image aus gestartet werden. Weitere Informationen finden Sie unter Felddiagnosen für den Cisco Internet Router der Serie 12000.

Hier ein Beispiel für eine diag [slot#] Befehlsausgabe:

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 automatisch neu geladen. Ist dies nicht der Fall, befindet er sich möglicherweise in einem Zustand, der inkonsistent ist (überprüfen Sie dies mit dem Befehl show diag [slot #]), bis er manuell neu geladen wird. Das ist normal. Um die Karte manuell neu zu laden, verwenden Sie den Befehl hw-module-Steckplatz [slot#] reload.

Cache Parity-Ausnahmen

Sie können Cache-Paritätsausnahmen durch SIG=20 im Anzeigekontext [Steckplatz #] identifizieren.

Wenn der Befehl show tech-support (im Aktivierungsmodus) von Ihrem Cisco Gerät ausgegeben wird, können Sie um potenzielle Probleme und Bugfixes anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Sie können Output Interpreter verwenden, um potenzielle Probleme und Fixes anzuzeigen. Um Output Interpreter verwenden zu können, müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Es gibt zwei verschiedene Arten von Paritätsfehlern:

- Weiche Paritätsfehler - Diese treten auf, wenn sich ein Energielevel im Chip (z. B. ein oder Null) ändert. Bei einem weichen Paritätsfehler muss die Platine oder eine der Komponenten nicht ausgetauscht werden.

- Harte Paritätsfehler - Diese treten auf, wenn ein Chip- oder Mainboard-Fehler auftritt, der die Beschädigung von Daten zur Folge hat. In diesem Fall sollten Sie die betroffene Komponente, in der Regel einen Speicherchip-Austausch oder einen Plateauwechsel, wieder einsetzen oder austauschen. Wenn mehrere Paritätsfehler an derselben Adresse festgestellt werden, tritt ein schwerer Paritätsfehler auf. Es gibt kompliziertere Fälle, die schwieriger zu identifizieren sind, aber im Allgemeinen, wenn in einer bestimmten Speicherregion in relativ kurzer Zeit (mehrere Wochen bis Monate) mehr als ein Paritätsfehler auftritt, kann 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, suchen Sie ein Wartungsfenster, um den Befehl diag für diesen Steckplatz auszuführen.

- Wenn die Diagnose zu einem Ausfall führt, ersetzen Sie die Linecard.

- Wenn kein Fehler auftritt, ist dies wahrscheinlich ein unflexibler Paritätsfehler, und die Linecard muss nicht ersetzt werden (es sei denn, sie stürzt ein zweites Mal mit Paritätsfehler nach kurzer Zeit ab).

Busfehler-Ausnahmen

Sie können Ausnahmen für Busfehler anhand von SIG=10 im Anzeigekontext [Steckplatz #] identifizieren.

Wenn der Befehl show tech-support (im Aktivierungsmodus) von Ihrem Cisco Gerät ausgegeben wird, können Sie um potenzielle Probleme und Bugfixes anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Sie können Output Interpreter verwenden, um potenzielle Probleme und Fixes anzuzeigen. Um Output Interpreter verwenden zu können, müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Dieser Crash-Typ ist normalerweise softwarebezogen, aber wenn Sie aus irgendeinem Grund (z. B. eine brandneue Karte, oder die Abstürze beginnen nach einem Stromausfall) der Meinung sind, dass das Problem hardwarebezogen sein könnte, führen Sie den Befehl diag für diesen Steckplatz aus.

Hinweis: Einige Software-Fehler haben bekanntermaßen dazu geführt, dass der diag-Befehl Fehler meldet, obwohl es kein Problem mit der Hardware gibt. Wenn eine Karte bereits ausgetauscht wurde, aber bei demselben Diagnosetest immer noch fehlschlägt, kann dieses Problem Sie betreffen. Behandeln Sie den Absturz in diesem Fall als Softwareproblem.

Durch ein Upgrade auf die neueste Version Ihres Cisco IOS-Software-Release-Train werden alle behobenen Fehler beseitigt, die Line Card-Busfehler verursachen. Wenn der Absturz nach dem Upgrade immer noch auftritt, sammeln Sie die relevanten Informationen (siehe Sammeln von Informationen über den Absturz) zusammen mit einem technischen Support, sowie alle Informationen, die Sie für nützlich erachten (z. B. kürzlich durchgeführte Topologieänderungen oder eine neue Funktion, die kürzlich implementiert wurde), und wenden Sie sich an Ihren Cisco Support-Mitarbeiter.

Software-erzwungene Abstürze

Sie können softwareerzwungene Abstürze durch SIG=23 im Show Context [Steckplatz #] erkennen. Trotz des Namens sind diese Abstürze nicht immer softwarebezogen.

Wenn der Befehl show tech-support (im Aktivierungsmodus) von Ihrem Cisco Gerät ausgegeben wird, können Sie um potenzielle Probleme und Bugfixes anzuzeigen. Zur Verwendung müssen Sie ein registrierter Kunde sein, angemeldet sein und JavaScript aktivieren.

Sie können Output Interpreter verwenden, um potenzielle Probleme und Fixes anzuzeigen. Um Output Interpreter verwenden zu können, müssen Sie ein registrierter Kunde sein, angemeldet 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) die Linecards kontinuierlich an. Wenn eine Linecard nicht antwortet, entscheidet der Routingprozessor, sie zurückzusetzen. Dies führt zu einem softwareerzwungenen Absturz (SIG=23) der betroffenen Linecard. Diese Fehler sollten in den Routerprotokollen angezeigt werden:

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 Fehler bei Timeouts für Fabric-Pings zu beheben, müssen Sie herausfinden, warum die Linecard nicht auf den Ping-Befehl reagierte. Es können mehrere Ursachen auftreten:

- Die CPU-Auslastung der Linecard ist hoch - Dies kann mithilfe des Befehls show proc cpu im Ausführungssteckplatz [Steckplatz #] überprüft werden. Wenn die CPU wirklich hoch ist (über 95 %), finden Sie weitere Informationen unter Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern.

- In Inter Process Communication (IPC) gibt es Softwarefehler oder die Linecard hat keine IPC-Puffer mehr. Meistens werden diese Software-erzwungenen Reloads durch Software-Bugs verursacht.

Durch ein Upgrade auf die neueste Version Ihres Cisco IOS Software Release Train werden alle behobenen Fehler beseitigt, die zu Fabric-Ping-Timeouts führen. Wenn der Absturz nach dem Upgrade immer noch auftritt, sammeln Sie die relevanten Informationen (siehe Abrufen von Informationen zum Absturz) zusammen mit einem show tech-support, einem show ipc-Status und allen Informationen, die Sie für nützlich halten (z. B. kürzlich erfolgte Topologieänderungen oder eine kürzlich implementierte neue Funktion), und wenden Sie sich an Ihren Cisco Support-Mitarbeiter.

- Hardwarefehler - Wenn die Karte schon seit langem einwandfrei funktioniert und keine aktuellen Topologie-, Software- oder Funktionsänderungen vorgenommen wurden oder die Probleme nach einem Umzug oder Stromausfall auftraten, kann Hardware-Fehler die Ursache sein. Führen Sie den Befehl diag auf der betroffenen Linecard aus. Ersetzen Sie die Linecard (Linecard), falls fehlerhaft. Wenn mehrere Linecards betroffen sind oder der Datenträger in Ordnung ist, ersetzen Sie das Fabric.

%GSRSPA-6-FEHLERWIEDERHERSTELLUNG: Ein Hardware- oder Software-Fehler ist in Untersteckplatz 0 aufgetreten.Grund: Bemerkung: Automatische Fehlerwiederherstellung von TXECCERR initiiert

Der Fehler TXECCERR/RXECCERR tritt auf, wenn bei MAC-Adressen, die den Grenzwert innerhalb des Zeitintervalls überschreiten, eine nicht behebbare ECC-Fehlerunterbrechung mit RxFIFO oder TxFIFO auftritt. Nicht behebbare ECC-Fehler können nicht durch die ECC-Logik korrigiert werden. Wenn während des RxFIFO-Lesens ein nicht behebbarer Fehler auftritt, wird das Paket, zu dem die Daten gehören, an der SPI4-Empfangsschnittstelle mit EOP/Abort markiert und von oberen Schichten verworfen.

Dies ist auf die Hardware zurückzuführen und wird nach dem erneuten Laden des SIP/SPA korrigiert. Die permanente Lösung besteht darin, das SIP/SPA zu ersetzen, um Fehler zu vermeiden.

Andere Abstürze

Andere Crash-Typen sind weit weniger verbreitet als die beiden oben genannten. In den meisten Fällen sollte der Befehl diag angeben, ob die Karte ersetzt werden muss. Wenn die Karte den Diagnosetest erfolgreich besteht, sollten Sie ein Upgrade der Software in Erwägung ziehen.

Informationen, die beim Öffnen einer TAC-Serviceanfrage gesammelt werden müssen

Wenn Sie nach den oben beschriebenen Fehlerbehebungsschritten weiterhin Hilfe benötigen und eine Serviceanfrage (nur registrierte Kunden) beim Cisco TAC öffnen möchten, geben Sie folgende Informationen an:

- Die Fehlerbehebung wurde vor dem Öffnen der Serviceanfrage durchgeführt.

- Ausgabe des technischen Supports anzeigen (wenn möglich im Aktivierungsmodus).

- Protokollausgabe oder Konsolenaufzeichnungen anzeigen, falls verfügbar.

- Execute-On-Steckplatz [Steckplatz #] zeigt Technik für den Steckplatz an, bei dem die Linecard abgestürzt ist.

Fügen Sie die gesammelten Daten Ihrer Serviceanfrage im unverschlüsselten Textformat (.txt) hinzu. Sie können Informationen zu Ihrer Serviceanfrage hinzufügen, indem Sie sie mit dem TAC Service Request Tool hochladen (nur 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, der Ihre Service-Anfrage-Nummer in der Betreffzeile Ihrer Nachricht enthält.
Hinweis: Laden Sie den Router vor dem Erfassen der oben genannten Informationen nicht manuell neu oder starten Sie ihn nur, wenn Sie zur Fehlerbehebung bei einem Line Card-Crash auf dem Cisco Internet Router der Serie 12000 aufgefordert werden, da dies dazu führen kann, dass wichtige Informationen verloren gehen, die zur Bestimmung der Ursache des Problems erforderlich sind.

Zugehörige Informationen

- Fehlerbehebung bei Router-Abstürzen

- Konfigurieren eines Core-Dump auf einer GSR Line Card

- Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern

- Technischer Support und Dokumentation - Cisco Systems