Contenido

Introducción

Overview

Escenario de desperfectos

Motivo del desperfecto

Diferentes tipos de desperfecto

Requisito de registros inicial

Pasos del análisis

Recuperación de sesión

Introducción

Este documento describe cómo encontrar y resolver problemas de caídas de instalaciones de StarOs.

Overview

En ocasiones, la lógica del sistema puede fallar, lo que hace que se reinicie una tarea de software para restaurar la funcionalidad adecuada. Esto puede provocar un bloqueo del proceso. Los desperfectos en las instalaciones de tareas se notifican con frecuencia en StarOS, y se pueden tomar las acciones necesarias en función de la causa raíz del desperfecto. Para identificar caídas en el nodo, puede utilizar este comando CLI:

******** show crash list *******

Saturday April 15 05:05:56 SAST 2023

=== ==================== ======== ========== =============== =======================

#           Time         Process  Card/CPU/        SW          HW_SER_NUM

PID         VERSION       CF / Crash Card

=== ==================== ======== ========== =============== =======================

1   2022-Dec-02+14:08:46 confdmgr 02/0/19342 21.26.13        NA

2   2022-Dec-02+14:48:08 confdmgr 02/0/31546 21.26.13        NA

3   2022-Dec-04+19:10:50 sessmgr  03/0/12321 21.26.13        NA

4   2022-Dec-21+03:34:13 sessmgr  04/0/12586 21.26.13        NA

Las caídas similares se consolidan en un registro. El registro muestra el número de veces que se ha producido este tipo de desperfecto.

********************* CRASH #02 ***********************

SW Version          : 21.26.13

Similar Crash Count : 33 >>>>

Time of First Crash : 2022-Dec-02+14:10:05

Assertion failure at confdmgr/src/confdmgr_fsm.c:870

Note: State machine failure, state = 3

Function: confdmgr_fsm_state_wait_p0_handler()

Expression: 0

Code: CRASH

Proclet: confdmgr (f=1900,i=0)

Process: card=2 cpu=0 arch=X pid=31546 argv0=confdmgr

IN  show snmp trap history verboseEl resultado muestra que algún proceso se ha bloqueado:

Fri Dec 26 08:32:20 2014 Internal trap notification 73 (ManagerFailure) facility sessmgr

instance 188 card 7 cpu 0

Fri Dec 26 08:32:20 2014 Internal trap notification 150 (TaskFailed) facility sessmgr instance

188 on card 7 cpu 0

Fri Dec 26 08:32:23 2014 Internal trap notification 1099 (ManagerRestart) facility sessmgr

instance 139 card 4 cpu 1

Fri Dec 26 08:32:23 2014 Internal trap notification 151 (TaskRestart) facility sessmgr

instance 139 on card 4 cpu 1

Escenario de desperfectos

Puede haber varias razones diferentes para los desperfectos:

1. Diferentes escenarios de flujo de llamadas

2. Problemas de memoria

3. Problema de configuración

4. Fallos de hardware

Motivo del desperfecto

Usted tiene múltiples instalaciones de tareas en StarOS que tienen su funcionalidad individual por lo que en función de las funciones, siempre que la instalación encuentra cualquier entrada de este tipo donde está entrando en un estado problemático, se bloquea la instalación para recuperarse de ese estado de error.

Diferentes tipos de desperfecto

1. Fallo de afirmación:

********************* CRASH #22 ***********************

SW Version          : 21.26.13

Similar Crash Count : 33

Time of First Crash : 2023-Apr-12+22:40:01

Assertion failure at sess/smgr/sessmgr_snx.c:9568 >>>>

Function: sessmgr_snx_send_drop_call()

Expression: result == SN_STATUS_SUCCESS

Proclet: sessmgr (f=87000,i=261)

Process: card=5 cpu=0 arch=X pid=12724 cpu=~0% argv0=sessmgr

2. Falla de segmentación:

********************* CRASH #69 ***********************

SW Version : 21.13.3

Similar Crash Count : 2

Time of First Crash : 2019-Nov-25+07:53:54

Fatal Signal 11: Segmentation fault >>>>

Faulty address: 0x7ff6b4801036

Signal from: kernel

Signal detail: address not mapped to object

Process: card=8 cpu=1 arch=X pid=7316 argv0=vpp

Crash time: 2020-Feb-11+04:04:23 UTC

Build_number:

3. Señal mortal:

********************* CRASH #01 ***********************

SW Version          : 21.23.12

Similar Crash Count : 2

Time of First Crash : 2023-Jan-27+05:22:46

Fatal Signal 11: 11  >>>>>

PC: [04be6859/X] sessmgr_pgw_create_bearers()

Faulty address: 0x297116e4

Signal from: kernel

Signal detail: address not mapped to object

Process: card=9 cpu=1 arch=X pid=10383 cpu=~8% argv0=sessmgr

Requisito de registros inicial

El registro de desperfectos sirve como una valiosa fuente de información de eventos de desperfecto. Cuando se produce una caída del software, StarOS captura y almacena datos relevantes que pueden ayudar a determinar la causa de la caída. Esta información puede almacenarse en la memoria del sistema o transferirse y guardarse en un servidor de red.

Archivo de núcleo o archivo de núcleo mínimo: Tenga en cuenta que los archivos de núcleo corresponden a los PID en los que se produjo el desperfecto. Los archivos de núcleo se denominan con el formato "crash-<card no>-<cpu>-<pid>-<unixtime>-core". Puede encontrar esta información en el resultado del comando "show crash list".

Archivo de Minicore: este archivo contiene información sobre la tarea que falla, incluido el seguimiento de la pila actual, las muestras de perfiles anteriores, las muestras de actividad de memoria anteriores y otros datos agrupados en un formato de archivo propietario.

Vaciado de memoria (o núcleo completo): un vaciado de memoria proporciona un vaciado de memoria completo del proceso inmediatamente después de que se produjo el desperfecto. Este volcado de memoria es a menudo esencial para identificar la causa raíz de la caída del software.

Firmas de bloqueo: las firmas de bloqueo se pueden revisar desde el Show Support Details (SSD) compartido u otras fuentes relevantes.

******** show crash list *******

Saturday April 15 05:05:56 SAST 2023

=== ==================== ======== ========== =============== =======================

#           Time         Process  Card/CPU/        SW          HW_SER_NUM

PID         VERSION       CF / Crash Card

=== ==================== ======== ========== =============== =======================

1   2022-Dec-02+14:08:46 confdmgr 02/0/19342 21.26.13        NA

2   2022-Dec-02+14:48:08 confdmgr 02/0/31546 21.26.13        NA

3   2022-Dec-04+19:10:50 sessmgr  03/0/12321 21.26.13        NA

Ahora, si desea conocer la firma para el crash 1, busque en SSD con CRASH # 01 o en CLI utilice show crash number 1.

From SSD

********************* CRASH #01 ***********************

SW Version          : 21.26.13

Similar Crash Count : 1

Time of First Crash : 2022-Dec-02+14:08:46

Assertion failure at confdmgr/src/confdmgr_fsm.c:758

Note: State machine failure, state = 5

Function: confdmgr_fsm_state_wait_p1_handler()

Expression: 0

Code: CRASH

Using CLI

[local]abc# show  crash number 1

Friday June 09 06:41:53 CDT 2023

********************* CRASH #01 ***********************

SW Version          : 21.12.20.77760

Similar Crash Count : 1

Time of First Crash : 2021-Mar-31+15:58:06

Fatal Signal 6: Aborted

PC: [ffffe430/X] __kernel_vsyscall()

Note: User-initiated state dump w/core.

Signal from: sitmain pid=6999 uid=0

Process: card=9 cpu=0 arch=X pid=9495 cpu=~0% ar

Examine el Show Support Details (SSD) y los syslogs durante el registro de hora específico cuando ocurrió el problema.

Pasos del análisis

1. Necesita verificar la pila/firma de desperfecto y verificar si hay algún error para esa firma de desperfecto en particular.

2. Necesidad de analizar el archivo de núcleo/minicore para analizar el rastro y para obtener una pista de qué función se estrelló la instalación.

3. Una vez que se hace la depuración del archivo de núcleo, es necesario verificar los síntomas con el defecto de software y si hay algún defecto de software existente para una firma de desperfecto y seguimiento similares.

Recuperación de sesión

El software StarOs está diseñado para gestionar tanto las condiciones/eventos previstos como las condiciones/eventos imprevistos. Aunque Cisco se esfuerza por tener un software perfecto, inevitablemente existen errores y es posible que se produzcan bloqueos. Es por eso que la función de recuperación de sesión es tan importante.

La función de recuperación de sesión proporciona conmutación por fallas y reconstrucción sin problemas de la información de sesión del suscriptor en caso de un fallo de hardware o software dentro del sistema que impida que una sesión de usuario completamente conectada se desconecte. La recuperación de sesiones se realiza duplicando los procesos de software clave (por ejemplo, el administrador de sesiones y el administrador AAA) dentro del sistema. Estos procesos reflejados permanecen en estado inactivo (modo de espera), en el que no realizan ningún procesamiento hasta que se pueden necesitar en caso de que se produzca un error de software (por ejemplo, se anula una tarea del administrador de sesiones).

Tareas como las tareas de demux, el administrador AAA y el administrador VPN tienen mecanismos de recuperación automática incorporados en nuestros sistemas, específicamente para el manejo de la información del suscriptor. La recuperación de sesión se refiere principalmente a escenarios donde hay un error en la tarea sessmgr o un error en el nivel de la tarjeta, y las sesiones deben recuperarse sin ninguna pérdida de llamada.

- En el sistema, un administrador de sesiones en espera está activo en cada tarjeta de procesamiento y puede asumir rápidamente el control como sessmgr principal en caso de falla. A continuación, se crea un nuevo sessmgr en espera en la tarjeta de procesamiento.

- Cuando un proceso sessmgr falla inesperadamente, el sessmgr en espera recupera información de respaldo del aaamgr (administrador AAA) y reconstruye sus sesiones.

- Si el aaamgr falla, el aaamgr en espera consulta al sessmgr para sincronizar la información del suscriptor relevante.

- En caso de que se produzca un error en demux-mgr, consulta todos los sessmgrs y reconstruye su base de datos de información de distribución de llamadas.

- Para garantizar la redundancia a nivel de tarjeta, una tarjeta de procesamiento sirve como una tarjeta en espera, lista para tomar el control en caso de falla de hardware o software. La tarjeta standby entonces recupera las sesiones de un peer amgr que se ejecuta en una tarjeta diferente.

******** show session recovery status verbose *******

Saturday April 15 05:11:17 SAST 2023

Session Recovery Status:

Overall Status        : Ready For Recovery  >>>>

Last Status Update    : 5 seconds ago

----sessmgr---  ----aaamgr----  demux

cpu state    active standby  active standby  active  status

---- -------  ------ -------  ------ -------  ------  -------------------------

3/0 Active   40     1        40     1        0       Good

4/0 Active   40     1        40     1        0       Good

5/0 Active   40     1        40     1        0       Good

6/0 Active   40     1        40     1        0       Good

7/0 Active   0      0        0      0        10      Good (Demux)

8/0 Active   40     1        40     1        0       Good

9/0 Active   40     1        40     1        0       Good

10/0 Active   40     1        40     1        0       Good

11/0 Standby  0      40       0      40       0       Good