O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve técnicas de solução de problemas para o hardware do Nexus 7000 (N7K).
Esse comando exibe o status do módulo do ventilador no switch.
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
O status do ventilador pode ser ok, failure ou ausente.
“Fan module removed. Fan module has been absent for 120 seconds"
Esse comando exibe as fontes de alimentação instaladas, o resumo do uso de energia e o status das fontes de alimentação no switch.
O comando e um exemplo de saída são fornecidos.
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
O status da fonte de alimentação pode ser um destes:
Falhas na fonte de alimentação:
Cada fonte de alimentação tem um LED que indica o status da saída de energia. Esse LED é controlado diretamente pela fonte de alimentação e uma cor vermelha indica uma falha na fonte de alimentação. Ao verificar o syslog, você pode mostrar mensagens alternadas sobre falha e recuperação da fonte de alimentação, indicando ainda mais problemas relacionados à fonte de alimentação.
Cada placa no chassi tem pelo menos dois sensores de temperatura. Cada sensor de temperatura é configurado com um limiar menor e um maior. Este comando com saída de exemplo mostra como as informações de temperatura podem ser recuperadas do switch:
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
O sensor de entrada é colocado na entrada de fluxo de ar e é o indicador mais crítico da temperatura da placa. Todas as ações de software são tomadas com base em uma violação de temperatura grave do sensor de entrada.
Isso resulta em uma mensagem de syslog, evento de callhome e uma interceptação SNMP (Simple Network Management Protocol). Essas mensagens de prioridade 1 ou 2 são impressas no syslog - O módulo 1 reportou o alarme de temperatura grave (sensor-index 1 temperature 76).
A placa de linha é desligada instantaneamente com esta mensagem de syslog de prioridade 0 - Módulo 1 desligado devido ao alarme de temperatura principal.
O supervisor redundante está desligado instantaneamente. Isso resultará em um switchover ou no desligamento em standby, dependendo do supervisor específico que violou o limite. Essa mensagem de syslog de prioridade 0 é exibida - Módulo 1 desligado devido ao alarme de temperatura principal.
Às vezes, os sensores de temperatura falham e se tornam inacessíveis. Nenhuma ação explícita de software é tomada para esta condição. Esta mensagem de syslog de prioridade 4 está impressa - O sensor de temperatura do Módulo 1 falhou.
A depuração de uma reinicialização/recarga no nível do switch/supervisor normalmente envolve a busca de informações de depuração/registro armazenadas na memória de acesso aleatório não volátil (NVRAM) nos supervisores. Há 3 tipos de informações de depuração/log presentes na NVRAM que podem conter algumas informações importantes.
1.1 Motivo da redefinição
Os motivos de redefinição são armazenados na NVRAM do supervisor em cada supervisor. Cada Supervisor armazena seu próprio motivo de redefinição. Depois que o switch voltar a funcionar, os motivos de redefinição podem ser despejados usando este comando CLI. Um exemplo de saída é fornecido.
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)
Até os últimos 4 motivos de redefinição são salvos e exibidos. Um motivo de redefinição contém:
Às vezes, um motivo de redefinição de Desconhecido é exibido. Os motivos de redefinição desconhecidos para o software ou fora do controle de software são categorizados como Desconhecido. Eles normalmente incluem:
1.2 Syslog NVRAM
As mensagens de syslog com prioridade 0, 1 e 2 também são registradas na NVRAM do Supervisor. Depois que o switch voltar a ficar on-line, as mensagens de syslog na NVRAM podem ser exibidas usando esse comando. O comando e um exemplo de saída são exibidos:
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
A verificação do syslog da NVRAM pode fornecer mais informações sobre a falha específica que causou a recarga/redefinição do switch/supervisor.
1.3 Registro de exceções do módulo
O registro de exceções do módulo é um registro de enfileiramento de todos os erros e condições excepcionais em cada módulo. Algumas exceções são catastróficas, algumas afetam parcialmente certas portas em um módulo, outras são para fins de aviso. Cada entrada de log tem o dispositivo específico que registrou a exceção, o nível de exceção, o código de erro, as portas afetadas, o carimbo de data e hora. O log de exceções é armazenado na NVRAM no Supervisor e pode ser exibido usando esse comando CLI. Um exemplo de saída é fornecido.
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)
O registro de exceções fornece informações críticas para solucionar erros e condições de exceção. Algumas das IDs do dispositivo estão listadas aqui.
#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
No chassi de Switch de Dados Multicamada (MDS), os módulos supervisores são criados de forma um pouco diferente dos módulos de placa de linha. Quando dois supervisores estão presentes no sistema e o sistema é ligado, um dos supervisores se torna ativo e o outro em espera. A ativação do supervisor ativo e a ativação do supervisor em standby são diferentes e são discutidas aqui.
Se não houver um supervisor ativo no sistema, o supervisor que inicializa assumirá como padrão o supervisor ativo. Um processo chamado gerenciador de sistema é responsável por carregar todos os componentes do software de forma ordenada no supervisor. Um dos primeiros componentes de software executados no supervisor é o gerenciador de plataforma. Este componente carregará todos os drivers e handshakes do kernel com o gerenciador de sistema. Em caso de sucesso, o gerenciador de sistema iniciará o restante dos processos com base na dependência interna entre os processos.
Do ponto de vista do gerenciador de módulos, o Supervisor é como outro módulo de placa de linha com diferenças sutis. Quando o gerenciador de plataforma indica ao gerenciador de módulos que o Supervisor está UP, o gerenciador de módulos não espera pelo registro. Em vez disso, informa todos os componentes de software que o Supervisor está ativo (também conhecido como Sequência de Inserção do Sup). Todos os componentes configurarão o supervisor. Se algum componente retornar com uma falha, o supervisor será reinicializado.
Se houver um supervisor ativo no sistema, o supervisor que está inicializando assumirá como padrão o estado de supervisor em standby. O supervisor em standby precisa espelhar o estado do supervisor ativo. Isso é obtido pelo ‘gerenciador de sistema’ no ativo, iniciando uma sincronização (sincronização global) do estado do supervisor ativo para o supervisor em standby. Quando todos os componentes no modo de espera são sincronizados com o do supervisor ativo, o gerente de módulo é informado de que o supervisor em standby está ativo.
O gerenciador de módulos agora irá em frente e informará todos os componentes de software no supervisor ativo para configurar o supervisor em standby (também conhecido como Sequência de inserção do supervisor em standby). Quaisquer erros de qualquer componente durante a Sequência de Inserção do Standby Sup resultarão na Reinicialização do Supervisor em Standby.
O MDS mantém muitas informações de depuração durante o tempo de execução. Mas, sempre que um supervisor reinicializa, grande parte das informações de depuração é perdida. No entanto, todas as informações críticas são armazenadas na ram não volátil, que pode ser usada para reconstruir a falha. Quando um supervisor ativo é reinicializado, as informações armazenadas em sua nvram não podem ser obtidas até que ela volte a funcionar. Quando o Supervisor voltar, estes comandos podem ser usados para despejar o log persistente:
Switch#show logging nvram
Switch#show system reset-reason
Switch#show module internal exception-log
Exemplo 1: Reinicialização do Sup Ativo (devido a travamento do processo do supervisor)
Neste exemplo, um processo de supervisor travou (Service "xbar"), o que faz com que a sup ativa seja reinicializada. Quando o supervisor volta a funcionar novamente, as informações armazenadas no motivo da redefinição fornecem uma indicação clara para a reinicialização do supervisor.
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)
Se houver um supervisor em standby no sistema, o supervisor em standby agora se tornará supervisor ativo. A exibição das informações do syslog no supervisor em standby também fornecerá as mesmas informações (embora não seja explicitamente como "show system reset-reason").
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).
Exemplo 2: Reinicialização do Sup Ativo (devido a falha de diagnóstico de tempo de execução)
Neste exemplo, o Supervisor no slot 6 está ativo e o intermediário no Supervisor relata um erro fatal. Quando qualquer dispositivo de hardware relata um erro fatal, o módulo que contém o dispositivo é reinicializado. Nesse caso, o Supervisor ativo é reinicializado. Se houver um supervisor em standby, o supervisor em standby assumirá o controle. As mensagens de syslog no supervisor em standby e no log de exceções terão informações para identificar a origem do erro.
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
Além disso, quando o sup reinicializado ficar online novamente, "show system reset-reason" conterá também informações relevantes. Nesse caso, o módulo 6 (que era o sup ativo) foi reinicializado pelo Sap 48 com o código de erro 0x80000020. O processo proprietário desse sap pode ser obtido pelo comando "show system internal mts sup sap 48 description", que diz que o processo foi xbar-manager.
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)
Exemplo 3: Falha no modo de espera do Sup
Neste exemplo, a sup ativa está ativa e em execução e a sup de standby está conectada ao sistema. No entanto, show module não indica que o módulo já foi ativado.
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
No entanto, se você fizer login no console da sup de standby, ela indicará que está em standby.
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)#
Conforme discutido anteriormente, quando a sup de standby é inserida no sistema, a configuração e o estado de todos os componentes do supervisor ativo são copiados para o modo de espera (gsync). Até que esse processo esteja concluído, o supervisor ativo não considera a presença de um supervisor em standby. Para verificar se esse processo está concluído, você pode emitir o seguinte comando no supervisor ativo. A saída do comando indica que a sincronização está em andamento (e provavelmente nunca foi concluída).
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
O motivo mais provável para isso ter acontecido é, se um dos componentes do software no standby não tiver sincronizado seu estado com o supervisor ativo. Para verificar quais processos não foram sincronizados, você pode emitir esse comando no supervisor ativo e a saída indica que muitos componentes de software não completaram a sincronização.
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
Além disso, olhando para o supervisor em standby, vemos que o componente de software xbar foi reiniciado 23 vezes. Esta parece ser a causa mais provável de o modo de espera não ter surgido.
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
Exemplo 3: O Sup em standby está no estado ativado
Neste exemplo, o submenu de standby é inserido no slot 6. comando show module emitido no ative-sup, mostra que o Standby Sup está no estado ligado.
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
Neste exemplo, show logging não fornece nenhuma informação valiosa e também não mostra o registro de exceção interno do módulo. No entanto, como todas as transições de estado para um determinado módulo são armazenadas no gerenciador de módulos, podemos examinar as transições de estado do gerenciador de módulos para descobrir o que está errado. As transições internas de estado são:
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#
Examine os registros acima do Índice 92, indica que o supervisor está em estado de falha e que o evento disparado é LCM_EV_LC_INSERTED_SEQ_FAILED. (Falha na sequência de inserção). Ao acessar os registros para descobrir por que a Sequência de Inserção falhou, veja que a sequência de inserção falhou logo após uma resposta do MTS_SAP_XBAR_MANAGER (Índice 73 e Índice 74). Isso indica que há algo errado com a configuração xbar quando a sup de standby é inserida. Mais depuração pode ser feita observando-se os registros internos do componente com falha (nesse caso, componente xbar).