In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die Fehlerbehebungsverfahren für die Nexus 7000 (N7K)-Hardware beschrieben.
Dieser Befehl zeigt den Status des Lüftermoduls auf dem Switch an.
SITE1-AGG1# show environment fan Fan: ------------------------------------------------------ Fan Model Hw Status ------------------------------------------------------ Fan1(sys_fan1) N7K-C7010-FAN-S 1.1 Ok Fan2(sys_fan2) N7K-C7010-FAN-S 1.1 Ok Fan3(fab_fan1) N7K-C7010-FAN-F 1.1 Ok Fan4(fab_fan2) N7K-C7010-FAN-F 1.1 Ok Fan_in_PS1 -- -- Ok Fan_in_PS2 -- -- Ok Fan_in_PS3 -- -- Shutdown Fan Zone Speed: Zone 1: 0x78 Zone 2: 0x58 Fan Air Filter : Present
Der Lüfterstatus kann OK, Fehler oder fehlerhaft sein.
“Fan module removed. Fan module has been absent for 120 seconds"
Dieser Befehl zeigt die installierten Netzteile, die Zusammenfassung des Stromverbrauchs und den Status der Netzteile am Switch an.
Der Befehl sowie eine Beispielausgabe werden bereitgestellt.
SITE1-AGG1# show environment power Power Supply: Voltage: 50 Volts Power Actual Total Supply Model Output Capacity Status (Watts ) (Watts ) ------- ------------------- ----------- ----------- -------------- 1 N7K-AC-6.0KW 1179 W 6000 W Ok 2 N7K-AC-6.0KW 1117 W 6000 W Ok 3 N7K-AC-6.0KW 0 W 0 W Shutdown Actual Power Module Model Draw Allocated Status (Watts ) (Watts ) ------- ------------------- ----------- ----------- -------------- 1 N7K-M148GT-11 N/A 400 W Powered-Up 3 N7K-M132XP-12 N/A 750 W Powered-Up 4 N7K-F132XP-15 318 W 385 W Powered-Up 5 N7K-SUP1 N/A 210 W Powered-Up 6 N7K-SUP1 N/A 210 W Powered-Up 10 N7K-M132XP-12L 535 W 750 W Powered-Up Xb1 N7K-C7010-FAB-1 N/A 80 W Powered-Up Xb2 N7K-C7010-FAB-1 N/A 80 W Powered-Up Xb3 N7K-C7010-FAB-1 N/A 80 W Powered-Up Xb4 xbar N/A 80 W Absent Xb5 xbar N/A 80 W Absent fan1 N7K-C7010-FAN-S 133 W 720 W Powered-Up fan2 N7K-C7010-FAN-S 133 W 720 W Powered-Up fan3 N7K-C7010-FAN-F 12 W 120 W Powered-Up fan4 N7K-C7010-FAN-F 12 W 120 W Powered-Up N/A - Per module power not available Power Usage Summary: -------------------- Power Supply redundancy mode (configured) PS-Redundant Power Supply redundancy mode (operational) Non-Redundant Total Power Capacity (based on configured mode) 12000 W Total Power of all Inputs (cumulative) 12000 W Total Power Output (actual draw) 2296 W Total Power Allocated (budget) 4785 W Total Power Available for additional modules 7215 W
Der Netzteilstatus kann wie folgt lauten:
Ausfall des Netzteils:
Jedes Netzteil verfügt über eine LED, die den Status der Ausgangsleistung anzeigt. Diese LED wird direkt vom Netzteil gesteuert, und eine rote Farbe weist auf einen Netzteilfehler hin. Beim Scannen des Syslog werden möglicherweise abwechselnde Meldungen zu Stromausfällen und zur Wiederherstellung angezeigt, die weitere Hinweise auf Probleme mit der Stromversorgung geben.
Jede Karte im Gehäuse verfügt über mindestens zwei Temperatursensoren. Jeder Temperatursensor ist mit einem kleinen und einem großen Grenzwert konfiguriert. Dieser Befehl mit Beispielausgabe zeigt, wie Temperaturinformationen vom Switch abgerufen werden können:
SITE1-AGG1# show environment temperature Temperature: -------------------------------------------------------------------- Module Sensor MajorThresh MinorThres CurTemp Status (Celsius) (Celsius) (Celsius) -------------------------------------------------------------------- 1 Crossbar(s5) 105 95 46 Ok 1 CTSdev4 (s9) 115 105 56 Ok 1 CTSdev5 (s10) 115 105 57 Ok 1 CTSdev7 (s12) 115 105 56 Ok 1 CTSdev9 (s14) 115 105 53 Ok 1 CTSdev10(s15) 115 105 53 Ok 1 CTSdev11(s16) 115 105 52 Ok 1 CTSdev12(s17) 115 105 51 Ok 1 QEng1Sn1(s18) 115 105 51 Ok 1 QEng1Sn2(s19) 115 105 50 Ok 1 QEng1Sn3(s20) 115 105 48 Ok 1 QEng1Sn4(s21) 115 105 48 Ok 1 L2Lookup(s22) 120 110 47 Ok 1 L3Lookup(s23) 120 110 54 Ok 3 Crossbar(s5) 105 95 50 Ok 3 QEng1Sn1(s12) 115 110 69 Ok 3 QEng1Sn2(s13) 115 110 67 Ok 3 QEng1Sn3(s14) 115 110 66 Ok 3 QEng1Sn4(s15) 115 110 67 Ok 3 QEng2Sn1(s16) 115 110 70 Ok 3 QEng2Sn2(s17) 115 110 67 Ok 3 QEng2Sn3(s18) 115 110 66 Ok 3 QEng2Sn4(s19) 115 110 67 Ok 3 L2Lookup(s27) 115 105 51 Ok 3 L3Lookup(s28) 120 110 64 Ok 4 Crossbar1(s1) 105 95 69 Ok 4 Crossbar2(s2) 105 95 52 Ok 4 L2dev1(s3) 105 95 37 Ok 4 L2dev2(s4) 105 95 43 Ok 4 L2dev3(s5) 105 95 45 Ok 4 L2dev4(s6) 105 95 45 Ok 4 L2dev5(s7) 105 95 40 Ok 4 L2dev6(s8) 105 95 41 Ok 4 L2dev7(s9) 105 95 42 Ok 4 L2dev8(s10) 105 95 40 Ok 4 L2dev9(s11) 105 95 38 Ok 4 L2dev10(s12) 105 95 38 Ok 4 L2dev11(s13) 105 95 38 Ok 4 L2dev12(s14) 105 95 37 Ok 4 L2dev13(s15) 105 95 34 Ok 4 L2dev14(s16) 105 95 33 Ok 4 L2dev15(s17) 105 95 33 Ok 4 L2dev16(s18) 105 95 32 Ok 5 Intake (s3) 60 42 24 Ok 5 EOBC_MAC(s4) 105 95 42 Ok 5 CPU (s5) 105 95 42 Ok 5 Crossbar(s6) 105 95 47 Ok 5 Arbiter (s7) 110 100 55 Ok 5 CTSdev1 (s8) 115 105 44 Ok 5 InbFPGA (s9) 105 95 43 Ok 5 QEng1Sn1(s10) 115 105 48 Ok 5 QEng1Sn2(s11) 115 105 46 Ok 5 QEng1Sn3(s12) 115 105 44 Ok 5 QEng1Sn4(s13) 115 105 44 Ok 6 Intake (s3) 60 42 24 Ok 6 EOBC_MAC(s4) 105 95 40 Ok 6 CPU (s5) 105 95 36 Ok 6 Crossbar(s6) 105 95 45 Ok 6 Arbiter (s7) 110 100 52 Ok 6 CTSdev1 (s8) 115 105 43 Ok 6 InbFPGA (s9) 105 95 43 Ok 6 QEng1Sn1(s10) 115 105 53 Ok 6 QEng1Sn2(s11) 115 105 51 Ok 6 QEng1Sn3(s12) 115 105 48 Ok 6 QEng1Sn4(s13) 115 105 48 Ok 10 Crossbar(s5) 105 95 46 Ok 10 QEng1Sn1(s12) 115 110 65 Ok 10 QEng1Sn2(s13) 115 110 62 Ok 10 QEng1Sn3(s14) 115 110 64 Ok 10 QEng1Sn4(s15) 115 110 65 Ok 10 QEng2Sn1(s16) 115 110 65 Ok 10 QEng2Sn2(s17) 115 110 63 Ok 10 QEng2Sn3(s18) 115 110 64 Ok 10 QEng2Sn4(s19) 115 110 65 Ok 10 L2Lookup(s27) 115 105 51 Ok 10 L3Lookup(s28) 120 110 71 Ok xbar-1 Intake (s2) 60 42 27 Ok xbar-1 Crossbar(s3) 105 95 55 Ok xbar-2 Intake (s2) 60 42 25 Ok xbar-2 Crossbar(s3) 105 95 49 Ok xbar-3 Intake (s2) 60 42 26 Ok xbar-3 Crossbar(s3) 105 95 47 Ok
Der Eingangssensor befindet sich am Luftstrom-Eingang und ist der wichtigste Indikator für die Kartentemperatur. Alle Softwareaktionen werden auf der Grundlage einer schwerwiegenden Temperaturverletzung des Eingangssensors durchgeführt.
Dies führt zu einer Syslog-Meldung, einem Call Home-Ereignis und einem Simple Network Management Protocol (SNMP)-Trap. Diese Meldungen der Priorität 1 oder 2 werden im Syslog gedruckt - Modul 1 meldet einen Alarm zur Haupt-Temperatur (Sensor-Index 1 Temperatur 76).
Die Linecard wird sofort heruntergefahren, wenn diese Syslog-Meldung mit der Priorität 0 - Modul 1 aufgrund eines größeren Temperaturalarms heruntergefahren wird.
Der redundante Supervisor wird sofort heruntergefahren. Dies führt je nach dem Supervisor, der den Schwellenwert überschritten hat, zum Switchover oder zum Standby-Herunterfahren. Diese Syslog-Meldung der Priorität 0 wird angezeigt - Modul 1 ist aufgrund eines Alarm wegen großer Temperatur heruntergefahren.
Manchmal fallen die Temperatursensoren aus und sind nicht mehr zugänglich. Für diese Bedingung wird keine explizite Softwareaktion ausgeführt. Diese Syslog-Meldung mit Priorität 4 wird gedruckt - Temperatursensor in Modul 1 ist ausgefallen.
Das Debuggen eines Reset-/Neuladevorgangs auf Switch-/Supervisor-Ebene beinhaltet in der Regel das Überprüfen von Debug-/Protokollinformationen, die im nichtflüchtigen RAM (Non-Volatile Random Access Memory, NVRAM) der Supervisoren gespeichert sind. Im NVRAM gibt es drei Arten von Debug-/Protokollinformationen, die wichtige Informationen enthalten können.
1.1 Grund für Zurücksetzen
Die Gründe für die Zurücksetzung werden auf jedem Supervisor-NVRAM gespeichert. Jeder Supervisor speichert seinen eigenen Grund zum Zurücksetzen. Wenn der Switch wieder hochgefahren ist, können die Gründe für das Zurücksetzen mit diesem CLI-Befehl abgelaufen sein. Eine Beispielausgabe wird bereitgestellt.
SITE1-AGG1# show system reset-reason ----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) --- 1) No time Reason: Unknown Service: Version: 6.1(2) 2) No time Reason: Unknown Service: Version: 6.1(1) 3) At 246445 usecs after Wed Nov 7 21:26:59 2012 Reason: Reset triggered due to Switchover Request by User Service: SAP(93): Swover due to install Version: 6.1(2) 4) At 36164 usecs after Tue Nov 6 01:18:15 2012 Reason: Reset Requested by CLI command reload Service: Version: 5.2(1) ----- reset reason for Supervisor-module 5 (from Supervisor in slot 6) --- 1) At 939785 usecs after Wed Nov 7 22:28:36 2012 Reason: Reset due to upgrade Service: Version: 6.1(1) 2) At 687128 usecs after Thu Mar 29 18:06:34 2012 Reason: Reset of standby by active sup due to sysmgr timeout Service: Version: 6.0(2) 3) At 10012 usecs after Thu Mar 29 17:56:13 2012 Reason: Reset of standby by active sup due to sysmgr timeout Service: Version: 6.0(2) 4) At 210045 usecs after Thu Mar 29 17:45:51 2012 Reason: Reset of standby by active sup due to sysmgr timeout Service: Version: 6.0(2) ----- reset reason for Supervisor-module 6 (from Supervisor in slot 5) --- 1) At 50770 usecs after Wed Nov 7 21:12:19 2012 Reason: Reset due to upgrade Service: Version: 6.1(2) 2) At 434294 usecs after Mon Nov 5 22:10:16 2012 Reason: Reset due to upgrade Service: Version: 5.2(1) 3) At 518 usecs after Mon Nov 5 21:21:51 2012 Reason: Reset Requested by CLI command reload Service: Version: 5.2(7) 4) At 556934 usecs after Mon Nov 5 21:12:15 2012 Reason: Reset due to upgrade Service: Version: 5.2(1) ----- reset reason for Supervisor-module 6 (from Supervisor in slot 6) --- 1) No time Reason: Unknown Service: Version: 6.1(2) 2) At 462775 usecs after Wed Nov 7 22:38:44 2012 Reason: Reset triggered due to Switchover Request by User Service: SAP(93): Swover due to install Version: 6.1(1) 3) No time Reason: Unknown Service: Version: 6.1(2) 4) No time Reason: Unknown Service: Version: 5.2(1)
Bis zu den letzten 4 Gründen zum Zurücksetzen werden gespeichert und angezeigt. Ein Grund zum Zurücksetzen enthält:
Manchmal wird ein Grund für das Zurücksetzen von Unbekannt angezeigt. Zurücksetzungsgründe, die der Software nicht bekannt sind oder über die Softwarekontrolle hinausgehen, werden als Unbekannt eingestuft. Dazu gehören in der Regel:
1.2 NVRAM-Syslog
Syslog-Meldungen der Priorität 0, 1 und 2 werden ebenfalls im NVRAM des Supervisors angemeldet. Wenn der Switch online wiederhergestellt ist, können mithilfe dieses Befehls Syslog-Meldungen im NVRAM angezeigt werden. Der Befehl und eine Beispielausgabe werden angezeigt:
SITE1-AGG1# show log nvram 2012 Nov 17 05:59:51 SITE1-AGG1 %$ VDC-1 %$ %SYSMGR-STANDBY-2-LAST_CORE_BASIC_TRACE: : PID 15681 with message 'Core detected due to hwclock crash'. 2012 Nov 17 12:07:11 SITE1-AGG1 %$ VDC-1 %$ %CMPPROXY-2-LOG_CMP_UP: Connectivity Management processor(on module 5) is now UP 2012 Nov 17 12:07:56 SITE1-AGG1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 1 has come online 2012 Nov 17 12:07:58 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-PS_OK: Power supply 1 ok (Serial number DTM131000A4) 2012 Nov 17 12:07:58 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-PS_FANOK: Fan in Power supply 1 ok 2012 Nov 17 12:07:58 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-PS_OK: Power supply 2 ok (Serial number DTM140700HS) 2012 Nov 17 12:07:58 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-PS_FANOK: Fan in Power supply 2 ok 2012 Nov 17 12:07:58 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-PS_DETECT: Power supply 3 detected but shutdown (Serial number DTM1413004P) 2012 Nov 17 12:07:59 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-XBAR_DETECT: Xbar 1 detected (Serial number JAF1308ABCS) 2012 Nov 17 12:08:01 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-XBAR_DETECT: Xbar 2 detected (Serial number JAB120600NX) 2012 Nov 17 12:08:02 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-XBAR_DETECT: Xbar 3 detected (Serial number JAF1508AJHN) 2012 Nov 17 12:08:04 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_DETECT: Module 1 detected (Serial number JAB121602HP) Module-Type 10/100/1000 Mbps Ethernet Module Model N7K-M148GT-11 2012 Nov 17 12:08:04 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_PWRUP: Module 1 powered up (Serial number JAB121602HP) 2012 Nov 17 12:08:11 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_DETECT: Module 3 detected (Serial number JAF1441BSED) Module-Type 10 Gbps Ethernet Module Model N7K-M132XP-12 2012 Nov 17 12:08:11 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_DETECT: Module 4 detected (Serial number JAF1542ABML) Module-Type 1/10 Gbps Ethernet Module Model N7K-F132XP-15 2012 Nov 17 12:08:12 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_PWRUP: Module 3 powered up (Serial number JAF1441BSED) 2012 Nov 17 12:08:12 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_PWRUP: Module 4 powered up (Serial number JAF1542ABML) 2012 Nov 17 12:08:15 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_DETECT: Module 10 detected (Serial number JAF1521BNMK) Module-Type 10 Gbps Ethernet XL Module Model N7K-M132XP-12L 2012 Nov 17 12:08:15 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_PWRUP: Module 10 powered up (Serial number JAF1521BNMK) 2012 Nov 17 12:08:30 SITE1-AGG1 %$ VDC-1 %$ %CMPPROXY-STANDBY-2-LOG_CMP_UP: Connectivity Management processor(on module 6) is now UP 2012 Nov 17 12:08:33 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-FANMOD_FAN_OK: Fan module 1 (Fan1(sys_fan1) fan) ok 2012 Nov 17 12:08:33 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-FANMOD_FAN_OK: Fan module 2 (Fan2(sys_fan2) fan) ok 2012 Nov 17 12:08:33 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-FANMOD_FAN_OK: Fan module 3 (Fan3(fab_fan1) fan) ok 2012 Nov 17 12:08:33 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-FANMOD_FAN_OK: Fan module 4 (Fan4(fab_fan2) fan) ok 2012 Nov 17 12:11:40 SITE1-AGG1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 2 has come online 2012 Nov 17 12:12:31 SITE1-AGG1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 3 has come online 2012 Nov 17 12:13:21 SITE1-AGG1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 4 has come online 2012 Nov 17 13:10:33 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_TEMPMINALRM: Xbar-1 reported minor temperature alarm. Sensor=2 Temperature=43 MinThreshold=42 2012 Nov 17 19:56:35 SITE1-AGG1 %$ VDC-1 %$ %PLATFORM-2-MOD_TEMPOK: Xbar-1 recovered from minor temperature alarm. Sensor=2 Temperature=41 MinThreshold=42
Beim Scannen des NVRAM-Syslog werden möglicherweise weitere Informationen zu dem Fehler angezeigt, der das erneute Laden/Zurücksetzen des Switches/Supervisors verursacht hat.
1.3 Modulausnahme
Ein Modul-Ausnahmeglog ist ein Wrapper-Protokoll aller Fehler und außergewöhnlicher Bedingungen auf jedem Modul. Einige Ausnahmen sind katastrophal, einige betreffen teilweise bestimmte Ports in einem Modul, andere dienen der Warnung. Jeder Protokolleintrag verfügt über das Gerät, auf dem die Ausnahme, die Ausnahmestufe, der Fehlercode, die betroffenen Ports und der Zeitstempel protokolliert wurden. Das Ausnahmeprotokoll wird im NVRAM auf dem Supervisor gespeichert und kann mit diesem CLI-Befehl angezeigt werden. Eine Beispielausgabe wird bereitgestellt.
SITE1-AGG1# show module internal exceptionlog ********* Exception info for module 1 ******** exception information --- exception instance 1 ---- Module Slot Number: 1 Device Id : 10 Device Name : eobc Device Errorcode : 0xc0005043 Device ID : 00 (0x00) Device Instance : 05 (0x05) Dev Type (HW/SW) : 00 (0x00) ErrNum (devInfo) : 67 (0x43) System Errorcode : 0x4042004d EOBC link failure Error Type : Warning PhyPortLayer : Ethernet Port(s) Affected : none DSAP : 0 (0x0) UUID : 0 (0x0) Time : Mon Nov 5 20:39:38 2012 (Ticks: 5098948A jiffies) exception information --- exception instance 2 ---- Module Slot Number: 1 Device Id : 10 Device Name : eobc Device Errorcode : 0xc0005047 Device ID : 00 (0x00) Device Instance : 05 (0x05) Dev Type (HW/SW) : 00 (0x00) ErrNum (devInfo) : 71 (0x47) System Errorcode : 0x4042004e EOBC heartbeat failure Error Type : Warning PhyPortLayer : Ethernet Port(s) Affected : none DSAP : 0 (0x0) UUID : 0 (0x0) Time : Mon Nov 5 20:39:37 2012 (Ticks: 50989489 jiffies)
Das Ausnahmetprotokoll liefert wichtige Informationen zur Behebung von Fehlern und Ausnahmebedingungen. Einige Geräte-IDs sind hier aufgeführt.
#define DEV_LINECARD_CTRL 1 #define DEV_SAHARA_FPGA 2 #define DEV_RIVIERA_ASIC 3 #define DEV_LUXOR_ASIC 4 #define DEV_FRONTIER_U_ASIC 5 #define DEV_FRONTIER_D_ASIC 6 #define DEV_ALADDIN_ASIC 7 #define DEV_SSA_ASIC 8 #define DEV_MIRAGE_ASIC 9 #define DEV_EOBC_MAC 10 #define DEV_SUPERVISOR_CTRL 11 #define DEV_BELLAGIO_ASIC 12 #define DEV_SIBYTE 13 #define DEV_FLAMINGO 14 #define DEV_FATW_CTRL 15 #define DEV_MGMT_MAC 16 #define DEV_MOD_RDN_CTRL 17 #define DEV_MOD_ENV 18 #define DEV_GG_FPGA 19 #define DEV_BALLY_MAIN_BOARD 20 #define DEV_BALLY_DAUGHTER_CARD 21 #define DEV_LOCAL_SSO_ASIC 22 #define DEV_REMOTE_SSO_ASIC 23 #define DEV_ID_UD_FIX_FPGA 24 #define DEV_ID_PM_FPGA 25 // PM - Power Mngmnt #define DEV_ID_SUP_XBUS2 26 #define DEV_MARRIOTT_FPGA 27 #define DEV_REUSE_ME 28 #define DEV_GBIC 29 #define DEV_XGFC_FPGA 30 #define DEV_GNN_FPGA 31 #define DEV_SIBYTE_MEM_EPLD 32 #define DEV_BATTERY 33 #define DEV_IDE_DISK 45 #define DEV_XCVR 46 #define DEV_LINECARD 48 #define DEV_TEMP_SENSOR 49 #define DEV_HIFN_COMP 50 #define DEV_X2 51
Im Multilayer Data Switch (MDS)-Chassis werden die Supervisor-Module etwas anders aufgerufen als die Linecard-Module. Wenn zwei Supervisoren im System vorhanden sind und das System hochgefahren ist, wird einer der Supervisoren aktiv, der andere Standby-Supervisor. Die aktive Supervisor-Aktivierung und die Standby-Supervisor-Aktivierung sind anders und werden hier behandelt.
Wenn im System kein aktiver Supervisor vorhanden ist, wird der Supervisor, der hochgefahren wird, standardmäßig dem aktiven Supervisor zugewiesen. Der so genannte Systemmanager ist für das geordnete Laden aller Softwarekomponenten auf den Supervisor verantwortlich. Eine der ersten Softwarekomponenten, die auf dem Supervisor ausgeführt wird, ist der Plattform-Manager. Diese Komponente lädt alle Kernel-Treiber und Handshakes mit dem Systemmanager. Bei Erfolg startet der Systemmanager die restlichen Prozesse basierend auf der internen Abhängigkeit zwischen den Prozessen.
Aus Sicht des Modulmanagers ist Supervisor genau wie ein anderes Linecard-Modul mit kleinen Unterschieden. Wenn der Plattform-Manager dem Modul-Manager mitteilt, dass der Supervisor aktiviert ist, wartet der Modulmanager nicht auf die Registrierung. Stattdessen informiert er alle Softwarekomponenten, dass der Supervisor aktiviert ist (auch als Sup Insertion Sequence bezeichnet). Alle Komponenten konfigurieren den Supervisor. Wenn eine Komponente bei einem Ausfall wiederhergestellt wird, wird der Supervisor neu gestartet.
Wenn ein aktiver Supervisor im System vorhanden ist, wird der Supervisor, der hochgefahren wird, standardmäßig in den Standby-Supervisor-Status versetzt. Der Standby-Supervisor muss den Status des aktiven Supervisors spiegeln. Dies wird durch den "Systemmanager" bei aktivem Vorgang erreicht, der eine gsync (globale Synchronisierung) des aktiven Supervisor-Zustands zum Standby-Supervisor initiiert. Sobald alle Komponenten im Standby-Modus mit denen des aktiven Supervisors synchronisiert sind, wird der Modulmanager darüber informiert, dass der Standby-Supervisor eingeschaltet ist.
Der Module-Manager informiert nun alle Softwarekomponenten des aktiven Supervisors, um den Standby-Supervisor zu konfigurieren (auch bekannt als "Standby-Sup-Einfügungssequenz"). Alle Fehler von Komponenten während der Einführungssequenz für Standby-Sup führen zum Standby-Supervisor-Neustart.
MDS verwaltet während der Laufzeit viele Debuginformationen. Wenn ein Supervisor jedoch einen Großteil der Debuginformationen neu startet, gehen diese verloren. Alle wichtigen Informationen werden jedoch im nichtflüchtigen RAM gespeichert, der zur Wiederherstellung des Fehlers verwendet werden kann. Beim Neustart eines aktiven Supervisors können die in seinem nvram gespeicherten Informationen erst abgerufen werden, wenn sie wieder verfügbar sind. Sobald der Supervisor wieder verfügbar ist, können diese Befehle verwendet werden, um das persistente Protokoll auszulagern:
Switch# show logging nvram
Switch# zeigt Grund zum Zurücksetzen des Systems an
Switch# show module internal exception-log
Beispiel 1: Aktiver Sup-Neustart (aufgrund des Absturzes des Supervisor-Prozesses)
In diesem Beispiel ist ein Supervisor-Prozess abgestürzt (Service "xbar"), der den Neustart des aktiven Supervisor bewirkt. Wenn der Supervisor wieder hochgefahren wird, geben die im Grund des Zurücksetzens gespeicherten Informationen einen klaren Hinweis für den Neustart des Supervisors.
switch# show system reset-reason ----- reset reason for module 6 ----- 1) At 94009 usecs after Tue Sep 27 18:52:13 2005 Reason: Reset triggered due to HA policy of Reset Service: Service "xbar" Version: 2.1(2)
Wenn das System über einen Standby-Supervisor verfügt, wird der Standby-Supervisor jetzt zum aktiven Supervisor. Die Anzeige der Syslog-Informationen auf dem Standby-Supervisor stellt ebenfalls dieselben Informationen bereit (jedoch nicht so explizit wie die Meldung "Gründe für das Zurücksetzen des Systems anzeigen").
Switch# show logging 2005 Sep 27 18:58:05 172.20.150.204 %SYSMGR-3-SERVICE_CRASHED: Service "xbar" (PID 1225) hasn't caught signal 9 (no core). 2005 Sep 27 18:58:06 172.20.150.204 %SYSMGR-3-SERVICE_CRASHED: Service "xbar" (PID 2349) hasn't caught signal 9 (no core). 2005 Sep 27 18:58:06 172.20.150.204 %SYSMGR-3-SERVICE_CRASHED: Service "xbar" (PID 2352) hasn't caught signal 9 (no core).
Beispiel 2: Aktiver Sup-Neustart (aufgrund von Laufzeitdiagnosefehlern)
In diesem Beispiel ist der Supervisor in Steckplatz 6 aktiv, und der Schiedsrichter im Supervisor meldet einen schwerwiegenden Fehler. Wenn ein Hardwaregerät einen schwerwiegenden Fehler meldet, wird das Modul, das das Gerät enthält, neu gestartet. In diesem Fall wird der aktive Supervisor neu gestartet. Wenn ein Standby-Supervisor vorhanden ist, übernimmt der Standby-Supervisor. Syslog-Meldungen im Standby-Supervisor und im Ausnahmeprotokoll enthalten Informationen zur Identifizierung der Fehlerquelle.
Switch# show logging 2005 Sep 28 14:17:47 172.20.150.204 %XBAR-5-XBAR_STATUS_REPORT: Module 6 reported status for component 12 code 0x60a02. 2005 Sep 28 14:17:59 172.20.150.204 %PORT-5-IF_UP: Interface mgmt0 on slot 5 is up 2005 Sep 28 14:18:00 172.20.150.204 %CALLHOME-2-EVENT: SUP_FAILURE switch# show module internal exceptionlog module 6 ********* Exception info for module 6 ******** exception information --- exception instance 1 ---- device id: 12 device errorcode: 0x80000020 system time: (1127917068 ticks) Wed Sep 28 14:17:48 2005 error type: FATAL error Number Ports went bad: 1,2,3,4,5,6 exception information --- exception instance 2 ---- device id: 12 device errorcode: 0x00060a02 system time: (1127917067 ticks) Wed Sep 28 14:17:47 2005 error type: Warning Number Ports went bad: 1,2,3,4,5,6
Wenn das neu gestartete Sup erneut online ist, enthält "Grund zum Zurücksetzen des Systems anzeigen" ebenfalls relevante Informationen. In diesem Fall wurde das Modul 6 (das aktive Sup war) von Sap 48 mit dem Fehlercode 0x8000020 neu gestartet. Der Prozess, der diesen SAP besitzt, kann über den Befehl "show system internal mts sup sap 48 description" abgerufen werden, der besagt, dass der Prozess "xbar-manager" war.
switch(standby)# show system reset-reason ----- reset reason for module 6 ----- 1) At 552751 usecs after Wed Sep 28 14:17:48 2005 Reason: Reset Requested due to Fatal Module Error Service: lcfail:80000020 sap:48 node:060 Version: 2.1(2)
Beispiel 3: Standby-Sup konnte nicht online gehen
In diesem Beispiel ist das aktive Sup aktiv und aktiv, und das Standby-Sup ist mit dem System verbunden. Allerdings zeigt das Modul show nicht an, dass das Modul jemals gestartet wurde.
switch# show module Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 5 0 Supervisor/Fabric-1 DS-X9530-SF1-K9 active * 8 8 IP Storage Services Module powered-dn Mod Sw Hw World-Wide-Name(s) (WWN) --- ----------- ------ -------------------------------------------------- 5 2.1(2) 1.1 -- Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 5 00-0b-be-f7-4d-1c to 00-0b-be-f7-4d-20 JAB070307XG
Wenn Sie sich jedoch bei der Konsole des Standby-Supervisors anmelden, wird angegeben, dass es sich um einen Standby-Switch handelt.
runlog>telnet sw4-ts 2004 Trying 172.22.22.55... Connected to sw4-ts.cisco.com (172.22.22.55). Escape character is '^]'. MDS Switch login: admin Password: Cisco Storage Area Networking Operating System (SAN-OS) Software TAC support: http://www.cisco.com/tac Copyright (c) 2002-2005, Cisco Systems, Inc. All rights reserved. The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license. Some parts of this software are covered under the GNU Public License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html. switch(standby)#
Wie bereits erwähnt, werden beim Einsetzen des Standby-Supervisors in das System die Konfiguration und der Zustand aller Komponenten des aktiven Supervisors in den Standby-Modus (gsync) kopiert. Solange dieser Prozess abgeschlossen ist, berücksichtigt der aktive Supervisor nicht, dass ein Standby-Supervisor vorhanden ist. Um zu überprüfen, ob dieser Prozess abgeschlossen ist, können Sie den folgenden Befehl auf dem aktiven Supervisor ausführen. Die Ausgabe des Befehls zeigt an, dass die Synchronisierung ausgeführt wird (und wahrscheinlich noch nie abgeschlossen ist).
switch# show system redundancy status Redundancy mode --------------- administrative: HA operational: None This supervisor (sup-1) ----------------------- Redundancy state: Active Supervisor state: Active Internal state: Active with HA standby Other supervisor (sup-2) ------------------------ Redundancy state: Standby Supervisor state: HA standby Internal state: HA synchronization in progress
Der wahrscheinlichste Grund dafür ist, dass eine der Softwarekomponenten im Standby-Gerät ihren Status nicht mit dem aktiven Supervisor synchronisieren konnte. Um zu überprüfen, welche Prozesse nicht synchronisiert wurden, können Sie diesen Befehl auf dem aktiven Supervisor ausführen. Die Ausgabe zeigt an, dass viele Softwarekomponenten noch nicht mit gsync fertig gestellt sind.
switch# show system internal sysmgr gsyncstats Name Gsync done Gsync time(sec) ---------------- ---------- ------------- aaa 1 0 ExceptionLog 1 0 platform 1 1 radius 1 0 securityd 1 0 SystemHealth 1 0 tacacs 0 N/A acl 1 0 ascii-cfg 1 1 bios_daemon 0 N/A bootvar 1 0 callhome 1 0 capability 1 0 cdp 1 0 cfs 1 0 cimserver 1 0 cimxmlserver 0 N/A confcheck 1 0 core-dmon 1 0 core-client 0 N/A device-alias 1 0 dpvm 0 N/A dstats 1 0 epld_upgrade 0 N/A epp 1 1
Beim Standby-Supervisor wird außerdem festgestellt, dass die Xbar-Softwarekomponente 23-mal neu gestartet wurde. Dies scheint die wahrscheinlichste Ursache dafür zu sein, dass der Standby-Modus nicht aktiviert wurde.
switch(standby)# show system internal sysmgr service all Name UUID PID SAP state Start count ---------------- ---------- ------ ----- ----- ----------- aaa 0x000000B5 1458 111 s0009 1 ExceptionLog 0x00000050 [NA] [NA] s0002 None platform 0x00000018 1064 39 s0009 1 radius 0x000000B7 1457 113 s0009 1 securityd 0x0000002A 1456 55 s0009 1 vsan 0x00000029 1436 15 s0009 1 vshd 0x00000028 1408 37 s0009 1 wwn 0x00000030 1435 114 s0009 1 xbar 0x00000017 [NA] [NA] s0017 23 xbar_client 0x00000049 1434 917 s0009 1
Beispiel 3: Standby-Sup befindet sich im eingeschalteten Zustand
In diesem Beispiel wird der Standby-Sup in Steckplatz 6 eingefügt. show module command issued on the active-sup, shows Standby Sup is in powered-up state.
switch# show module Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 5 0 Supervisor/Fabric-1 DS-X9530-SF1-K9 active * 6 0 Supervisor/Fabric-1 powered-up 8 8 IP Storage Services Module powered-dn Mod Sw Hw World-Wide-Name(s) (WWN) --- ----------- ------ -------------------------------------------------- 5 2.1(2) 1.1 -- Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 5 00-0b-be-f7-4d-1c to 00-0b-be-f7-4d-20 JAB070307XG
In diesem Beispiel liefert die Anzeigeprotokollierung keine wertvollen Informationen und zeigt auch das interne Ausnahmeprotokoll des Moduls. Da jedoch alle Zustandsübergänge für ein bestimmtes Modul im Modulmanager gespeichert sind, können wir die Zustandsübergänge des Modulmanagers überprüfen, um herauszufinden, was falsch ist. Die internen Zustandsübergänge sind:
Switch# show module internal event-history module 5 64) FSM:<ID(1): Slot 6, node 0x0601> Transition at 563504 usecs after Wed Sep 28 14:44:53 2005 Previous state: [LCM_ST_LC_NOT_PRESENT] Triggered event: [LCM_EV_PFM_MODULE_SUP_INSERTED] Next state: [LCM_ST_SUPERVISOR_INSERTED] 65) FSM:<ID(1): Slot 6, node 0x0601> Transition at 563944 usecs after Wed Sep 28 14:44:53 2005 Previous state: [LCM_ST_SUPERVISOR_INSERTED] Triggered event: [LCM_EV_START_SUP_INSERTED_SEQUENCE] Next state: [LCM_ST_CHECK_INSERT_SEQUENCE] 66) Event:ESQ_START length:32, at 564045 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x2710, Ret:success Seq Type:SERIAL 67) Event:ESQ_REQ length:32, at 564422 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x1, Ret:success [E_MTS_TX] Dst:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_INSERTED(1081) 68) Event:ESQ_RSP length:32, at 566174 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x1, Ret:success [E_MTS_RX] Src:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_INSERTED(1081) 69) Event:ESQ_REQ length:32, at 566346 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x2, Ret:success [E_MTS_TX] Dst:MTS_SAP_NTP(72), Opc:MTS_OPC_LC_INSERTED(1081) 70) Event:ESQ_RSP length:32, at 566635 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x2, Ret:success [E_MTS_RX] Src:MTS_SAP_NTP(72), Opc:MTS_OPC_LC_INSERTED(1081) 71) Event:ESQ_REQ length:32, at 566772 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x3, Ret:success [E_MTS_TX] Dst:MTS_SAP_XBAR_MANAGER(48), Opc:MTS_OPC_LC_INSERTED(1081) 73) Event:ESQ_RSP length:32, at 586418 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x3, Ret:(null) [E_MTS_RX] Src:MTS_SAP_XBAR_MANAGER(48), Opc:MTS_OPC_LC_INSERTED(1081) 74) FSM:<ID(1): Slot 6, node 0x0601> Transition at 586436 usecs after Wed Sep 28 14:44:53 2005 Previous state: [LCM_ST_CHECK_INSERT_SEQUENCE] Triggered event: [LCM_EV_LC_INSERTED_SEQ_FAILED] Next state: [LCM_ST_CHECK_REMOVAL_SEQUENCE] 75) Event:ESQ_START length:32, at 586611 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x2710, Ret:success Seq Type:SERIAL 76) Event:ESQ_REQ length:32, at 593649 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x1, Ret:success [E_MTS_TX] Dst:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_REMOVED(1082) 77) Event:ESQ_RSP length:32, at 594854 usecs after Wed Sep 28 14:44:53 2005 Instance:1, Seq Id:0x1, Ret:success [E_MTS_RX] Src:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_REMOVED(1082) 90) FSM:<ID(1): Slot 6, node 0x0601> Transition at 604447 usecs after Wed Sep 28 14:44:53 2005 Previous state: [LCM_ST_CHECK_REMOVAL_SEQUENCE] Triggered event: [LCM_EV_ALL_LC_REMOVED_RESP_RECEIVED] Next state: [LCM_ST_LC_FAILURE] 91) FSM:<ID(1): Slot 6, node 0x0601> Transition at 604501 usecs after Wed Sep 28 14:44:53 2005 Previous state: [LCM_ST_LC_FAILURE] Triggered event: [LCM_EV_LC_INSERTED_SEQ_FAILED] Next state: [LCM_ST_LC_FAILURE] 92) FSM:<ID(1): Slot 6, node 0x0601> Transition at 604518 usecs after Wed Sep 28 14:44:53 2005 Previous state: [LCM_ST_LC_FAILURE] Triggered event: [LCM_EV_SUPERVISOR_FAILURE] Next state: [LCM_ST_LC_NOT_PRESENT] Curr state: [LCM_ST_LC_NOT_PRESENT] switch#
Die Protokolle oben, Ziffer 92, zeigen an, dass der Supervisor ausgefallen ist und das ausgelöste Ereignis LCM_EV_LC_INSERTED_FF_FAILED ist. (Einfügesequenz fehlgeschlagen). Um herauszufinden, warum die Einfügesequenz fehlgeschlagen ist, sehen Sie in den Protokollen, dass die Einfügesequenz unmittelbar nach einer Antwort von MTS_SAP_XBAR_MANAGER (Index 73 und Index 74) fehlgeschlagen ist. Dies weist darauf hin, dass bei der Xbar-Konfiguration beim Einsetzen des Standby-Supervisors etwas nicht stimmt. Weitere Debugging können durch die internen Protokolle der fehlerhaften Komponente (in diesem Fall der xbar-Komponente) durchgeführt werden.