Resolviendo problemas 3650/3850 de las recargas del administrador del stack a través de un sistema señale

 

Introducción

Resolver problemas las recargas del stack con un informe del sistema en ausencia de una caída se hace comúnmente en las Plataformas de la transferencia NGWC usando la tecnología del stackwise. La documentación actual se limita en las aplicaciones de un informe del sistema y están escribiendo esta guía para explicar cómo usted puede leverage estos informes para diagnosticar los problemas encontrados típicamente con empilar los problemas. Esta guía se adapta determinado para las arquitecturas que conmutan del Catalyst 3650/3850 que ejecutan IOS-XE que soporte empilar las capacidades.

La mayoría de los problemas con la tecnología del stackwise proviene un problema de comunicación entre los miembros dentro de un stack. Cualquier inconsistencia de la información entre los miembros o la pérdida de conectividad puede dar lugar a un problema que impregne a través del stack entero que lleva en última instancia a una restauración con el administrador del stack. Este documento resaltará algunos de los tipos comunes de errores considerados con las recargas del stack-administrador, las aplicaciones de un informe del sistema, y los CLI relevantes disponibles de diagnosticar y diversos tipos de problema.

Información previa:

Informe del sistema contra los informes del Switch

Un sistema-informe es un informe completo del miembro de cómo percibe el estado del stack. Éste no es un RMtermcode = 3 nfw (que vaciará hacia fuera la memoria para el debugging adicional), sino que por el contrario, es un informe que tiene los registros y información de debugging para los diversos servicios que se ejecutan bajo IOS-XE que sería útil para que el desarrollo siga el estado de ese servicio. Un sistema-informe se puede generar cuando el Switch es recargado por el administrador del stack, una caída de proceso ha ocurrido, o generado manualmente por el usuario durante la operación viva.

 

En muchos casos, hay las situaciones en las cuales un un solo switch pudo fallar en un stack pero el resto de los miembros puede permanecer intacto. Para recolectar como información sobre el estado del stack en el cualquier momento, los switch_reports fueron introducidos de modo que los miembros restantes generen uno cuando detecta que ha ido un miembro abajo. El switch_report será un informe local de cómo ese miembro percibe al estado actual del stack.

 

Nota: Se escriben y se comprimen estos informes así que no pueden ser impresos a la terminal usando “más”. Necesitarán ser transferidos del Switch y ser descomprimidos para ver el registro.

 

Donde recolectar los informes del sistema/del Switch

Los informes del sistema serán escritos típicamente en el RMtermcode = 3 nfw: directorio del miembro en ese stack. Por ejemplo, si hay un stack del Switch del x-miembro, después cada Switch tendrá su propio directorio del RMtermcode = 3 nfw que pueda ser accesible usando el “RMtermcode = 3 nfw-x del dir” donde “x” corresponde a ese miembro dentro del stack.

 

3850#dir crashinfo-1:

Directorio del RMtermcode = 3 nfw: /    

11 - last_systemreport_log del rwx 355 14 de agosto de 2015 07:48:17 -04:00  

12 - rwx 724015 15 de octubre de 2014 07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz

 

3850#dir crashinfo-2:

Directorio de crashinfo-2:/   

11 - last_systemreport_log del rwx 357 14 de agosto de 2015 07:50:49 -04:00  

12 - rwx 751340 15 de octubre de 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz

 

Nota: Esté seguro de recolectar la salida para el “RMtermcode = 3 nfw-x del dir: ” para cada Switch en ese stack porque “la tecnología de la demostración” no enumerará hacia fuera los sistemas de archivos disponibles o los archivos CRASHINFO. Es importante que usted tiene la imagen entera de cada miembro en ese stack. Actualización: A partir de más nuevas versiones >3.6E IOS-XE, la tecnología de la demostración reflejará el '' RMtermcode = 3 nfw del dir: '+ salida del “show file systems”. Vea CSCun50428 .

 

Secciones interesantes en el informe del sistema

De una perspectiva de TAC, éstos son algunas de las entradas generalmente vistas dentro del informe del sistema que puede ayudar a diagnosticar los eventos de un problema específico. Hay otros registros de los otros servicios contenidos en aquí que el desarrollo puede encontrar para querer revisar.

 

archivo del registro: /mnt/pss/sup_sysmgr_reset.log

Esto es una salida corta a muy genéricamente entiende porqué una restauración fue considerada. Vea los tipos abajo de sección de los errores para mirar el significado y el contexto en cómo estas razones variarán.

 

archivo del registro: IOS

Éste es el búfer del registro mantenido dentro de IOSd. Encontrarán a los comandos any que fueron publicados por el usuario o los Syslog generados dentro de IOSd en esta sección. La mayoría de los registros recientes están hacia el extremo de esta salida.

 

Búfer de traza: stack-mgr-eventos

No pierde de vista los eventos vistos del administrador del stack de que incluirán cuando otros miembros son el unirse a/quitados del stack o a través de quien el puerto de pila los mensajes viene adentro.

               

Búfer de traza: redundancy-timer-ha_mgr

Visualiza los eventos de la señal de mantenimiento entre el Switches en el stack. Los grupos fecha/hora pueden ayudar a determinar cuando la interrupción en la comunicación comenzó.

 

Tipos de errores

Esta sección resaltará alguno comúnmente - las restauraciones consideradas de un informe del sistema que son invocadas típicamente por el proceso de administrador del stack. El administrador del stack es un proceso del linux que maneja a los miembros en el stack y supervisará cualquier cambio en los papeles entre el Switches en el stack. Si el administrador del stack detecta un problema durante la elección de la inicialización o del papel, enviará una señal de la recarga al Switches individual para que el stack reajuste. Debajo de la voluntad también enumere los bug conocido que se han asociado al tipo de falla respectivo.

 

Nota: No todas las recargas del stack-administrador se atribuyen a un problema del software. De hecho, es más común ver estos problemas evidentes como problema secundario/de la víctima a un problema de hardware subyacente.

 

Motivo de restauración: Reajuste/recarga pedida por el [stack-manager]. [ISSU Incompatibility]

Usted puede ser que vea este tipo de restauración cuando hay una falla de la sincronización a granel mientras que intenta sincronizar la configuración en el master entre todos los miembros en el stack. Marcar el fichero de diario: El IOS o el registros del Switch activo pudo resaltar las configuraciones que contribuyeron a esta restauración.

Motivo de restauración: Mantenga el pid del [iosd]: [xyz] terminado anormalmente [11].

Esto vista cuando el Switch causa un crash en el proceso de IOSd. La mirada de los directorios del RMtermcode = 3 nfw para cualesquiera archivos CRASHINFO + vaciado de memoria se puede utilizar para hacer el debug de este error más lejos.

 

hap_sup_reset: Motivo de restauración: Reajuste/recarga pedida por el [stack-manager]. [stack merge]

Se considera una fusión del stack cuando hay dos o más Switches que lo crea es el master del stack. Esto se puede ver cuando allí es una rotura en el timbre de un stack (es decir dos cables son disconnected del stack) así que el activo y el espera pierde la comunicación a los otros miembros. La adición de un interruptor ya a un stack existente puede causar una fusión del stack pues habrá dos Switches activo en el stack.

 

CSCuh58098 - 3850 stack pueden recargar cuando las cuestiones del cableado del stack están presentes

CSCui56058 - Habilitar la lógica del debounce para el cable del stack

CSCup53338 - caída 3850 IOSD | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

 

hap_sup_reset: Motivo de restauración de la razón Code:[4]: Restauración/Reloadrequested por el [stack-manager]. [stack merge due to incompatibility]

Esto se ha visto en las situaciones cuando un Switch activo y espera existe en el stack. Si el Switch activo pierde la comunicación al recurso seguro, el recurso seguro intentará asumir el control como el active aunque el active todavía está para arriba.

 

CSCuo49555 /CSCup58016 - 3850/3650 de las caídas debido a la inundación del unicast en el mgmt vira hacia el lado de babor

CSCur07909 - Empile la fusión debido al active y a la Conectividad perdida espera

 

 

Motivo de restauración: Reajuste/recarga pedida por el [stack-manager]. [Wrong neighbor encountered after ASIC ballot]

El Switches participa en una votación ASIC durante el inicio hasta determina sus switches de vecindad dentro del stack. Esta restauración puede ser considerada cuando un temporizador expira para que un vecino se declare o si hay un error lógico durante la conversación del nbrcast. Esto se ha visto en el contexto de los cables defectuosos del stack que se han resuelto a través del reemplazo.

 

CSCun60777 - Debido recargada Switch perjudicar al vecino encontrado después de la votación de ASIC

CSCud93761 - Debido recargada Switch perjudicar al vecino encontrado después de la votación de ASIC

 

 

 

hap_sup_reset: Motivo de restauración de la razón Code:[4]: Reajuste/recarga pedida por el [stack-manager]. [lost both active and standby]

Esto se ve típicamente de un miembro en el stack que no es en un active o rol en espera. Cuando el active falla, si no hay Switch espera para asumir rol activo para el stack, después el stack entero reajustará. Si el stack es un estado inestable o directiva de la Redundancia no ha sincronizado todavía, esto puede ser vista. Esto es probable una víctima del porqué fue el Switches activo/espera abajo o potencialmente una indicación que la Redundancia no está sincronizando correctamente. Esto puede también ser vista en cuando los stack se configuran en una configuración del mitad-timbre.

 

CSCup53882 - Switches miembros en una reinicialización de 3850 stack - [lost both active and standby]

 

hap_sup_reset: Motivo de restauración de la razón Code:[1]: Reajuste/recarga pedida por el [stack-manager]. [Keepalive_Timeout]

Visto cuando los mensajes de la señal de mantenimiento no se reciben del Switch en el stack. Mirada del “búfer de traza: el redundancy-timer-ha_mgr” debe mostrar el intercambio de los mensajes de la señal de mantenimiento y proporcionar una perspectiva de la hora para cuando la interrupción en la comunicación comenzó. La acopio de los informes del Switch del resto del stack y la mirada de los registros durante el tiempo de trama pueden ayudar aquí.

 

 

hap_sup_reset: Motivo de restauración: Reajuste/recarga pedida por el [stack-manager]. [Reload command]

Esto es un motivo de restauración bastante intuitivo – se ve esto cuando el stack-administrador recibe una petición de la recarga que se podría invocar con el CLI o externamente vía el (SNMP) del dispositivo de administración. En casos de CSCuj17317 , esto también aparecerá como un “comando reload” publicó también. Del archivo del registro: IOS que usted puede ver:

 

CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr:  Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr:  Reloading due to reason Reload command

 

Bug relevantes

CSCur76872 - El administrador del stack va abajo de cuando el sistema se ejecuta del buffer SDP.

CSCup49704 - caída de 3850 FED - para SPI que espera canaliza FED_SPI_FLCD, FED_SPI_FAST…

 

 

 

Diagnóstico de un problema potencial del /port del cableado del stack

El síntoma 1) cualquier muestra de una cuestión del cableado del stack será evidente por cualquier cambio del puerto de pila antes de la restauración. Mirada del “fichero de diario: Informe IOS el” antes de una restauración es típicamente un lugar bueno a comenzar. Aquí está un ejemplo de donde usted ve el cambio del puerto de pila que se registra en el SW2 actual y el SW1 espera. Este mismo puerto de pila agitaba cada uno en cada caso de la restauración y fue resuelto substituyendo el cable del stack:

 

=====================  log file: IOS  =====================
.
.
Aug  8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is down  (SW1-1)
Aug  8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is up  (SW1-1)
Aug  8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr:  Switch 1 has been removed from the stack.
Aug  8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1

 

El síntoma 2) dependiendo de la configuración del stackwise se utiliza (180, 480, más), el número de timbres de la transmisión por el puerto ASIC variará. Estos comandos sondearán los registros globales que mantienen un total de conexiones de cuántos errores de lectura se consideran para cada timbre de la transmisión. “Puerto-ASIC 0" corresponde al puerto de pila 1 y “puerto-ASIC 1" corresponde al puerto de pila 2. Esto se debe publicar para cada Switch y cualquier muestra de incrementar las cuentas puede aislar si allí quizá un problema en el puerto o con el cable del stack.

 

 

 

 

Éstos se pueden recoger varias veces durante algunos minutos de comparar los deltas en la cuenta:

 

muestre el <switch#> leído <0-1> del Switch de SifRacDataCrcErrorCnt del registro de puerto-ASIC de la plataforma

• Segmento con los datos error crc

muestre el <switch#> leído <0-1> del Switch de SifRacRwCrcErrorCnt del registro de puerto-ASIC de la plataforma

• Incrementado en cualquier control fallado CRC

muestre el <switch#> leído <0-1> del Switch de SifRacPcsCodeWordErrorCnt del registro de puerto-ASIC de la plataforma

• Incrementado en el código inválido PCS, se detecta el codeword desconocido PCS, error corriente de la disparidad

muestre el <switch#> leído <0-1> del Switch de SifRacInvalidRingWordCnt del registro de puerto-ASIC de la plataforma

• Error de bit en el ringword causado stack error crc

 

 

Lo que sigue es un ejemplo donde usted tenía un evento de la fusión del stack visto ambos miembros de un stack 2-member sin ningunas muestras de un puerto de pila del cambio. Usted ve ring[0] el incrementar con los CRC en el stack port-1 del Switch 1 y terminado encima de substituir el cable del stack para conseguir más allá de este problema.

 

3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015
 
For asic 0
 
SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x00000031 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001
                               
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015
 
For asic 0
 
SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x000000c9 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001

 

Nota: Dependiendo del registro el cual se está mirando, la máscara quizá diferente en cada caso. En el ejemplo antedicho, la máscara envolverá alrededor en los bits del último 14. Así, cuando el contador alcanza 0x00003FFF, envolverá de nuevo a 0x00000000.

 

Extremidades adicionales

1. Archivar los directorios del RMtermcode = 3 nfw

Más Switches en el stack significa que habrá más archivos de informe que se recogerán. Es fácil conseguir abrumado por el número de informes se generen que. La organización es vital a aislar un error. Encuentre un estado coherente usando los grupos fecha/hora de cuando cada Switch escribió el archivo de informe para un incidente dado si es posible. De allí, pida esos informes muy específicos de eso Switches dado así que el cliente no carga varios archivos. El directorio del RMtermcode = 3 nfw puede también ser archivado así que el cliente puede enviar un solo archivo que contiene los informes interesados. Lo que sigue creará un archivo nombrado “crashinfo-archive.tar” en el directorio de Flash:

 

F340.03.10-3800-1#archive tar /create ?
 WORD Tar filename

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
 WORD Dir to archive files from

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
 WORD File or Dir
 <cr>

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:

 

 

2. Recuperación de un stack inestable

Puede haber algunas situaciones donde usted ve a varios miembros en un stack que recargan durante el inicio para arriba después de que ocurra el proceso de elección del stack. Si un Switch recargado se cree para ser el master del stack entonces éste puede llevar a menudo a un evento de la fusión del stack y ingresará en un estado del loop del inicio. En esta situación, puede ser recomendable preguntar al cliente:

- Accione abajo el stack entero y vuelva a sentar todos los cables del stack firmemente.

- El encendido cada switch miembro en el stack uno por uno hasta todos los miembros ha convergido a su estado previsto.

- En caso de que un miembro no puede unirse al stack, quitar esto del stack e intentar iniciar a este individuo como independiente para resolver problemas más lejos.

 

3. Genere los informes del sistema manualmente

Manualmente crear los informes del sistema requiere el “servicio interno” ser habilitada. Esto escribirá un informe del sistema como archivo de texto que se pueda hacer por la base del Switch.

 

 

3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit

3800-1#resource create_system_report ?
 WORD system report filename

3800-1#resource create_system_report sysreport.txt ?
 switch Switch number
 <cr>

3800-1#resource create_system_report sysreport.txt switch ?
 <1-1> Switch number

3800-1#resource create_system_report sysreport.txt switch 1 ?
 <cr>