Catalyst 6000/6500 - Systemabstürze Fehlerbehebung

  

Einführung

  

In diesem Dokument wird erläutert, wie Sie bei Abstürzen des Cisco Catalyst Switch Supervisor Engine Switch Processor (SP) der Serien 6000/6500 und der Multilayer Switch Feature Card (MSFC) Route Processor (RP) eine Fehlerbehebung durchführen können.

  

Voraussetzungen

  

Anforderungen

  

Für dieses Dokument bestehen keine speziellen Anforderungen.

  

Verwendete Komponenten

  

Die Informationen in diesem Dokument basieren auf den Cisco Catalyst Switch Supervisors der Serien 6000 und 6500 und MSFC-Modulen.

  

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

  

Abstürze im Supervisor-Modul

  

System durch Einschalten wieder auf ROM zurückgesetzt (SP durch Abbruch)

  

Ein Catalyst 6500/6000 mit einem SP-Konfigurationsregister, das Unterbrechungen (z. B. 0x2) ermöglicht und ein Konsolenbruchsignal empfängt, wechselt in den ROMmon-Diagnosemodus. Das System scheint abstürzen zu können.

  

Diese Beispiel-Switch-Ausgabe gibt an, dass der Switch von einem Switch-Prozessor-Konsolenbruchsignal in den ROMmon-Diagnosemodus gewechselt hat.

  

Hinweis: Das RP-Konfigurationsregister ist 0x2102.

  

6500_IOS#show version
Cisco Internetwork Operating System Software 
IOS (tm) c6sup2_rp Software (c6sup2_rp-PS-M), Version 12.1(13)E14, EARLY DEPLOYMENT 
RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Tue 30-Mar-04 01:56 by pwade
Image text-base: 0x40008C00, data-base: 0x417A6000

ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
BOOTLDR: c6sup2_rp Software (c6sup2_rp-PS-M), Version 12.1(13)E14, EARLY DEPLOYMENT 
RELEASE SOFTWARE (fc1)

6500_IOS uptime is 31 minutes
Time since 6500_IOS switched to active is 31 minutes
System returned to ROM by power-on (SP by abort at PC 0x601061A8)
System image file is "slot0:c6sup12-ps-mz.121-13.E14"

cisco Catalyst 6000 (R7000) processor with 227328K/34816K bytes of memory.
Processor board ID SAD053701CF
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
X.25 software, Version 3.0.0.
Bridging software.
1 Virtual Ethernet/IEEE 802.3 interface(s)
192 FastEthernet/IEEE 802.3 interface(s)
18 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.

16384K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

  

Die Lösung besteht darin, das Konfigurationsregister neu zu konfigurieren und das System neu zu laden. Gehen Sie wie folgt vor:

  

1. Geben Sie im globalen Konfigurationsmodus den Befehl config-register 0x2102 aus, und legen Sie das Konfigurationsregister für den RP und den SP auf 0x2102 fest.
   
   

   6500_IOS#config terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   6500_IOS(config)#config-register 0x2102
   
   6500_IOS(config)#end
   

2. Geben Sie den Befehl show bootvar ein, um den Wert für das Konfigurationsregister beim nächsten Neuladen zu überprüfen.
   
   

   6500_IOS#show bootvar
   BOOT variable = slot0:c6sup12-ps-mz.121-13.E14,1
   CONFIG_FILE variable = 
   BOOTLDR variable = 
   Configuration register is 0x2102

3. Geben Sie den Befehl remote command switch show bootvar ein, um zu überprüfen, ob das Konfigurationsregister auf dem SP ebenfalls geändert wurde.
   
   

   6500_IOS#remote command switch show bootvar
   
   
   6500_IOS-sp#
   BOOT variable = slot0:c6sup12-ps-mz.121-13.E14,1
   CONFIG_FILE variable = 
   BOOTLDR variable = 
   Configuration register is 0x2 (will be 0x2102 at next reload)
   

4. Laden Sie den Switch neu, damit die neue SP-Konfigurationseinstellung wirksam wird.
   
   

   6500_IOS#reload
   

   Hinweis: Sie können an dieser Stelle den Befehl copy running-config startup-config ausführen, um die Konfiguration zu speichern. Dieser Schritt ist jedoch nicht erforderlich, da die Konfigurationseinstellung nicht Teil der Startkonfiguration oder der aktuellen Konfiguration ist.

  

System erhält Software Forced Crash

  

Während eine Kennwortwiederherstellung auf einer Supervisor Engine 720 durchgeführt wird, kann der Switch während der Unterbrechung abstürzen, um Zugriff auf die Konsole des RP zu erhalten.

  

*** System received a Software forced crash *** 
 signal= 0x17, code= 0x24, context= 0x4269f6f4 
 PC = 0x401370d8, Cause = 0x3020, Status Reg = 0x34008002

  

Verwenden Sie dieses Verfahren zur Kennwortwiederherstellung, um zu verhindern, dass der Supervisor beim Wiederherstellen eines Kennworts abstürzt:

  

1. Drücken Sie die Break-Taste auf der Terminal-Tastatur direkt, nachdem der RP die Steuerung des Konsolenports übernimmt.
   
   Auf dem Catalyst 6500, der Cisco IOS^® ausführt, wird zuerst der SP gestartet. Dann wird die Steuerung auf den RP übertragen. Sobald der RP die Kontrolle erhält, starten Sie die Break-Sequenz. Der RP hat die Kontrolle über den Konsolenport erlangt, wenn diese Meldung angezeigt wird. (Initiieren Sie erst die Unterbrechungssequenz, wenn Sie diese Meldung sehen.):
   
   

   00:00:03: %OIR-6-CONSOLE: Changing console ownership to route processor

   Tipp: Informationen zu Tastenkombinationen finden Sie in den Standardkombinationen für Break Key Sequence während der Kennwortwiederherstellung.

2. Geben Sie den Befehl confreg 0x2142 1> innerhalb von 10 Sekunden an der ROMON 1> ein, um Flash zu starten, ohne die Konfiguration zu laden.
   
   
3. Laden Sie den Switch neu, und fahren Sie mit der Konfiguration des neuen Kennworts fort.
   
   
4. Geben Sie den Befehl config-register 0x2102 oder den ursprünglichen Wert im globalen Konfigurationsmodus ein.

   Dieses Problem ist in der Cisco Bug-ID CSCec36997 dokumentiert (nur registrierte Kunden).

  

System kehrt durch unbekannte Ursache des erneuten Ladens zum ROM zurück

  

Die Cisco Catalyst Switches der Serien 6000 und 6500 können aufgrund einer unbekannten Ursache unerwartet neu geladen werden. Die Ausgabe des Befehls show version zeigt eine ähnliche Fehlermeldung an:

  

System returned to ROM by unknown reload cause - suspect 
boot_data[BOOT_COUNT] 0x0, BOOT_COUNT 0, BOOTDATA 19 (SP by power-on)

  

Dieses Problem ist in der Cisco Bug-ID CSCef80423 dokumentiert (nur registrierte Kunden). Aktualisieren Sie den Switch auf die neueste Version der Cisco IOS Software, die nicht vom Fehler betroffen ist, um dieses Problem zu beheben.

  

%PM_SCP-1-LCP_FW_ERR

  

Diese Meldung weist darauf hin, dass die Firmware des angegebenen Moduls einen Paritätsfehler erkannt hat. Das System setzt das Modul automatisch zurück, um den Fehler zu beheben. Auf diesem Modul wird auch eine Crashinfo-Datei angezeigt. Die Fehlermeldung kann auf einen vorübergehenden Fehler oder einen Hardwarefehler zurückzuführen sein. Wenn die Fehlermeldung einmal auftritt, handelt es sich um ein vorübergehendes Problem. Diese wird automatisch vom System wiederhergestellt. Das Symptom der Parität kann durch CPO_ECC im Cache-Speicher identifiziert werden. Der ECC, der den Paritätsfehler darstellt, wurde vom System selbst korrigiert.

  

Es gibt zwei Arten von Paritätsfehlern:

  

• Weiche Paritätsfehler
  
  Diese Fehler treten auf, wenn im Chip ein Single Event Latch Up (SEL) auftritt. Wenn von der CPU darauf verwiesen wird, führen solche Fehler dazu, dass das System entweder abstürzt (wenn sich der Fehler in einem Bereich befindet, der nicht behebbar ist) oder dass andere Systeme wiederhergestellt werden (z. B. ein CyBus-Komplex wird neu gestartet, wenn der Fehler im Paketspeicher [MEMD]). Bei einem weichen Paritätsfehler muss die Platine oder eine der Komponenten nicht ausgetauscht werden.
  
  
• Harte Paritätsfehler
  
  Diese Fehler treten auf, wenn ein Chip oder ein Mainboard ausfällt, der Daten beschädigt. In diesem Fall müssen Sie die betroffene Komponente wieder einsetzen oder austauschen, die normalerweise einen Speicherchip-Austausch oder einen Plateaustauschen umfasst. Wenn mehrere Paritätsfehler an derselben Adresse auftreten, tritt ein Paritätsfehler auf. Es gibt kompliziertere Fälle, die schwieriger zu identifizieren sind. Wenn Sie in einem bestimmten Speicherbereich in relativ kurzer Zeit mehr als einen Paritätsfehler sehen, können Sie diesen im Allgemeinen als harten Paritätsfehler betrachten. Die Fehlermeldung sieht ähnlich aus wie folgt:
  
  

  Mar 9 12:12:24.427 GMT: %PM_SCP-SP-1-LCP_FW_ERR: Module 6 is experiencing the 
  following error: Pinnacle #0 PB parity error. Tx path. Status=0x0042

  Studien haben gezeigt, dass weiche Paritätsfehler 10- bis 100-mal häufiger auftreten als harte Paritätsfehler. Cisco empfiehlt daher dringend, auf einen schwerwiegenden Paritätsfehler zu warten, bevor Sie einen Ersatz tätigen. Dadurch werden die Auswirkungen auf Ihr Netzwerk erheblich reduziert.

  

%SYSTEM_CONTROLLER-3-FATAL

  

Die Meldung weist darauf hin, dass der System-Controller einen Fehler erkannt hat. Laden Sie das Gerät neu. Wenn diese Meldung erneut auftritt, ersetzen Sie den fehlerhaften Speicher oder die MSFC-Karte.

  

%SYSTEM_CONTROLLER-3-FATAL: An unrecoverable error has been detected.
The system is being reset.

%Software-forced reload

  

Fehlerhafter Lüfter verursacht Absturz des Supervisors

  

Wenn ein Lüftereinschub ausfällt oder ein Netzteil ausgeschaltet wird, können die Supervisor-Module bei Cisco Catalyst Switches mit Cisco IOS Software Release 12.1(19)E1 abstürzen. Das Problem ist in der Cisco Bug-ID CSCeb51698 dokumentiert (nur registrierte Kunden). Aktualisieren Sie den Switch auf die Cisco IOS-Version, die von diesem Fehler nicht betroffen ist.

  

Der Switch wurde eigenständig zurückgesetzt/neu gestartet.

  

Wenn Sie vermuten, dass der Switch sich selbst zurückgesetzt hat, geben Sie den Befehl show version ein, um die Betriebszeit des Switches zu überprüfen. Dies ist die Zeit seit dem letzten Zurücksetzen. Geben Sie den Befehl show log ein, um den Neustartverlauf anzuzeigen, wie in diesem Beispiel veranschaulicht wird. Zeigen Sie diese Befehlsausgabe an, um festzustellen, ob Ausnahmen aufgezeichnet wurden.

  

sup2a> (enable)show version
WS-C6506 Software, Version NmpSW: 6.3(10)


!--- Output is suppressed.


Uptime is 7 days, 4 hours, 27 minutes

  

sup2a> (enable)show log

Network Management Processor (ACTIVE NMP) Log:
  Reset count:   1
  Re-boot History:   Jan 06 2003 10:35:56 0

  Bootrom Checksum Failures:      0   UART Failures:                  0
  Flash Checksum Failures:        0   Flash Program Failures:         0
  Power Supply 1 Failures:        0   Power Supply 2 Failures:        0
  Swapped to CLKA:                0   Swapped to CLKB:                0
  Swapped to Processor 1:         0   Swapped to Processor 2:         0
  DRAM Failures:                  0

  Exceptions:                     0

  Loaded NMP version:            6.3(10)
  Software version:              slot0:cat6000-sup2.6-3-10.bin
  Reload same NMP version count: 1

  Last software reset by user: 1/6/2003,10:35:35

  EOBC Exceptions/Hang:            0

Heap Memory Log:
Corrupted Block = none

  

Diese Ausgabe des Befehls show log zeigt keine Softwareausnahmen an. Der letzte Neustart des Switches ist der 06. Januar 2003. Die Reboot-Zeit stimmt mit dem Feld Letzte Software-Zurücksetzung überein.

  

Diese Ausgabe des Befehls show log zeigt eine Ausnahme an, die beim letzten Neustart aufgezeichnet wurde.

  

esc-cat5500-b (enable)show log

Network Management Processor (STANDBY NMP) Log:
Reset count: 38
Re-boot History: Oct 14 2001 05:48:53 0, Jul 30 2001 06:51:38 0
Jul 28 2001 20:31:40 0, May 16 2001 21:15:39 0
May 02 2001 01:02:53 0, Apr 26 2001 21:42:24 0
Apr 07 2001 05:23:42 0, Mar 25 2001 02:48:03 0
Jan 05 2001 00:21:39 0, Jan 04 2001 4:54:52 0
Bootrom Checksum Failures: 0 UART Failures: 0
Flash Checksum Failures: 0 Flash Program Failures: 0
Power Supply 1 Failures: 4 Power Supply 2 Failures: 0
Swapped to CLKA: 0 Swapped to CLKB: 0
Swapped to Processor 1: 3 Swapped to Processor 2: 0
DRAM Failures: 0

Exceptions: 1

Loaded NMP version: 5.5(7)
Reload same NMP version count: 3

Last software reset by user: 7/28/2001,20:30:38
Last Exception occurred on Oct 14 2001 05:47:29 ...
Software version = 5.5(7)
Error Msg:
PID = 86 telnet87
EPC: 80269C44


!--- Output is suppressed.

  

Wenn auf Ihrem Switch eine solche Softwareausnahme angezeigt wird, führen Sie den dir-Bootflash aus: -Befehl, der das MSFC-Bootflash-Gerät (Route Processor [RP]) und das dir-Slavebootflash anzeigt: um nach einem Softwareabsturz zu suchen. Die Ausgabe in diesem Abschnitt zeigt, dass Crashinfo im RP-Bootflash aufgezeichnet wurde. Stellen Sie sicher, dass der Crashinfo, den Sie sehen, der letzte Crash ist.

  

cat6knative#dir bootflash:
Directory of bootflash:/

    1  -rw-     1693168   Jul 24 2002 15:48:22  c6msfc2-boot-mz.121-8a.EX
    2  -rw-      183086   Aug 29 2002 11:23:40  crashinfo_20020829-112340
    3  -rw-    20174748   Jan 30 2003 11:59:18  c6sup22-jsv-mz.121-8b.E9
    4  -rw-        7146   Feb 03 2003 06:50:39  test.cfg
    5  -rw-       31288   Feb 03 2003 07:36:36  01_config.txt
    6  -rw-       30963   Feb 03 2003 07:36:44  02_config.txt

31981568 bytes total (9860396 bytes free)

  

Der Supervisor-Bootflash-Ordner: zeigt das Bootflash-Gerät der Supervisor Engine an. Sie können auch das dir-Slavesup-Bootflash ausgeben: um das Standby-Bootflash-Gerät der Supervisor Engine anzuzeigen. Diese Ausgabe zeigt Crashinfo, das auf dem Bootflash-Gerät der Supervisor Engine aufgezeichnet wurde.

  

cat6knative11#dir sup-bootflash:
Directory of sup-bootflash:/

    1  -rw-    14849280   May 23 2001 12:35:09  c6sup12-jsv-mz.121-5c.E10
    2  -rw-       20176   Aug 02 2001 18:42:05  crashinfo_20010802-234205


!--- Output is suppressed.

  

Wenn die Befehlsausgabe anzeigt, dass bei dem vermuteten Neustart des Switches ein Softwareabsturz aufgetreten ist, wenden Sie sich an den technischen Support von Cisco. Geben Sie die Ausgabe des Befehls show tech-support und des Befehls show logging sowie die Ausgabe der Datei crashinfo an.

  

Das mit DFC ausgerüstete Modul wurde eigenständig zurückgesetzt.

  

Wenn ein mit DFC (Distributed Forwarding Card) ausgerüstetes Modul ohne Benutzerneuladen eigenständig zurückgesetzt wurde, können Sie den Bootflash der DFC-Karte überprüfen, um festzustellen, ob er abgestürzt ist. Wenn eine Absturzinformationsdatei verfügbar ist, können Sie die Ursache des Absturzes finden. Geben Sie das dir dfc#module#-bootflash: um zu überprüfen, ob eine Crash-Informationsdatei vorliegt und wann sie geschrieben wurde. Wenn der DFC-Reset mit dem Crashinfo-Timestamp übereinstimmt, führen Sie den Befehl more dfc#module#-bootflash:filename aus. Oder geben Sie den Befehl copy dfc#module#-bootflash:filename tftp ein, um die Datei über TFTP auf einen TFTP-Server zu übertragen.

  

cat6knative#dir dfc#6-bootflash:
Directory of dfc#6-bootflash:/
-#- ED ----type---- --crc--- -seek-- nlen -length- -----date/time------ name 
1   ..   crashinfo 2B745A9A   C24D0   25   271437 Jan 27 2003 20:39:43 crashinfo_
 20030127-203943

  

Nachdem Sie die Crashinfo-Datei zur Verfügung gestellt haben, erfassen Sie die Ausgabe des Befehls show logging und des Befehls show tech und wenden Sie sich für weitere Unterstützung an den technischen Support von Cisco.

  

Das Booten vom falschen Gerät verursacht einen Absturz

  

Wenn Sie von einem Gerät starten, das nicht in der Gerätetabelle aufgeführt ist, führt dies zu einem Absturz mit dem Supervisor-Modul. Aktualisieren Sie den Switch auf Cisco IOS Software Release 12.2(18r)SX05 oder höher.

  

CONST_DIAG-2-HM_SUP_CRSH

  

Fehlermeldungen:

  

%CONST_DIAG-2-HM_SUP_CRSH: Supervisor crashed due to unrecoverable errors, 
Reason: Failed TestSPRPInbandPing
%CONST_DIAG-2-HM_SUP_CRSH: Standby supervisor crashed due to unrecoverable errors, 
Reason: Failed TestSPRPInbandPing

  

Ursachen und Auflösungen:

  

• Wenn die TCAM-Einträge beschädigt sind, kann der SPRPInbandPing-Test fehlschlagen. Wenn der Test, der als Teil von Cisco Generic Online Diagnostics (GOLD) ausgeführt wurde, zehnmal hintereinander fehlschlägt, kann die Supervisor Engine abstürzen.
  
  Um dieses Problem zu beheben, aktualisieren Sie die Cisco IOS Software auf eine Version, die nicht von der Cisco Bug ID CSCsc3990 betroffen ist (nur registrierte Kunden).
  
  
• Wenn die Systemüberwachung auf dem Gerät aktiviert ist und während des Startvorgangs eine vollständige Diagnose konfiguriert wird, kann der Supervisor beim Start abstürzen.
  
  Die Systemüberwachung und die vollständige Diagnose kollidieren bei einigen Tests miteinander. Deaktivieren Sie als Problemumgehung beide Optionen, je nach Ihren Anforderungen.

  

EARL-Treiber: lyra_purge_search:process_ush_event_list fehlgeschlagen

  

Die Cisco Catalyst Switches der Serien 6500 und 6000 können während des Startvorgangs unerwartet neu geladen werden. Das Absturzprotokoll kann Systemmeldungen wie die folgenden anzeigen:

  

Über das aktive Supervisor-Modul:

  

%SYS-SP-2-MALLOCFAIL: Memory allocation of 320000 bytes 
failed from 0x40BCF26C, alignment 8 
Pool: Processor  Free: 75448  Cause: Not enough free memory 
Alternate Pool: None  Free: 0  Cause: No Alternate pool 
-Process= "CEF process", ipl= 0, pid= 240
-Traceback= 40280AB4 40288058 40BCF274 40BE5660 40BE5730 4029A764 4029A750

%L2-SP-4-NOMEM: Malloc failed: L2-API Purge/Search failed. size req. 512

SP: EARL Driver:lyra_purge_search:process_push_event_list failed

%SCHED-SP-2-SEMNOTLOCKED: L2 bad entry (7fff/0) purge proc
attempted to unlock an unlocked semaphore
-Traceback= 402C202C 4058775C 4058511C 40587CB8

  

Vom Standby-Supervisor-Modul:

  

%SYS-SP-STDBY-2-MALLOCFAIL: Memory allocation of 2920 bytes 
failed from 0x40174088, alignment 8 
Pool: Processor  Free: 9544  Cause: Memory fragmentation 
Alternate Pool: None  Free: 0  Cause: No Alternate pool 
-Process= "DiagCard2/-1", ipl= 0, pid= 154
-Traceback= 4016F7CC 40172984 40174090 4063601C 40636584 4062D194 4062ABD8 4062A9EC
4017E0B0 4017E09C

%L2-SP-STDBY-4-NOMEM: Malloc failed: L2-API Purge/Search failed. size req. 512

%SCHED-SP-STDBY-2-SEMNOTLOCKED: L2 bad entry (7fff/0) purge proc
attempted to unlock an unlocked semaphore
-Traceback= 4018A300 403F0400 403EDD7C 403F0A48

SP-STDBY: EARL Driver:lyra_purge_search:process_push_event_list failed

%SYS-SP-STDBY-2-MALLOCFAIL: Memory allocation of 1400 bytes 
failed from 0x409928B4, alignment 8 
Pool: Processor  Free: 7544  Cause: Memory fragmentation 
Alternate Pool: None  Free: 0  Cause: No Alternate pool 
-Process= "CEF LC Stats", ipl= 0, pid= 138
-Traceback= 4016F7CC 40172984 409928BC 409C5EEC 4098A5EC

  

In der Cisco IOS Software-Version 12.2(17d)SXB benötigt die Supervisor Engine 2 ein DRAM-Minimum von 256 MB. Wenn Ihr Supervisor-Modul DRAM von 128 MB hat, aktualisieren Sie zur Behebung dieses Problems den Speicher auf 256 MB oder mehr. Weitere Informationen finden Sie in den Versionshinweisen für Cisco IOS Release 12.2SX auf der Supervisor Engine 720, der Supervisor Engine 32 und der Supervisor Engine 2.

  

SNMP-Abfrage in ROMMon-Aktualisierung stürzt den Switch ab

  

Die Cisco Catalyst Switches der Serien 6000 und 6500 können aufgrund einer unerwarteten Ausnahme unerwartet neu geladen werden.

  

01:22:25: %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host 10.1.2.2
01:23:25: %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host 10.1.2.2
01:23:40: ROMMON image upgrade in progress
01:23:40: Erasing flash

Unexpected exception, CPU signal 5, PC = 0x402F3DC4

  

Während des ROMMon-Upgrades wird ein Neuladen des Switches ausgelöst, wenn das System eine SNMP-Abfrage empfängt.

  

Führen Sie dieses Verfahren aus, um zu verhindern, dass der Switch beim Durchführen des ROMMon-Upgrades abstürzt:

  

1. Deaktivieren Sie den SNMP-Agent im Switch.
   
   

   no snmp-server

2. Deaktivieren Sie mögliche SNMP-Abfragen an dieses Gerät von den Netzwerkmanagementstationen.
   
   
3. Führen Sie das ROMMon-Upgrade nur auf dem Standby-Supervisor durch. Führen Sie zur Aktualisierung des aktiven Supervisors einen erzwungenen Switchover durch, und führen Sie das ROMMon-Upgrade durch.
   
   

   redundancy force-switchover

%Error Opening Bootflash:Crashinfo (Datei nicht gefunden)

  

Diese Meldung wird als Port der Ausgabe des Befehls show stapacks (ebenfalls Teil des Befehls show tech-support) angezeigt. Die vollständige Nachricht ähnelt der folgenden:

  

***************************************************
******* Information of Last System Crash **********
***************************************************
 

Using bootflash:crashinfo.
 
%Error opening bootflash:crashinfo (File not found)
 
***************************************************
****** Information of Last System Crash - SP ******
***************************************************
 

The last crashinfo failed to be written.
Please verify the exception crashinfo configuration
the filesytem devices, and the free space on the
filesystem devices.
Using crashinfo_FAILED.
 
%Error opening crashinfo_FAILED (File not found)

  

Es gibt zwei Bedingungen, unter denen eine solche Meldung angezeigt wird:

  

• Der Bootflash: Gerät hat nicht genügend Speicherplatz, um die Crashinfo-Datei zu speichern. So überprüfen Sie, ob der Bootflash: genügend Speicherplatz hat, erstellen Sie den dir-Bootflash: oder den Befehl dir all eingeben. Stellen Sie sicher, dass im Bootflash freier Speicherplatz für den Crashinfo vorhanden ist (wenn der Switch aus irgendwelchen Gründen in Zukunft abstürzt).
  
  
• Das System ist noch nie einem Absturz ausgesetzt. Wenn Sie den Switch nach einem vermuteten Absturz neu gestartet haben, führen Sie den Befehl show version aus. Suchen Sie in der Ausgabe nach der Zeile, die mit der Rückgabe des Systems an das ROM durch beginnt. Wenn der Text, der auf die Leitung folgt, eingeschaltet ist, ist der Switch nicht abgestürzt. Die Liste ist nicht vollständig, aber andere Sätze, die angeben können, ob ein Absturz stattgefunden hat, sind: Unbekannte Ursache für Neuladen - Verdacht, Paritätsfehler beim Prozessorspeicher auf dem PC, und SP durch Abbruch beim PC.

  

MSFC-Modul-bezogene Abstürze

  

Das System erhält eine Busfehler-Ausnahme.

  

Die MSFC kann mit einer Busfehler-Ausnahme abstürzen, die durch ein Software- oder Hardwareproblem verursacht werden kann. Diese Fehlermeldungen können angezeigt werden:

  

• Auf der Konsole:
  
  

  *** System received a Bus Error exception ***
  signal= 0xa, code= 0x10, context= 0x60ef02f0
  PC = 0x601d22f8, Cause = 0x2420, Status Reg = 0x34008002

• In der Ausgabe des Befehls show version:
  
  

  !--- Output is suppressed.
  
  System was restarted by bus error at PC 0x0, address 0x0 at 15:31:54 EST Wed Mar 29 2000
  
  !--- Output is suppressed.

Wenn die angegebene Adresse eine ungültige Adresse aus dem Speicherbereich ist, handelt es sich um einen Softwarefehler. Wenn sich die Adresse im gültigen Bereich befindet, ist die Ursache des Problems wahrscheinlich ein Hardwarefehler des Prozessorspeichers.

  

Weitere Informationen zu diesen Typen von Bus-Fehlerabstürzen finden Sie unter Fehlerbehebung bei Busfehler-Abstürzen. Weitere Informationen finden Sie unter Cisco Bug ID CSCdx92013 (nur registrierte Kunden).

  

System empfängt eine Cache-Parity-Ausnahme

  

Die MSFC enthält keinen ECC-Speicherschutz. Daher stürzt die MSFC bei der Erkennung eines Paritätsfehlers ab. Dies sind einige der Fehler, die Sie sehen können, wenn dies auftritt:

  

• In der Konsole sehen Sie:
  
  

  *** System received a Cache Parity Exception *** 
  signal= 0x14, code= 0xa405c428, context= 0x60dd1ee0 
  PC = 0x6025b2a8, Cause = 0x6420, Status Reg = 0x34008002

• In der Ausgabe des Befehls show version sehen Sie:
  
  

  
  !--- Output is suppressed.
  
  System returned to ROM by processor memory parity error at PC 0x6020F4D0, 
  address 0x0 at 18:18:31 UTC Wed Aug 22 2001   
  
  !--- Output is suppressed.

In der Crashinfo-Datei, die im Bootflash oder in der Konsole aufgenommen wurde, sehen Sie:

  

Error: primary data cache, fields:  data, SysAD 
virtual addr 0x4B288202, physical addr(21:3) 0x288200, vAddr(14:12) 0x0000 
virtual address corresponds to pcimem, cache word 0 
Address: 0x4B288200 not in L1 Cache      
Address: 0x4B288202 Can not be loaded into L1 Cache

  

Wenn der Fehler mehrmals auftritt, müssen Sie die MSFC ersetzen. Wenn der Fehler nur einmal auftritt, kann es zu einem einzelnen Ereignis kommen. Überwachen Sie in diesem Fall die MSFC. Weitere Informationen zu Paritätsfehlern finden Sie unter Prozessorspeicherparitätsfehler (PMPEs).

  

Andere Paritätsbezogene Fehler

  

MSFC2 enthält ECC-Speicherschutz. Es gibt jedoch Speicherorte, an denen die Parität überprüft wird, Single-Bit-Fehler jedoch nicht korrigiert werden können. Dies sind einige Fehlermeldungen, die Sie in der Crashinffile sehen können, die auf einen Paritätsfehler hinweisen:

  

• MISTRAL_TM_DATA_PAR_ERR_REG_MASK_HI: 42
  
  
• Fehlerbedingung erkannt: TM_NPP_PARITY_ERROR
  
  
• Fehlerbedingung erkannt: SYSAD_PARITY_FEHLER
  
  
• Fehlerbedingung erkannt: SYSDRAM_PARITÄT

  

Wenn diese Fehlermeldungen nur einmal protokolliert werden, ist möglicherweise ein einzelnes Ereignis verärgert. Überwachen Sie die MSFC2. Wenn die Fehler häufiger auftreten, ersetzen Sie MSFC2. Weitere Informationen zu Paritätsfehlern finden Sie unter Prozessorspeicherparitätsfehler (PMPEs).

  

%MISTRAL-3-FEHLER

  

Wenn MSFC2 abstürzt und Sie eine Crashinfo-Datei im Bootflash-Gerät haben, führen Sie den Befehl more bootflash:crashinfo_filename aus. Der Befehl zeigt die Informationen aus der Crashinfo-Datei an. Wenn Sie die MISTRAL-3-FEHLER-Meldung im ersten Protokollabschnitt des Crashinfo-Protokolls sehen, können Sie MSFC2-Abstürze mit Mistral-3-Fehlermeldungen in der Crashinfo-Datei überprüfen, ob einer der häufigen Gründe aufgetreten ist.

  

Allgemeine Diagnoseverfahren für Switches, auf denen CatOS ausgeführt wird

  

Integritätsprüfung für CatOS

  

Der Befehl show system sanity (Systemintegrität anzeigen) führt eine Reihe vordefinierter Prüfungen der Konfiguration mit einer möglichen Kombination bestimmter Systemzustände aus, um eine Liste von Warnbedingungen zu erstellen. Die Prüfungen sind so konzipiert, dass sie nach irgendetwas suchen, das unangebracht erscheint. Die Prüfungen sollen Ihnen helfen, die gewünschte und korrekte Systemkonfiguration und -funktionalität beizubehalten. Dieser Befehl wird von CatOS ab Version 8.3x unterstützt.

  

Informationen zur Liste der durchgeführten Prüfungen und zur Beispielausgabe des Befehls finden Sie unter Sanitätsprüfung auf Konfigurationsprobleme und Systemstatus.

  

Wiederherstellen von Catalyst-Switches, die CatOS nach fehlgeschlagenen Bootvorgängen ausführen

  

Unter Recover the Catalyst 6500/6000 with Supervisor Engine I or II (Catalyst 6500/6500 mit Supervisor Engine 1 oder 2 wiederherstellen können Sie Cisco Catalyst 6000/6500 wiederherstellen.

  

Unter Recover the Catalyst 6500/6000 with Supervisor Engine 720 or Supervisor Engine 32 (Catalyst 6000/6500 mit Supervisor Engine 720 oder 32 wiederherstellen können Sie Cisco Catalyst 600/6500 wiederherstellen.

  

Abrufen von Informationen aus der Crashinfo-Datei

  

Die Crashinfo-Datei ist eine Sammlung nützlicher Informationen über den aktuellen Absturz, der im Bootflash- oder Flash-Speicher gespeichert ist. Wenn ein Router aufgrund von Daten- oder Stapelbeschädigungen abstürzt, sind mehr Informationen zum erneuten Laden erforderlich, um diesen Absturztyp zu debuggen, als nur die Ausgabe des Befehls show stacks.

  

Die Crashinff-Datei enthält folgende Informationen:

  

• begrenzte Fehlermeldung (Protokoll) und Befehlsverlauf
  
  
• Beschreibung des Bilds, das zum Zeitpunkt des Absturzes ausgeführt wird
  
  
• Ausgabe des Befehls show alignment (Alignment anzeigen)
  
  
• Malloc und freie Spuren
  
  
• Ablaufverfolgung
  
  
• Kontext auf Prozessebene
  
  
• Stapelablage auf Prozessebene
  
  
• Stack-Dump auf Unterbrechungsebene
  
  
• Informationen auf Prozessebene
  
  
• Speicherdump auf Prozessebene

  

Unter Abrufen von Informationen aus der Crashinfo-Datei finden Sie weitere Informationen und Informationen zum Abrufen der Crashinfo-Datei.

  

Unter Erstellen von Core-Dumps finden Sie weitere Informationen und Informationen zum Sammeln von Core-Dump vom Gerät.

  

Fehlerbehebung aufgrund von Fehlermeldungen

  

Informationen zu Cisco Catalyst Switches der Serien 6000/6500, die Native IOS ausführen, finden Sie in den gängigen Fehlermeldungen zu Catalyst Switches der Serien 6500/6000, auf denen Cisco IOS Software ausgeführt wird. Wenn Sie eine Fehlermeldung sehen, die nicht in einer der gängigen Fehlermeldungen enthalten ist, lesen Sie Folgendes:

  

• Message and Recovery Procedures - Catalyst 6500 Series Cisco IOS System Message Guide, 12.2SX
  
  
• Message and Recovery Procedures - Catalyst 6500 Series Cisco IOS System Message Guide, 12.1 E

  

Informationen zu Cisco Catalyst Switches der Serien 6000/6500, die ein Hybrid-Betriebssystem ausführen, finden Sie unter Häufige CatOS-Fehlermeldungen für Catalyst Switches der Serien 6500 und 6000. Wenn Sie eine Fehlermeldung sehen, die nicht in einer der gängigen Fehlermeldungen enthalten ist, finden Sie weitere Informationen im Messaging and Recovery Procedures - Catalyst 6500 Series System Message Guide, 8.4.

  

Verwenden Sie den Cisco CLI Analyzer (nur registrierte Kunden), um sofort eine Fehlerbehebungsanalyse und einen Aktionsplan für Router, Switches oder PIX-Geräte zu erhalten. Hierzu werden die gesammelten Befehlsausgaben für show verwendet.

  

Zugehörige Informationen

  

• Fehler- und Systemmeldungen - Cisco Catalyst Switches der Serie 6500
• Häufige CatOS-Fehlermeldungen bei Catalyst Switches der Serien 6500 und 6000
• Häufige Fehlermeldungen bei Catalyst Switches der Serien 6500/6000 mit Cisco IOS Software
• Produktsupport für Switches
• Unterstützung der LAN Switching-Technologie
• Technischer Support und Dokumentation - Cisco Systems