Solución de problemas de recargas de Stack Manager 3650/3850

Introducción

Este documento describe cómo aprovechar los informes del sistema para diagnosticar problemas de pila.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Si resuelve problemas de recargas de pila a través de un informe del sistema en ausencia de un desperfecto se hace comúnmente en las plataformas de switching NGWC que utiliza la tecnología stackwise. La documentación actual se limita a los usos de un informe del sistema y esta guía explica cómo puede aprovechar estos informes para diagnosticar problemas que se suelen encontrar con los problemas de apilamiento. Esta guía se centra especialmente en las arquitecturas de switches Catalyst 3650/3850 que ejecutan Cisco IOS® XE con capacidades de apilamiento compatibles.

La mayoría de los problemas con la tecnología stackwise provienen de un problema de comunicación entre los miembros dentro de una pila. Cualquier incoherencia de la información entre los miembros o pérdida de conectividad puede dar lugar a un problema que penetra en toda la pila y, en última instancia, conduce a un restablecimiento con el administrador de la pila. Este documento puede resaltar algunos de los tipos comunes de fallas que se observan con las recargas del administrador de la pila, los usos de un informe del sistema y las CLI relevantes disponibles para diagnosticar y los diferentes tipos de problemas.

Informes del sistema frente a informes del switch

Un informe del sistema es un informe completo del miembro a partir de cómo percibe el estado de la pila. Esto no es crashinfo (que puede vaciar memoria para depurarla), sino un informe que tiene registros e información de depuración para varios servicios que se ejecutan bajo Cisco IOS XE que sería útil para el desarrollo para rastrear el estado de ese servicio. Se puede generar un informe del sistema cuando el administrador de la pila recarga el switch, se ha producido una caída del proceso o el usuario lo ha generado manualmente durante el funcionamiento en tiempo real.

En muchos casos, hay situaciones en las que un solo switch puede fallar en una pila, pero el resto de los miembros puede permanecer intacto. Para recopilar información sobre el estado de la pila en un momento dado, se introdujeron switch_reports de modo que los miembros actuales puedan generar uno cuando detecten que un miembro ha caído. El switch_report puede ser un informe local de cómo percibe ese miembro el estado actual de la pila.

Nota: Estos informes se escriben y se comprimen para que no se puedan imprimir en el terminal con más. Es posible que deban transferirse fuera del switch y descomprimirse para ver el registro.

Dónde recopilar informes del sistema/switch

Los informes del sistema se pueden escribir normalmente en el directorio crashinfo: del miembro en esa pila. Por ejemplo, si hay una pila de switches de miembro x, cada switch puede tener su propio directorio crashinfo al que se puede acceder con dir crashinfo-x, donde x corresponde a ese miembro dentro de la pila.

3850#dir crashinfo-1:

Directorio de crashinfo:/    

11 -rwx 355 Aug 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 Aug 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

Nota: Asegúrese de recopilar la salida para dir crashinfo-x para cada switch en esa pila porque show tech no puede enumerar los sistemas de archivos disponibles o los archivos crashinfo. Es importante que tenga la imagen completa de todos y cada uno de los miembros de la pila. Actualización: a partir de las versiones más recientes de Cisco IOS XE >3.6E, el comando show tech puede reflejar la salida de dir crashinfo: + show file systems. Consulte Cisco bug ID CSCun50428.

Secciones destacables del informe del sistema

Desde el punto de vista del TAC, estas son algunas de las entradas más vistas del informe del sistema que pueden ayudar a diagnosticar eventos de un problema específico. Hay otros registros de otros servicios contenidos aquí que el desarrollo puede encontrar que desea revisar.

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

Este es un resultado corto para entender muy genéricamente por qué se vio un reinicio. Consulte la sección sobre los siguientes tipos de fallos para ver el significado y el contexto de cómo pueden variar estos motivos.

archivo de registro: Cisco IOS

Este es el buffer de registro mantenido desde Cisco IOSd. En esta sección se puede encontrar cualquier comando emitido por el usuario o los registros del sistema generados dentro de Cisco IOSd. Los registros más recientes se encuentran hacia el final de este resultado.

Búfer de seguimiento: stack-mgr-events

Realiza un seguimiento de los eventos vistos desde el gestor de pilas, que pueden incluir cuándo otros miembros se están uniendo o quitando de la pila o a qué puerto de pila acceden los mensajes.

               

Búfer de seguimiento: redundancy-timer-ha_mgr

Muestra los eventos de activación entre los switches de la pila. Las marcas de tiempo pueden ayudar a determinar cuándo comenzó el problema de comunicación.

Tipos de errores

Esta sección puede resaltar algunos reinicios vistos comúnmente desde un informe del sistema que son invocados típicamente por el proceso del administrador de la pila. El gestor de pilas es un proceso de Linux que gestiona los miembros de la pila y puede 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, puede enviar una señal de recarga a los switches individuales para que la pila se reinicie. La siguiente lista también puede enumerar los errores conocidos que se han asociado al tipo de error respectivo.

Razón del restablecimiento: [stack-manager] solicitó el restablecimiento o la recarga. [Incompatibilidad de ISSU]

Puede ver este tipo de restablecimiento cuando hay un error de sincronización masiva cuando intenta sincronizar la configuración en el activo entre todos los miembros de la pila. Verifique el archivo de registro: Cisco IOS o los registros del switch activo pueden resaltar las configuraciones que contribuyeron a este restablecimiento.

Razón de restablecimiento: el servicio [iosd] pid:[xyz] finalizó de forma anómala [11].

Esto se ve cuando el switch falla en el proceso Cisco IOSd. Observe los directorios crashinfo para ver si se pueden utilizar los archivos crashinfo + vaciados de memoria para depurar aún más esta falla.

hap_sup_reset: Razón del restablecimiento: restablecimiento/recarga solicitada por [stack-manager]. [stack merge]

Una combinación de pila se observa cuando hay dos o más switches que creen que son el switch activo de la pila. Esto puede observarse cuando hay una ruptura en el anillo de una pila (es decir, cuando dos cables están desconectados de la pila), por lo que tanto el activo como el en espera pierden la comunicación con los otros miembros. La adición de un switch ya alimentado a una pila actual puede provocar una fusión de la pila, ya que puede haber dos switches activos en la pila.

ID de bug de Cisco CSCuh58098 - La pila 3850 puede recargarse cuando hay problemas de cableado de la pila

Cisco bug ID CSCui56058 - Habilita la lógica de rebote para el cable de pila

ID de bug de Cisco CSCup5338 - 3850 caída de IOSD | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset: Código de motivo:[4] Razón de restablecimiento:Restablecimiento/Recarga solicitado por [stack-manager]. [combinación de pila debido a incompatibilidad]

Esto se ha observado 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 modo en espera, el modo en espera puede intentar asumir el control como activo aunque el activo siga activo.

ID de bug de Cisco CSCuo49555

ID de bug de Cisco CSCup58016 : 3850/3650 falla debido a inundación de unidifusión en puerto de administración

Id. de error de Cisco CSCur07909 - Fusión de la pila debido a la pérdida de conectividad activa y en espera

Razón del restablecimiento: [stack-manager] solicitó el restablecimiento o la recarga. [Se encontró un vecino incorrecto después de la boleta ASIC]

Los switches participan en una boleta ASIC durante el arranque para determinar sus switches vecinos dentro de la pila. Este restablecimiento se puede ver cuando caduca un temporizador para que un vecino se declare a sí mismo o si hay un error lógico durante la conversación de difusión. Esto se ha visto en el contexto de cables de pila defectuosos que se han resuelto mediante la sustitución.

Id. de bug Cisco CSCun60777 - Switch recargado debido a vecino incorrecto encontrado después de la boleta ASIC

Id. de bug Cisco CSCud93761 - Switch recargado debido a vecino incorrecto encontrado después de la boleta ASIC

ID de bug de Cisco CSCun17506 - Amur:ng3k:same neighbor se ve en ambos puertos de pila en una pila de 3 miembros

hap_sup_reset: Código de motivo:[4] Razón de restablecimiento: Reinicio/Recarga solicitado por [stack-manager]. [lost both active and standby]

Normalmente, esto se observa 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 que asuma la función activa para la pila, se puede restablecer toda la pila. Si la pila es un estado inestable o la política de redundancia aún no se ha sincronizado, esto se puede ver. Esto es probablemente una víctima de la razón por la que los switches activos/en espera se desactivaron o, potencialmente, una indicación de que la redundancia no se sincroniza correctamente. Esto también se puede ver en cuando las pilas se configuran en una configuración de medio anillo.

Id. de error de Cisco CSCup5382- Switches miembros en un reinicio de pila 3850 - [perdió tanto activo como en espera]

hap_sup_reset: Código de motivo:[1] Razón de restablecimiento: Reinicio/Recarga solicitado por [stack-manager]. [Keepalive_Timeout]

Se ve cuando no se reciben mensajes de activación desde el switch en la pila. Consulte Trace Buffer: redundancy-timer-ha_mgr y muestra el intercambio de mensajes de "keep alive" y proporciona una perspectiva de tiempo para cuando comenzó la interrupción en la comunicación. Si recopila informes de switch del resto de la pila y observa los registros durante todo el período de tiempo, puede ayudar.

hap_sup_reset: Razón del restablecimiento: restablecimiento/recarga solicitada por [stack-manager]. [Volver a cargar comando]

Esta es una razón de reinicio bastante intuitiva - esto se ve cuando el gestor de la 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 los casos del ID de bug de Cisco CSCuj17317, esto también se muestra como un comando reload ejecutado también. En el archivo de registro: Cisco 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 relacionados

Cisco bug ID CSCur76872 - El gestor de la pila se desactiva cuando el sistema se queda sin memoria intermedia SDP.

Id. de error de Cisco CSCup49704 - Desperfecto de FED 3850 - Espera a los canales SPI FED_SPI_FLCD,FED_SPI_FAST ...

Diagnóstico de un problema potencial de puerto o cable de la pila

Síntoma 1) Cualquier indicio de un problema con el cable de pila es evidente por cualquier inestabilidad del puerto de pila antes del reinicio. Observe el archivo de registro: el informe de Cisco IOS antes de un reinicio es generalmente un buen lugar para comenzar. A continuación se muestra un ejemplo de dónde se ve el aleteo del puerto de pila que está registrado tanto en el SW2 actual como en el SW1 en espera. Este mismo puerto de pila estaba inestable cada uno en cada instancia del restablecimiento y se resolvió en el momento en que se reemplazó el cable de pila:

=====================  log file: Cisco 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 sentido de pila que se utiliza (180, 480 y más), el número de anillos de transmisión por puerto ASIC varía. Estos comandos sondean los registros globales que mantienen un total que aumenta en función de la cantidad de errores de lectura que se observan para cada anillo de transmisión. Port-asic 0 corresponde al puerto de pila 1 y port-asic 1 corresponde al puerto de pila 2. Esto debe emitirse para cada switch y cualquier signo de cuenta que aumente puede aislar si puede haber un problema en el puerto o con el cable de pila.

Se pueden recopilar varias veces durante unos minutos para comparar los deltas en el recuento:

show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>

• Segmento con error 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 clave PCS desconocida, que ejecuta un error de disparidad detectado.

show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>

• El error de bit en la pila causó el error CRC de la palabra de llamada.

Para Polaris (código 16.X) estos son los comandos:

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>

En este ejemplo se muestra dónde 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. Verá el incremento de ring[0] con CRC en el puerto 1 de la pila del switch 1 y, para superar este problema, reemplace el cable de la pila.

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

Sugerencias adicionales

1. Archivar Directorios Crashinfo

Más switches en la pila significa que puede haber más archivos de informes que recopilar. Es fácil sentirse abrumado por el número de informes que se generan. La organización es vital para separar un fracaso. Busque una coherencia con las marcas de tiempo de cuándo 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 dados para que el cliente no cargue varios archivos. El directorio crashinfo también se puede archivar para que el usuario de Cisco pueda enviar un solo archivo que contenga los informes interesados. El siguiente ejemplo puede crear un contenedor llamado 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. Recuperar una pila inestable

Puede haber algunas situaciones en las que vea varios miembros en una recarga de la pila durante el arranque después de que se lleve a cabo el proceso de elección de la pila. Si un switch recargado se considera a sí mismo como el activo, esto a menudo puede llevar a un evento de combinación de pila y puede entrar en un estado de loop de inicio. En esta situación, puede ser recomendable preguntar al cliente de Cisco:

• Apague toda la pila y restablezca firmemente todos los cables de la pila.
• Encienda cada switch miembro de la pila uno por uno hasta que todos los miembros hayan convergido al estado esperado.
• En los casos en los que un miembro no pueda unirse a la pila, retírelo de la pila e intente arrancar a este individuo de forma independiente para resolver más problemas.

3. Generar informes del sistema manualmente

Los informes del sistema creados manualmente requieren que se habilite el servicio interno. Esto escribe un informe del sistema como un archivo de texto que se puede hacer por base de 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>

Información Relacionada

• Soporte técnico y descargas de Cisco