Fehlerbehebung bei Fehlern bei der Synchronisierung mit Xbar auf Switches der Serie Nexus 7000
Inhalt
Einführung
In diesem Dokument wird beschrieben, wie eine fehlerhafte Kreuzschiene (Xbar) identifiziert wird, wenn ein Modul aufgrund eines Xbar-Synchronisierungsfehlers auf einem Switch der Cisco Nexus 7000-Serie ausgefallen ist. Das Fehlerbehebungsverfahren für dieses Problem beinhaltet die Erfassung von Daten, Datenanalysen und einen Eliminierungsprozess, um die Problemkomponente zu isolieren.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse der CLI des Cisco Nexus-Betriebssystems (NX-OS) zu verfügen.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf dem Cisco Nexus-Switch der Serie 7000, auf dem NX-OS Version 6.1(2) ausgeführt wird, können aber auch mit jeder NX-OS-Version verwendet werden.
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.
Problem
Das N7K-F248XP-25E-Modul ist aufgrund eines Xbar-Synchronisierungsfehlers beim Booten des Moduls nicht verfügbar. Wenn das Modul in Steckplatz 1 am Gehäuse eingesetzt wurde, wurde es heruntergefahren. Dies kann aus einem der folgenden Gründe auftreten:
- Fehlerhaftes Modul
- Falsche Xbar
- Schlechter oder verbogener Stift an der Rückwandplatine
Lösung
Falls beim N7K-F248XP-25E-Modul ein Hardwarefehler vermutet wird, müssen Sie die Protokolle anzeigen, um festzustellen, ob der Grund für den Fehler auf ein fehlerhaftes Modul oder auf einen Xbar-Synchronisierungsfehler zurückzuführen ist.
Um das Problem in diesem Beispiel weiter zu isolieren, wurde das Modul in einen anderen Steckplatz eingesetzt und wie erwartet aktiviert. Dies weist darauf hin, dass das Modul nicht fehlerhaft ist. Daher liegt das Problem entweder mit der Xbar-Fabric oder mit dem Chassis vor.
Dieses Ausnahmeprotokoll trat auf, als das Modul in Steckplatz 1 heruntergefahren wurde:
show module internal exceptionlog module 1
********* Exception info for module 1 ********
exception information --- exception instance 1 ----
Module Slot Number: 1
Device Id : 88
Device Name : XbarComplex
Device Errorcode : 0x00000008
Device ID : 00 (0x00)
Device Instance : 00 (0x00)
Dev Type (HW/SW) : 00 (0x00)
ErrNum (devInfo) : 08 (0x08)
System Errorcode : 0x40240012 xbar sync failed during module bringup
(DevErr is LinkNum)
Error Type : Informational
PhyPortLayer : Unknown
Port(s) Affected : none
DSAP : 0 (0x0)
UUID : 0 (0x0)
Time : Thu Mar 20 15:55:19 2014
(Ticks: 532B0F67 jiffies)
exception information --- exception instance 2 ----
Module Slot Number: 1
Device Id : 88
Device Name : XbarComplex
Device Errorcode : 0x00000008
Device ID : 00 (0x00)
Device Instance : 00 (0x00)
Dev Type (HW/SW) : 00 (0x00)
ErrNum (devInfo) : 08 (0x08)
System Errorcode : 0x40240012 xbar sync failed during module bringup
(DevErr is LinkNum)
Error Type : Informational
PhyPortLayer : Unknown
Port(s) Affected : none
DSAP : 0 (0x0)
UUID : 0 (0x0)
Time : Thu Mar 20 15:53:12 2014
(Ticks: 532B0EE8 jiffies)
Laut diesen Ausnahmeprotokollen liegt das Problem eindeutig bei der Xbar oder beim Gehäuse in Steckplatz 1.
Um das Problem weiter zu isolieren, müssen Sie jede Xbar einzeln entfernen, während Sie das Modul in Steckplatz 1 überwachen, bis es problemlos hochgefahren werden kann. Damit wird bestätigt, dass ein Problem mit einem bestimmten Xbar Fabric-Modul besteht. In diesem Fall würden Sie mit der Retourengenehmigung (Return Material Authorization, RMA) für die fehlerhafte Hardware fortfahren.
Dies ist jedoch ein langwieriger Vorgang und erfordert ein langes Wartungsfenster. Um den exakten Xbar-Fabric-Steckplatz zu finden, der das Synchronisierungsproblem mit dem Modul verursacht, können Sie wie folgt vorgehen:
show system internal xbar event-history errors
-----------------------------------------------------
7) Event:E_DEBUG, length:67, at 384460 usecs after Thu Mar 20 15:55:19 2014
[102] xbm_perform_error_action(1413): MTS_OPC_LC_INSERTED error 0x1
8) Event:E_DEBUG, length:104, at 384347 usecs after Thu Mar 20 15:55:19 2014
[102] send_exception_log_msg_to_lcm(1101): module 1 DevId 88 dev_err 0x8 sys
_err 0x40240012 err_type 0x4
9) Event:E_DEBUG, length:59, at 384343 usecs after Thu Mar 20 15:55:19 2014
[102] xbm_mod_ac_error(221): Sync fail for module 1 link 8
10) Event:E_DEBUG, length:66, at 384341 usecs after Thu Mar 20 15:55:19 2014
[102] xbm_mod_ac_error(210): Error for Slot 0 error_code 0x877660c
11) Event:E_DEBUG, length:62, at 384298 usecs after Thu Mar 20 15:55:19 2014
[102] xbm_sync_seq_failed(1169): Sync fail for module 1 link 8
In diesen Protokollen wird die Meldung Synchronisierung für Verbindung 8 in Modul 1 fehlgeschlagen angezeigt. Anschließend müssen Sie den Fabric-Steckplatz identifizieren, dem Link 8 zugeordnet ist. Um dies zu bestimmen, müssen Sie die Ausgabe des Befehls show system internal xbar sw überprüfen:
show system internal xbar sw
Module in slot 1 (present = 0)
Dedicated X-link 255
rid 0x2000000 type 0 state 0 sub_type 0 node_id 0x0
sw_card_id 0x0 lc_node_addr 0x0 feature_bits 0x0
timer: hdl 0x86fcc20 rid 0x2000000 ev_id 0xffff timer_id 0x41a tim_type 0x2
Link_Info:: Num Links 10 max Edp 10
Link_num 0
is_synced 0 is_edp 0 num_sync_try 0
Link_num 1
is_synced 0 is_edp 0 num_sync_try 0
Link_num 2
is_synced 0 is_edp 0 num_sync_try 0
Link_num 3
is_synced 0 is_edp 0 num_sync_try 0
Link_num 4
is_synced 0 is_edp 0 num_sync_try 0
Link_num 5
is_synced 0 is_edp 0 num_sync_try 0
Link_num 6
is_synced 0 is_edp 0 num_sync_try 0
Link_num 7
is_synced 0 is_edp 0 num_sync_try 0
Link_num 8
is_synced 0 is_edp 0 num_sync_try 3
Link_num 9
is_synced 0 is_edp 0 num_sync_try 0
Link_Map:: Num Links 10 max Edp 10
Link_num 0
connected to fab [10.0] active_lnk 1
fi_to_mon 0 fi_to_use 0
Link_num 1
connected to fab [10.0] active_lnk 1
fi_to_mon 0 fi_to_use 0
Link_num 2
connected to fab [11.0] active_lnk 1
fi_to_mon 1 fi_to_use 1
Link_num 3
connected to fab [11.0] active_lnk 1
fi_to_mon 1 fi_to_use 1
Link_num 4
connected to fab [12.0] active_lnk 1
fi_to_mon 2 fi_to_use 2
Link_num 5
connected to fab [12.0] active_lnk 1
fi_to_mon 2 fi_to_use 2
Link_num 6
connected to fab [13.0] active_lnk 1
fi_to_mon 3 fi_to_use 3
Link_num 7
connected to fab [13.0] active_lnk 1
fi_to_mon 3 fi_to_use 3
Link_num 8
connected to fab [14.0] active_lnk 1
fi_to_mon 4 fi_to_use 4
Link_num 9
connected to fab [14.0] active_lnk 1
fi_to_mon 4 fi_to_use 4
In der Ausgabe sehen Sie, dass Link_num 8 (Link 8) mit fab [14.0] (Fabric-Steckplatz 14), also Xbar 5, verbunden ist.
Um fab [14.0] (die Fabric in Steckplatz 5) zu identifizieren, geben Sie den Befehl show module ein:
show module
Xbar Ports Module-Type Model Status
--- ----- -------------------------------- ----------------- ------
4 0 Fabric Module 2 N7K-C7010-FAB-2 ok
Xbar MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
1 NA JAF1739AQTP
2 NA JAF1739AJAA
3 NA JAF1739AQDG
4 NA JAF1739ATHG
5 NA JAF1739AQEF
In der Ausgabe des Befehls show module können Sie das Xbar-Fabric-Modul in Steckplatz 5 anzeigen.
Sie sollten jetzt die korrekte Identifizierung der Fabric haben, die den Synchronisierungsfehler zum Modul in Steckplatz 1 verursacht hat. In diesem Beispiel wurde die Fabric aus Steckplatz 5 entfernt, und das Modul in Steckplatz 1 wurde fehlerfrei gestartet. Die fehlerhafte Xbar kann jetzt ausgetauscht werden.
Zugehörige Informationen
- Fehlerbehebung bei Nexus 7000 Fabric CRC-Fehlern
- Technischer Support und Dokumentation - Cisco Systems
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
17-Jun-2015 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)