Resolución de problemas de recargas 3650/3850 por parte del administrador de pila a través de un informe del sistema
Contenido
Introducción
La resolución de problemas de recargas de pilas a través de un informe del sistema en ausencia de un desperfecto se realiza normalmente en las plataformas de switching NGWC mediante la tecnología de apilamiento. La documentación actual se limita a los usos de un informe del sistema y esta guía se está redactando para explicar cómo puede aprovechar estos informes para diagnosticar los problemas que se suelen encontrar con los problemas de apilamiento. Esta guía está especialmente orientada a las arquitecturas de switching Catalyst 3650/3850 que ejecutan IOS-XE y admiten capacidades de apilamiento.
La mayoría de los problemas con la tecnología de apilamiento se deben a un problema de comunicación entre los miembros de una pila. Cualquier inconsistencia en la información entre los miembros o la pérdida de conectividad puede dar lugar a un problema que se extiende por toda la pila, lo que finalmente conduce a un reinicio con el administrador de la pila. Este documento resaltará algunos de los tipos comunes de fallas observados con las recargas del administrador de pila, el uso de un informe del sistema y las CLI relevantes disponibles para diagnosticar y diferentes tipos de problemas.
Información general:
Informe del sistema frente a informes de switch
Un informe del sistema es un informe completo del miembro sobre cómo percibe el estado de la pila. Esto no es un crashinfo (que vaciará la memoria para la depuración adicional), sino un informe que tiene registros e información de depuración para varios servicios que se ejecutan en IOS-XE que sería útil para el desarrollo para realizar un seguimiento del estado de ese servicio. Se puede generar un informe del sistema cuando el administrador de la pila vuelve a cargar el switch, se ha producido una caída del proceso o el usuario lo ha generado manualmente durante la operación en directo.
En muchos casos, hay situaciones en las que un solo switch puede fallar en una pila, pero el resto de los miembros pueden permanecer intactos. Para recopilar información sobre el estado de la pila en el momento dado, se introdujeron los informes_switch para que los miembros restantes generen uno cuando detecte que un miembro se ha caído. El informe_switch será un informe local de cómo ese miembro percibe el estado actual de la pila.
Dónde recopilar informes del sistema/switch
Los informes del sistema se escribirán normalmente en crashinfo: del miembro de esa pila. Por ejemplo, si hay una pila de switch de x-miembros, cada switch tendrá su propio directorio crashinfo al que se puede acceder usando "dir crashinfo-x" donde "x" corresponde a ese miembro dentro de la pila.
3850#dir crashinfo-1:
Directorio de crashinfo:/
11 -rwx 355 Ago 14 2015 07:48:17 -04:00 last_systemreport_log
12 -rwx 724015 Oct 15 2014 07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz
3850#dir crashinfo-2:
Directorio de crashinfo-2:/
11 -rwx 357 Ago 14 2015 07:50:49 -04:00 last_systemreport_log
12 -rwx 751340 Oct 15 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz
secciones interesantes en el informe del sistema
Desde el punto de vista del TAC, estas son algunas de las entradas más vistas dentro del informe del sistema que pueden ayudar a diagnosticar eventos de un problema específico. Existen otros registros de otros servicios incluidos aquí que el desarrollo puede encontrar que desea revisar.
archivo de registro:/mnt/pss/sup_sysmgr_reset.log
Este es un resultado corto para comprender de manera muy genérica por qué se vio un reinicio. Consulte la siguiente sección sobre tipos de fallos para ver el significado y el contexto en el que variarán estas razones.
archivo de registro:IOS
Este es el buffer de registro mantenido dentro del IOSd. En esta sección se encontrarán todos los comandos que haya ejecutado el usuario o los syslogs generados dentro de IOSd. Los registros más recientes están al final de este resultado.
Búfer de seguimiento: stack-mgr-events
Hace un seguimiento de los eventos observados desde el administrador de la pila, que incluirán cuándo otros miembros se unen o se eliminan de la pila o qué puerto de la pila atraviesan los mensajes.
Búfer de seguimiento: redundancy-timer-ha_mgr
Muestra los eventos de mantener activos entre los switches de la pila. Los sellos de tiempo pueden ayudar a determinar cuándo se inició la interrupción en la comunicación.
Tipos de fallas
En esta sección se resaltarán algunos restablecimientos habituales de un informe del sistema que suelen invocar los procesos del administrador de la pila. Stack Manager es un proceso linux que administra los miembros de la pila y supervisará cualquier cambio en las funciones entre los switches de la pila. Si el administrador de la pila detecta un problema durante la inicialización o la elección de la función, enviará una señal de recarga a los switches individuales para que la pila se reinicie. A continuación también se enumeran los errores conocidos que se han asociado al tipo de falla respectivo.
Nota: No todas las recargas del administrador de pila se atribuyen a un problema de software. De hecho, es más común ver estos problemas como un problema secundario/víctima de un problema de hardware subyacente.
Razón del restablecimiento:Restablecer/Recargar solicitado por [stack-manager]. [Incompatibilidad de ISSU]
Puede que vea este tipo de reinicio cuando hay una falla de sincronización masiva mientras intenta sincronizar la configuración en el activo entre todos los miembros de la pila. Comprobando el archivo de registro: IOS o los registros del switch activo podrían resaltar las configuraciones que contribuyeron a este reinicio.
Razón del restablecimiento:Servicio [iosd] pid:[xyz] finalizado anormalmente [11].
Esto se ve cuando el switch falla en el proceso IOSd. Mirando los directorios crashinfo para cualquier archivo crashinfo + vaciados de memoria se puede utilizar para depurar esta falla aún más.
ap_sup_reset: Razón del restablecimiento:Restablecer/Recargar solicitado por [stack-manager]. [stack merge]
Se ve una combinación de pila cuando hay dos o más switches que creen que son el switch activo de la pila. Esto se puede ver cuando hay una interrupción en el anillo de una pila (es decir, dos cables están desconectados de la pila) de modo que tanto el activo como el en espera pierden la comunicación con los otros miembros. La incorporación de un switch ya alimentado a una pila existente puede provocar una combinación de pilas, ya que habrá dos switches activos en la pila.
CSCuh58098 
- La pila 3850 se puede recargar cuando hay problemas de cableado de la pila
CSCui56058 - Habilitación de la lógica de eliminación de rebote para el cable de pila
CSCup53338 - 3850 caída de IOSD | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
ap_sup_reset: Código de motivo:[4] Razón del restablecimiento:Restablecimiento/recarga solicitada por [stack-manager]. [combinación de pila debido a incompatibilidad]
Esto se ha visto en situaciones en las que existe un switch activo y en espera en la pila. Si el switch activo pierde la comunicación con el standby, el standby intentará tomar el control como el activo aunque el activo aún esté activo.
CSCuo49555 /CSCup58016 - 3850/3650 se bloquea debido a la inundación unicast en el puerto mgmt
CSCur07909 - Combinación de la pila debido a la pérdida de conectividad activa y en espera
Razón del restablecimiento:Restablecer/Recargar solicitado por [stack-manager]. [Se encontró un vecino incorrecto después de la votación ASIC]
Los switches participan en una cédula ASIC durante el arranque para determinar sus switches vecinos dentro de la pila. Este reinicio se puede ver cuando un temporizador caduca para que un vecino se declare a sí mismo o si hay un error lógico durante la conversación nbrcast. Esto se ha visto en el contexto de cables de pila defectuosos que se han resuelto mediante la sustitución.
CSCun60777 - El switch se recargó debido a un vecino incorrecto encontrado después de la votación ASIC
CSCud93761 - El switch se recargó debido a un vecino incorrecto encontrado después de la votación ASIC
ap_sup_reset: Código de motivo:[4] Razón del restablecimiento:Restablecimiento/recarga solicitada por [stack-manager]. [perdió tanto activo como en espera]
Esto se ve normalmente desde un miembro de la pila que no está en una función activa o en espera. Cuando el activo falla, si no hay ningún switch en espera para asumir el rol activo para la pila, entonces la pila completa se reiniciará. Si la pila es un estado inestable o la política de redundancia aún no se ha sincronizado, esto puede verse. Esto es probablemente una víctima del por qué los switches activo/en espera se desactivaron o posiblemente una indicación de que la redundancia no se está sincronizando correctamente. Esto también se puede ver cuando las pilas se configuran en una configuración de medio anillo.
CSCup53882 - Switches miembro en un reinicio de pila 3850 - [perdió tanto activo como en espera]
ap_sup_reset: Código de motivo:[1] Razón del restablecimiento:Restablecimiento/recarga solicitada por [stack-manager]. [Keepalive_Timeout]
Se ve cuando no se reciben mensajes de "Mantener activo" del switch en la pila. Examinando "Trace Buffer: redundancy-timer-ha_mgr" debe mostrar el intercambio de mensajes de mantenimiento activo y proporcionar una perspectiva del momento en que se inició la interrupción de la comunicación. La recopilación de informes de switches del resto de la pila y el examen de los registros durante el período de tiempo pueden ser de ayuda aquí.
ap_sup_reset: Razón del restablecimiento:Restablecer/Recargar solicitado por [stack-manager]. [Recargar comando]
Esta es una razón de reinicio bastante intuitiva; esto se ve cuando el administrador de pila recibe una solicitud de recarga que se puede invocar a través de CLI o externamente a través del dispositivo de administración (SNMP). En casos de CSCuj17317 , esto también aparecerá como un ‘comando reload’ ejecutado. Desde el archivo de registro: IOS 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
Errores relevantes
CSCur76872 - Stack Manager se desactiva cuando el sistema se queda sin el búfer SDP.
CSCup49704 - 3850 FED Crash - Esperando canales SPI FED_SPI_FLCD,FED_SPI_FAST ...
Diagnóstico de un posible problema de puerto/cableado de pila
Síntoma 1) Cualquier signo de un problema de cableado de pila será evidente por cualquier inestabilidad del puerto de pila antes del reinicio. Mirando al "archivo de registro: El informe IOS" antes de un reinicio es generalmente un buen lugar para comenzar. A continuación se muestra un ejemplo de dónde se ve la inestabilidad del puerto de pila registrado tanto en el SW2 actual como en el SW1 en espera. Este mismo puerto de pila estaba inestable en cada instancia del reinicio y se resolvió reemplazando el cable de pila:
===================== 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
Síntoma 2) Según la configuración en el sentido de la pila (180, 480, más), el número de anillos de transmisión por puerto ASIC variará. Estos comandos sondearán los registros globales que mantienen un total en ejecución de cuántos errores de lectura se ven para cada anillo de transmisión. "Port-ASIC 0" corresponde al puerto de pila 1 y "port-ASIC 1" al puerto de pila 2. Esto se debe emitir para cada switch y cualquier señal de aumento de recuentos puede aislar si hay un problema en el puerto o con el cable de pila.
Estos se pueden recopilar varias veces en unos minutos para comparar los deltas del conteo:
show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>
- Error de segmento con CRC de datos
show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>
- Incrementado en cualquier verificación CRC fallida
show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>
- Incrementado en código PCS no válido, palabra de código PCS desconocida, se ha detectado un error de disparidad
show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>
- Error de bit en la pila causado error CRC de palabra de llamada
Para Polaris (código 16.X), los comandos son los siguientes:
show plat hardware fed sw <#/active/standby> fwd-asic register read register name SifRacDataCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register name SifRacRwCrcErrorCnt asic<0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register name SifRacPcsCodeWordErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register name SifRacInvalidRingWordCnt asic <0-1>
A continuación se muestra un ejemplo en el que se ha visto un evento de combinación de pila en ambos miembros de una pila de 2 miembros sin signos de un puerto de pila inestable. Se ve que el anillo[0] aumenta con los CRC en el puerto de pila 1 del switch 1 y terminó reemplazando el cable de pila para superar 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 que se esté examinando, la máscara puede ser diferente en cada caso. En el ejemplo anterior, la máscara se envolverá en los últimos 14 bits. Por lo tanto, cuando el contador alcance 0x00003FFF, se volverá a envolver a 0x00000000.
Sugerencias adicionales
1. Archivando directorios Crashinfo
Más switches en la pila significa que se recopilarán más archivos de informes. Es fácil sentirse abrumado por el número de informes que se generan. La organización es vital para aislar un fracaso. Busque una consistencia usando sellos de tiempo de cuando cada switch escribió el archivo de informe para un incidente determinado si es posible. A partir de ahí, pida esos informes muy específicos de esos switches para que el cliente no cargue varios archivos. El directorio crashinfo también se puede archivar para que el cliente pueda enviar un único archivo que contenga los informes interesados. A continuación se crea un archivo denominado 'crashinfo-archive.tar' en el directorio 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 una pila inestable
Puede haber algunas situaciones en las que vea varios miembros en una pila recargando durante el arranque después de que se lleve a cabo el proceso de elección de la pila. Si un switch recargado se cree que es el activo, a menudo esto puede conducir a un evento de fusión de pila y entrará en un estado de loop de inicio. En esta situación, puede ser aconsejable preguntar al cliente:
- Apague toda la pila y vuelva a colocar todos los cables de la pila firmemente.
- Encienda cada switch miembro de la pila uno por uno hasta que todos los miembros hayan convergido a su estado esperado.
- En los casos en los que un miembro no se une a la pila, quite esto de la pila e intente arrancar este individuo como independiente para resolver problemas adicionales.
3. Generar informes del sistema manualmente
La creación manual de informes del sistema requiere que se habilite el "servicio interno". Esto escribirá un informe del sistema como un archivo de texto que se puede realizar por 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>
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)