Inhalt

Einführung

Problem: SpineControlBus-Fehler

Lösung

Problem: Fehlerhafte Blöcke im NVRAM gefunden

Lösung

Problem: Modul 9 Compact Flash-Fehler

Lösung

Problem: N7K-M132XP-12 Linecard-PortLoopback-Testfehler

Lösung

Problem: N7K-M132XP-12 Linecard-MODUL-4-MOD_WARNUNG

Lösung

Problem: N7K-M224XP-23L Chico Fehlermeldung bei Synchronisierung

Lösung

Problem: Fehler beim N7K-F248XP-25 PrimaryBootROM- und SecondaryBootROM-Test

Lösung

Problem: Temperatursensorfehler

Lösung

Problem: Xbar-Fehler/C7010-FAB-1 im Power-Down-Status

Lösung

Problem: Fehlgeschlagenes Lüftermodul N7K-C7010-FAN-F

Lösung

Problem: %PLATFORM-2-PS_CAPACITY_CHANGE-Netzteilalarm

Lösung

Problem: %PLATFORM-5-PS_STATUS: Netzteil X PS_FAIL-Alarm

Lösung

Problem: Netzteilproblem auf FEX

Lösung

Problem: Netzteile des Typs N7K-AC-6,0KW werden als fehlerhaft gemeldet

Lösung

Problem: Software-Paketverluste

Lösung

Problem: USER-2-SYSTEM_MSG FIPS Self-Test Failure System-Fehler

Lösung

Einführung

Dieses Dokument enthält eine kurze Erläuterung und Lösungen für häufige Hardware- und Architekturprobleme bei Cisco Nexus Switches der Serie 7000, auf denen die Cisco NX-OS-Systemsoftware ausgeführt wird.

Hinweis: Das genaue Format der in diesem Dokument beschriebenen Syslog- und Fehlermeldungen kann leicht abweichen. Die Variation hängt von der Softwareversion ab, die auf der Supervisor Engine ausgeführt wird.

Problem: SpineControlBus-Fehler

Der Spine-Steuerungstest schlägt für den Nexus 7000-Supervisor fehl:

Nexus7000# show module internal exceptionlog module 5

...

System Errorcode  : 0x418b0022 Spine control test failed

Error Type        : Warning

PhyPortLayer      : 0x0

Port(s) Affected  : none

Error Description : Module 10 Spine Control Bus test Failed

...

11) SpineControlBus E

Error code ------------------> DIAG TEST ERR DISABLE

Total run count -------------> 1597800

Last test execution time ----> Mon May 27 21:57:17 2013

First test failure time -----> Sun Nov 20 00:30:55 2011

Last test failure time ------> Mon May 27 21:57:17 2013

Last test pass time ---------> Mon May 27 21:56:47 2013

Total failure count ---------> 33

Consecutive failure count ---> 1

Last failure reason ---------> Spine control test failed

Lösung

Dieses Problem bezieht sich auf die Cisco Bug-ID CSCuc72466. Weitere Informationen finden Sie in den Häufig gestellten Fragen zum Nexus 7000: Welche Aktion wird empfohlen, wenn der SpineControlBus-Test fehlschlägt?.

Problem: Fehlerhafte Blöcke im NVRAM gefunden

In Diagnoseereignissen werden NVRAM-Fehler angezeigt:

Nexus7000#show diagnostic events

1) Event:E_DEBUG, length:97, at 9664 usecs after Wed Dec  5 01:03:42 2012

[103] Event_ERROR: TestName->NVRAM TestingType->health monitoring module->5

Result->fail Reason->

#show diagnostic result module 5 test NVRAM detail

4) NVRAM-------------------------> E

Error code ------------------> DIAG TEST ERR DISABLE

Total run count -------------> 52596

Last test execution time ----> Wed Dec  5 01:03:41 2012

First test failure time -----> Tue Dec  4 23:28:45 2012

Last test failure time ------> Wed Dec  5 01:03:42 2012

Last test pass time ---------> Tue Dec  4 23:23:41 2012

Total failure count ---------> 20

Consecutive failure count ---> 20

Last failure reason ---------> Bad blocks found on nvram

Dies ist entweder ein Hardwareproblem, ein Supervisor Engine-Fehler oder ein vorübergehendes Problem.

Lösung

1. Führen Sie den NVRAM-Test erneut aus, um festzustellen, ob es sich um einen falschen Alarm handelt. Geben Sie diese Befehle ein, um den Diagnosetest zu deaktivieren und erneut zu aktivieren (Beispiel, wenn für Problemmodul 5 angegeben):

- Kein Test des NVRAM für das Diagnosemodul 5

- NVRAM-Test für das Diagnoseüberwachungsmodul 5

Geben Sie den Befehl show diagnose result module 5 test NVRAM detail ein, um die Ergebnisse des Testbefehls anzuzeigen.

2. Wenn der NVRAM-Test erneut fehlschlägt, setzen Sie das Modul 5 wieder ein. Beobachten Sie das Ergebnis des Anzeigeergebnismoduls 5 und zeigen Sie die Befehle des Moduls an.

3. Falls das Modul erneut ausfällt, fordern Sie den Supervisor im problematischen Steckplatz eine Retourengenehmigung (Return Material Authorization, RMA) an.

Problem: Modul 9 Compact Flash-Fehler

Eine oder alle dieser Optionen sind auf dem Supervisor 2/Supervisor 2E aufgeführt:

- Fehlermeldung:
DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 5 has failed test CompactFlash

20 times on device Compact Flash due to error The compact flash power test failed.

- Konfiguration konnte nicht gespeichert werden.

- Diagnosetestfehler:
Test results: (. = Pass, F = Fail, I = Incomplete,

U = Untested, A = Abort, E = Error disabled)

7) CompactFlash E

Error code ------------------> DIAG TEST ERR DISABLE

Total run count -------------> 23302

Last test execution time ----> Sun Apr 13 10:07:30 2014

First test failure time -----> Sun Apr 13 00:37:41 2014

Last test failure time ------> Sun Apr 13 10:07:40 2014

Last test pass time ---------> Sun Apr 13 00:07:41 2014

Total failure count ---------> 20

Consecutive failure count ---> 20

Last failure reason ---------> The compact flash power test

failed

Next Execution time ---------> Sun Apr 13 10:37:30 2014

Ursache

Die zweite Generation der Nexus 7000-Supervisoren wird mit zwei identischen eUSB-Blitzen geliefert, um Redundanz zu gewährleisten. Die Blitze stellen ein Repository für Bootflash, Konfigurationen und andere relevante Informationen bereit. Diese beiden Blitze werden als RAID-1-Array (Redundant Array of Independent Disks) neu konfiguriert, das die interne Spiegelung implementiert. Dank der Redundanz kann ein Supervisor mit dem Verlust eines der Blitze arbeiten, aber nicht mit beiden.

Es gibt einige Fälle, in denen eine oder beide dieser Blitze von der RAID-Software über einen Zeitraum von mehreren Monaten oder Jahren als fehlerhaft gekennzeichnet sind. Ein Reset/Reboot des Motherboards erkennt diese fehlgeschlagenen Blitze beim nächsten Booten wieder fehlerfrei.

Lösung

Gehen Sie wie folgt vor, um zu überprüfen, ob es sich um ein Hardwareproblem handelt oder nicht:

1. Laden Sie den problematischen Supervisor, wenn möglich, neu.

2. Wenn das Problem nach dem erneuten Laden auftritt, benötigen Sie einen Hardware-Ersatz.

3. Wenn das Problem durch erneutes Laden behoben wird, bezieht sich die Ursache auf die Cisco Bug-ID CSCus22805.

Problem: N7K-M132XP-12 Linecard-PortLoopback-Testfehler

Die Linecard meldet einen Diagnosefehler aufgrund des fehlgeschlagenen Port-Loopback-Tests 10-mal nacheinander:

DIAG_PORT_LB-2-PORTLOOPBACK_TEST_FAIL  Module:16 Test:PortLoopback

failed 10 consecutive times. Faulty module:Module 16 affected ports:5,7

Error:Loopback test failed. Packets lost on the LC at the Queueing engine ASIC

MODULE-4-MOD_WARNING  Module 16 (serial: XXXX) reported warning on

ports 16/5-16/5 (Ethernet) due to Loopback test failed.

Packets lost on the LC at the Queueing engine ASIC in device 78

(device error 0x41830059)

Ursache

Dies ist eine Warnmeldung und weist in den meisten Fällen auf ein Hardwareproblem mit dem Port hin.

Lösung

Suchen Sie zunächst nach der Cisco Bug-ID CSCtn81109 und der Cisco Bug-ID CSCti95293, da es sich um ein Softwareproblem handeln könnte.

Setzen Sie das Modul zuerst wieder ein, um die Karte neu zu initialisieren und die Hardwarestatustests erneut auszuführen. Wenn bei den Diagnosetests weiterhin ein Fehler für dieselbe Karte angezeigt wird, ersetzen Sie die Karte.

Laden Sie die Karte zu einem geeigneten Zeitpunkt neu, und erfassen Sie die Ausgaben für folgende Befehle:

- Protokollierungsprotokoll anzeigen

- Schaumodul

- Anzeigefeldmodul mit allen Details

Alternativ können Sie nur diesen bestimmten Test erneut durchführen, ohne die Karte neu laden zu müssen. Dieses Beispiel zeigt Modul 16:

show diagnostic result module 16

diagnostic clear result module all

(config)# no diagnostic monitor module 16 test 5

(config)# diagnostic monitor module 16 test 5

diagnostic start module 16 test 5

show diagnostic result module 16 test 5

Problem: N7K-M132XP-12 Linecard-MODUL-4-MOD_WARNUNG

Diese Fehler werden angezeigt, und es kann ein erneutes Laden des Moduls auftreten:

2013 Mar 27 00:40:23 DC3-7000-PRODD2-A23  MODULE-4-MOD_WARNING

Module 9 (serial: XXX) reported warning on ports 9/1-9/3 (Unknown)

due to BE2 Arbiter experienced an error in device 65 (device error 0xc410f613)

Ursache

Dies ist ein Hardwarefehler, der durch Paritätsfehler oder Hardware-Probleme auf der Tochterkarte verursacht wird.

Lösung

1. Überprüfen Sie die Ausgabe dieser Befehle:

- Anzeigeversion

- Anzeigemodul X mit Rücksetzgrund

- Anzeige der Protokollierung an Bord, interner Grund für Zurücksetzen

- show module internal event history module X

- Anzeigeprotokoll

2. Wenn Ihre Version von Cisco NS-OX älter als Version 4.2 ist, sollten Sie ein Upgrade auf eine neue Version durchführen, um die Fehlerbehebung für diese Software-Fehler zu gewährleisten (Minimierung der Wahrscheinlichkeit von Paritätsfehlern):

- Cisco Bug-ID CSCso72230 L1 D-Cache aktiviert 8541 CPU-Abstürze mit L1-D-Cache-Paritätsfehlern

- Cisco Bug ID CSCsr90831 - 8541 CPU-Abstürze mit L1-D-Cache mit L1-D-Cache Push-Paritätsfehler

3. Wenn die Fehler wiederholt auftreten, setzen Sie die Karte und den Monitor wieder ein.

4. Wenn die Fehler weiterhin auftreten, ersetzen Sie das Problem-Modul.

Weitere bekannte Software-Defekte

Cisco Bug-ID CSCtb98876

Problem: N7K-M224XP-23L Chico Fehlermeldung bei Synchronisierung

Diese Fehler werden auf dem Modul angezeigt:

%MODULE-4-MOD_WARNING: Module # (Serial number: XXXX) reported warning

Ethernet#/# due to chico serdes sync loss in device DEV_SKYTRAIN

(device error 0xc9003600)

Ursache

Diese Fehler weisen darauf hin, dass ein Problem mit dem Synchronisierungsverlust zwischen Modul # und Xbar/ASIC vorliegt. In den meisten Fällen ist der Hardwarefehler des Moduls die Ursache.

Wenn Ihre Version von Cisco NS-OX älter als 6.1(4) ist und die Meldung nicht kontinuierlich angezeigt wird, kann sie von der Cisco Bug-ID CSCud91672 betroffen sein. Der Fehler besteht darin, dass sich die Einstellungen der NX-OS-Serdes von den Diagnoseinstellungen auf den beiden Kanälen zwischen SKT <—>SAC unterscheiden.

Lösung

Erfassen Sie die Ausgabe dieser Befehle:

- Anzeigeversion

- Schaumodul

- Schaulauf

- show module internal event history module X

- Internes Aktivitätsmodul anzeigen X

- show module internal exception-log module X

- Anzeigen von internen Ereignisverlaufsfehlern im Modul

- show logging last 200

- show logging nvram

Aktualisieren Sie den Switch auf NS-OX Version 6.1(4) oder höher, um die Ursache des Fehlers zu isolieren.

Führen Sie diesen Test durch, um zu überprüfen, ob die Karte fehlerhaft ist und nicht der Xbar- oder Chassis-Steckplatz:

1. Setzen Sie das fehlerhafte Modul in einen anderen freien Steckplatz im Gehäuse ein.

2. Wenn Sie ein Ersatzmodul haben, setzen Sie es in einen problematischen Steckplatz ein.

3. Wenn die Fehler nach Schritt 1 nicht angezeigt werden, setzen Sie das Modul wieder in den problematischen Steckplatz ein, und überprüfen Sie es.

Problem: Fehler beim N7K-F248XP-25 PrimaryBootROM- und SecondaryBootROM-Test

Das Modul N7K-F248XP-25 schlägt sowohl beim PrimaryBootROM- als auch beim SecondaryBootROM-Test fehl:

show module internal exceptionlog module 1 | i Error|xception

********* Exception info for module 1 ********

exception information --- exception instance 1 ----

Error Description : Secondary BootROM test failed

exception information --- exception instance 2 ----

Error Description : Primary BootROM test failed

Ursache

Dies wird in der Regel durch eine Beschädigung der BIOS-Datei oder einen Hardwarefehler auf der Linecard angezeigt.

Lösung

Die Cisco Bug-ID CSCuf82089 fügt Code hinzu, um detailliertere Informationen über solche Fehler anzuzeigen und so eine bessere Diagnose zu ermöglichen. Beispielsweise wird eine ausgefallene Komponente anstelle eines derzeit NULL-Werts angezeigt.

In einigen Fällen ist das Problem auf eine BIOS-Beschädigung des Moduls zurückzuführen. Geben Sie den Befehl install module X bios erzwungen ein, um dies zu beheben. Beachten Sie, dass dieser Befehl möglicherweise Auswirkungen auf den Dienst haben kann. Es wird empfohlen, diese nur während eines Wartungsfensters auszuführen.

Gehen Sie wie folgt vor, um das Problem zu beheben:

1. Planen Sie ein Wartungsfenster, und geben Sie den Befehl Installationsmodul X bios als mögliche Problemumgehung ein. Geben Sie diesen Befehl nur während eines Wartungsfensters ein, um mögliche Auswirkungen auf den Service zu vermeiden.

2. Wenn Schritt 1 nicht hilft oder für diese Aktion kein Wartungsfenster vorhanden ist, ersetzen Sie das Modul. Diese Beispielausgabe zeigt einen fehlgeschlagenen Versuch:

Nexus7000# install module 1 bios forced

Warning: Installing Bios forcefully...!

Warning: Please do not remove or power off the module at this time

Upgrading primary bios

Started bios programming .... please wait

[#                            0%                             ]

BIOS install failed for module 1, Error=0x40710027(BIOS flash-type verify failed)

BIOS is OK ...

Please try the command again...

Problem: Temperatursensorfehler

Dieser Fehler wird auf der Plattform angezeigt:

%PLATFORM-4-MOD_TEMPFAIL: Module-2 temperature sensor 7 failed

Ursache

Dies ist ein zeitweiliges Problem mit dem Temperatur-/Spannungsblock im ASIC, das aufgrund des internen ASIC-Timings unter bestimmten Bedingungen auftritt. Cisco Bug ID CSCtw79052 beschreibt die bekannte Ursache für dieses Problem.

Dies ist ein Timing-Problem zwischen dem ASIC, der die Temperatur intern feststellt, und der Software, die das gültige Bit prüft. Das Problem besteht darin, dass es auf eine der 12 Clipper-Instanzen treffen kann. Es gibt keinen bestimmten Auslöser für dieses Problem, und es tritt nur gelegentlich auf. Dieses Problem hat keine Auswirkungen auf den Dienst und tritt auf, weil die Logik des Temperaturlesens ein Problem hat, das weitere Wiederholungen im Treiber erfordert.

Lösung

Erfassen Sie die Ausgabe dieser Befehle, und überprüfen Sie die Cisco Bug-ID CSCtw79052:

- Anzeigeversion

- Umgebungstemperatur anzeigen

- show sprom module <Modul #>

- Nexus#-Modul zum Anhängen <Modul #>

- <module#>#show hardware internal sensor event history errors

Problem: Xbar-Fehler/C7010-FAB-1 im Power-Down-Status

Der C7010-FAB-1 befindet sich in einem ausgeschalteten Zustand, und es treten folgende Fehler auf:

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed,

Left Ejector is OPEN, Right Ejector is CLOSE

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed,

Left Ejector is OPEN, Right Ejector is OPEN

%PLATFORM-2-XBAR_REMOVE: Xbar 3 removed (Serial number XXX)

Xbar Ports  Module-Type                         Model              Status

---  -----  ----------------------------------- ------------------ ----------

3    0      Fabric Module                       N/A                powered-dn

?

Xbar Power-Status  Reason

---  ------------  ---------------------------

3    powered-dn     failure(powered-down) since maximum number of bringups were exceeded

Alternativ können Xbar-ASIC-Fehler angezeigt werden:

%MODULE-4-MOD_WARNING: Module 15 (serial: XXX) reported warning due to

X-bar Interface ASIC Error in device 70 (device error 0xc4600248)

%OC_USD-SLOT15-2-RF_CRC: OC2 received packets with CRC error from MOD 15

through XBAR slot 3/inst 2

Ursache

Dieses Problem ist entweder auf ein fehlerhaftes oder falsch sitzendes Xbar-Modul oder einen fehlerhaften Chassis-Steckplatz zurückzuführen.

Lösung

1. Überprüfen Sie die Ausgabe dieser Befehle:

- Anzeigeversion

- Schaumodul

- Anzeigeprotokollierung

- show logging nvram

- show module internal exception log

- show module internal event history

- Schaukern

- Systemrücksetzgrund anzeigen

- Schauumgebung | in xbar

- show system internal platform internal event history xbar X ist die xbar #

- Anzeige systeminterner xbar-client-interner Ereignisverlaufsfehler

- show system internal xbar all

- Systeminterne xbar-Ereignisverlaufsfehler anzeigen

2. Setzen Sie das Xbar-Modul wieder fest ein, und prüfen Sie den Status.

3. Wenn der Wiedereinsetzen fehlschlägt, testen Sie xbar in einem anderen Steckplatz, oder testen Sie den Steckplatz mit einem anderen Xbar-Modul, um sicherzustellen, dass das Gehäuse in Ordnung ist.

4. Ersetzen Sie die fehlerhafte Hardware basierend auf den Tests in den Schritten 2 und 3.

Problem: Fehlgeschlagenes Lüftermodul N7K-C7010-FAN-F

Ein oder mehrere dieser Lüfterfehler-Symptome wurden beobachtet:

%PLATFORM-5-FAN_STATUS: Fan module 3 (Serial number XXX)

Fan3(fab_fan1) current-status is  FAN_FAIL

Nexus 7000#show environment fan

Fan3(fab_fan1)  N7K-C7010-FAN-F    1.1     Failure (Failed Fanlets: 2 6 7 8 9 10 14 15 )

Fan4(fab_fan2)  N7K-C7010-FAN-F    1.1     Ok

...

#show hardware

----------------------------------

Chassis has 4 Fan slots

----------------------------------

Fan3(fab_fan1) failed

Model number is N7K-C7010-FAN-F

...

Ursache

In den meisten Fällen handelt es sich dabei um einen Ausfall des Lüfters oder des Chassis-Steckplatzes.

Lösung

1. Überprüfen Sie die Ausgabe dieser Befehle:

- Anzeigeversion

- Schaumodul

- Bestand anzeigen

- Anzeigeprotokoll

- show log nvram

- show environment fan

2. Testen Sie dieses N7K-C7010-FAN-F in einem anderen geeigneten Chassis.

3. Ersetzen Sie den Lüfter oder das Gehäuse entsprechend den Ergebnissen der Schritte 1 und 2.

Problem: %PLATFORM-2-PS_CAPACITY_CHANGE-Netzteilalarm

Es werden Warnmeldungen zu Kapazitätsänderungen angezeigt, manchmal sehr häufig.

%PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS2 changed its capacity.

possibly due to On/Off or power cable removal/

2013 Oct 17 17:06:40 ... last message repeated 14 times

Ursache

Dieses Problem ist entweder auf ein defektes oder nicht angeschlossenes Netzkabel oder auf einen Netzteilfehler zurückzuführen.

Lösung

Überprüfen Sie die Ausgabe des Befehls show env power detail und den Netzteilstatus. In diesem Beispiel sind beide Akkorde angeschlossen, das zweite jedoch nur eine Kapazität von 1200 W anstelle von 3000 W und muss für 220 V AC auf dem N7K-AC-6.0KW konfiguriert werden. Die Stromquelle wurde in Ordnung getestet. Ersetzen Sie das Netzteil.

PS_2 total capacity:    4200 W   Voltage:50Vchord 1    capacity:    3000 W chord 1

connected to 110v AC chord 2    capacity:    1200 W chord 2    connected to 220v AC

Problem: %PLATFORM-5-PS_STATUS: Netzteil X PS_FAIL-Alarm

Diese Warnung wird auf der Plattform angezeigt:

%PLATFORM-5-PS_STATUS: PowerSupply 3 current-status is PS_FAIL

%PLATFORM-2-PS_FAIL: Power supply 3 failed or shut down (Serial number xxxxx)

Ursache

Diese Warnmeldung ist entweder auf ein defektes oder nicht angeschlossenes Netzkabel oder auf einen Netzteilfehler zurückzuführen.

Lösung

1. Überprüfen Sie die Ausgabe dieser Befehle:

- Anzeige von Leistungsangaben zur Umgebung

- Schauleistung

2. Schließen Sie das fehlerhafte Netzteil wieder an. Verwenden Sie das redundante Netzteil, um sicherzustellen, dass die Stromversorgung nicht offline geht.

3. Senden Sie eine RMA für das Netzteil. Verwenden Sie das redundante Netzteil, um sicherzustellen, dass die Stromversorgung nicht offline geht.

Referenzen

Redundante Stromversorgung für die Cisco Nexus Serie 7000

Problem: Netzteilproblem auf FEX

Diese Alarme werden für das FEX-Netzteil angezeigt:

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Module 1: Runtime diag detected major event:

Voltage failure on power supply: 1

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 System minor alarm on power

supply 1: failed

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Recovered: System minor alarm

on power supply 1: failed

Lösung

Überprüfen Sie Hardware- und Stromversorgungsprobleme. Wenn ein Softwareproblem vorliegt, werden Fehlermeldungen auch nach dem Austausch der Hardware angezeigt.

Methoden zur Behebung dieser Probleme:

1. Setzen Sie das FEX-Netzteil wieder ein. Verwenden Sie das redundante Netzteil, um sicherzustellen, dass die Stromversorgung nicht offline geht.

2. Senden Sie eine RMA für das FEX-Netzteil. Verwenden Sie das redundante Netzteil, um sicherzustellen, dass die Stromversorgung nicht offline geht.

3. Wiederholen Sie diese Schritte für das zweite Netzteil.

Prüfen und beantworten Sie diese Fragen, um die Umstände des Fehlers zu bestimmen:

1. Wie viele FEX-Netzteile sind betroffen?

2. Haben Sie für einen kleinen Alarm die Eingangsquelle ausgetauscht, und hat das etwas bewirkt?

3. Verfügen Sie über andere FEX-Netzteile mit Problemen?

4. Haben Sie noch andere Geräte mit derselben Stromquelle?

5. Haben Sie das Netzkabel ersetzt?

6. Gab es einen Stromstoß oder einen Funken in der Umgebung?

Erfassen Sie die Ausgabe dieser Befehle, um Fehler zu untersuchen:

- show sprom fex 100 all

- Protokollierungsprotokoll anzeigen | nicht mehr

- show tech fex 100 | nicht mehr

- FEX 100 anhängen

- show platform software satctrl trace trace

Bekannter Softwarefehler

Cisco Bug-ID CSCtr77620

Problem: Netzteile des Typs N7K-AC-6,0KW werden als fehlerhaft gemeldet

Die Emerson-Netzteile N7K-AC-6.0KW werden als Fail/Shut (Fehlgeschlagen/Herunterfahren) gemeldet, aber der Switch funktioniert einwandfrei, und für das fehlerhafte Netzteil wird eine nicht 0-prozentige Ausgabe angezeigt.

Ursache

Bei einem Netzteil, bei dem beide Eingänge aktiv sind, kann das Netzteil einen Unterspannungsfehler beheben, wenn ein Eingangsstecker getrennt, wieder angeschlossen und innerhalb von 1,5 Sekunden getrennt wird. NX-OS kann das Netzteil als ausgefallen kennzeichnen. Bei einer anderen Variante entfernen Sie bei einem Netzteil mit zwei Eingängen einen Eingang und warten 20 bis 30 Sekunden. Das Netzteil kann gelegentlich den internen Fehleralarm einstellen, und NX-OS meldet das Netzteil als fehlerhaft.

Die Cisco Bug-ID CSCty78612 ändert die Firmware der Netzteile, um das Problem zu beheben.

Die Cisco Bug-ID CSCuc86262 fügt eine Softwareverbesserung hinzu, um diese Fehlfehler zu beheben. NX-OS überwacht jetzt autonom den Status der Netzteil-Einheit (PSU) und ändert ihn auf den entsprechenden Status, wenn der gemeldete Status vom tatsächlichen Status abweicht.

Lösung

Geben Sie den Befehl show env power detail ein, und überprüfen Sie die tatsächliche Ausgabe, um den Fehlfehler zu überprüfen:

Nexus7000# show env power

Power Supply:

Voltage: 50 Volts

Power Actual Total

Supply Model Output Capacity Status

(Watts ) (Watts )

------- ------------------- ----------- ----------- --------------

1 N7K-AC-6.0KW 0 W 0 W Shutdown

2 N7K-AC-6.0KW 3888 W 6000 W Fail/Shut

Der fehlerhafte Fail/Shut-Status wird gelöscht, wenn Sie das Netzteil ausschalten/einschalten.

Die Cisco Bug-ID CSCty78612 ändert die Firmware auf dem PSU. Die Software wurde durch die Cisco Bug ID CSCuc86262 verbessert, die Benachrichtigungen bei falschem Ausfall/Herunterfahren mit der Korrektur der falschen Bits wiederherstellt, wenn das Netzteil zur Laufzeit normal funktioniert. In den NX-OS-Versionen 5.2(9), 6.1(3), 6.2(2) und höher ist die Erweiterung vorhanden, die eine RMA vermeidet.

Problem: Software-Paketverluste

Ein Teil der großen Pakete wird verworfen, wenn eine hohe Rate von IP-Paketen mit einer Länge von mehr als der konfigurierten MTU auf der Ausgangsschnittstelle des Pakets vorhanden ist.

Ursache

Dieses Verhalten wird erwartet. Wenn das System ein IP-Paket mit einer Länge empfängt, die länger ist als die konfigurierte MTU auf der Ausgangsschnittstelle des Pakets, sendet das System dieses Paket an die Steuerungsebene, die die Fragmentierung übernimmt. In NX-OS 4.1.3 und höher wird ein Durchsatzbegrenzer auf diese getesteten Pakete angewendet. Dadurch wird der Standardwert auf maximal 500 pps begrenzt.

Lösung

Dies ist ein bekannter Softwarefehler in der Cisco Bug-ID CSCsu01048.

Problem: USER-2-SYSTEM_MSG FIPS Self-Test Failure System-Fehler

Der Fehler "USER-2-SYSTEM_MSG FIPS-Selbsttest-Fehler in DCOS_rand - netstack" wird angezeigt.

Ursache

Bei jeder Generierung einer zufälligen Zahl wird der Selbsttest des Conditional Random Number Generator (CRNG) ausgeführt. Wenn der Test fehlschlägt, wird eine Syslog-Meldung protokolliert. Dies erfolgt gemäß der FIPS-Empfehlung (Federal Information Processing Standards). Die Auswirkungen sind jedoch harmlos, da die Zufallszahl wieder erzeugt wird.

In NX-OS gibt es zwei Arten von Zufallszahlen-Generatoren (Random Number Generators, RNGs):

- FIPS RNG, das in der openssl crypto library implementiert ist

- Nicht-FIPS-RNG ist das Linux-RNG.

Nach FIPS müssen alle RNGs den Conditional Random Number Generator Test (CRNGT) implementieren. Im Test wird die aktuell generierte Zufallszahl mit der vorherigen verglichen. Wenn die Zahlen identisch sind, wird eine Syslog-Meldung generiert, und es wird eine weitere zufällige Nummer generiert.

Der Test wird ausgeführt, um sicherzustellen, dass die Zufallszahl eindeutig ist. Es treten keine funktionalen Auswirkungen auf, da die Nummer regeneriert wird.

Lösung

Diese Meldung ist für den Systembetrieb harmlos. Ab Cisco NX-OS 5.2x und höher wird der Schweregrad der Meldung von 2 abgesenkt, sodass sie bei der Standardprotokollkonfiguration nicht mehr angezeigt wird. Diese Protokollierung erfolgt im Rahmen interner NX-OS-Selbsttests für verschiedene Funktionen auf dem Switch.

Dies ist ein bekannter Softwarefehler in der Cisco Bug-ID CSCtn70083.