Table des matières

Introduction

Aperçu

Scénario de plantages

Motif du plantage

Différents types de crash

Exigences initiales des journaux

Étapes d'analyse

Récupération de session

Introduction

Ce document décrit comment rechercher et dépanner les pannes de l'installation StarOs.

Aperçu

Parfois, la logique du système peut échouer, entraînant le redémarrage d'une tâche logicielle afin de restaurer le bon fonctionnement. Cela peut entraîner un blocage du processus. Les pannes de l'installation de tâches sont fréquemment signalées dans StarOS, et les actions nécessaires peuvent être prises en fonction de la cause première de la panne. Pour identifier les pannes sur le noeud, vous pouvez utiliser cette commande 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

Les incidents similaires sont regroupés dans un seul enregistrement. L'enregistrement affiche le nombre de fois que ce type de panne s'est produit.

********************* 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

Dans  show snmp trap history verboseLe résultat montre que certains processus se sont bloqués :

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

Scénario de plantages

Il peut y avoir plusieurs raisons différentes aux pannes :

1. Différents scénarios de flux d'appels

2. Problèmes de mémoire

3. Problème de configuration

4. Défaillances matérielles

Motif du plantage

Dans StarOS, vous disposez de plusieurs installations de tâches ayant leur fonctionnalité individuelle, donc en fonction des fonctions, chaque fois que l'installation rencontre une telle entrée où elle entre dans un état problématique, elle plante l'installation pour récupérer de cet état d'erreur.

Différents types de crash

1. Échec de l’affirmation :

********************* 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. Erreur de segmentation :

********************* 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. Signal fatal :

********************* 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

Exigences initiales des journaux

Le journal des incidents est une source précieuse d'informations sur les événements de panne. Lorsqu’une panne logicielle se produit, StarOS capture et stocke les données pertinentes qui peuvent aider à déterminer la cause de la panne. Ces informations peuvent être stockées dans la mémoire système ou transférées et enregistrées sur un serveur réseau.

Core File ou Mini Core File : notez que les fichiers Core correspondent au(x) PID où la panne s'est produite. Les fichiers principaux sont nommés au format « crash-<card no>-<cpu>-<pid>-<unixtime>-core ». Vous pouvez trouver ces informations dans le résultat de la commande "show crash list".

Minicore File : ce fichier contient des informations sur la tâche défaillante, y compris la trace de pile actuelle, les échantillons de profileur passés, les échantillons d'activité de mémoire passés et d'autres données regroupées dans un format de fichier propriétaire.

Core Dump (ou Full Core) : un core dump fournit un dump mémoire complet du processus immédiatement après le crash. Ce vidage de mémoire est souvent essentiel pour identifier la cause première de la panne logicielle.

Signatures de panne : les signatures de panne peuvent être consultées à partir du SSD (Show Support Details) partagé ou d'autres sources pertinentes.

******** 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

Maintenant, si vous voulez connaître la signature pour le crash 1, recherchez dans SSD avec CRASH # 01 ou dans CLI utilisez 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

Examinez les journaux système et les journaux de support technique (SSD) pendant l'horodatage spécifique au moment où le problème s'est produit.

Étapes d'analyse

1. Besoin de vérifier la pile/signature de plantage et de vérifier s'il y a des bogues pour cette signature de plantage particulière.

2. Besoin d'analyser le fichier principal/minicore pour analyser le retour en arrière et pour obtenir un indice pour quelle fonction l'installation a planté.

3. Une fois le débogage du fichier de base terminé, vous devez vérifier les symptômes avec le défaut logiciel et s'il y a un défaut logiciel existant pour une signature de plantage et un retour arrière similaires.

Récupération de session

Le logiciel StarOs est conçu pour gérer à la fois les conditions/événements prévus et les conditions/événements imprévus. Bien que Cisco s'efforce d'avoir un logiciel parfait, il est inévitable que des erreurs existent et que des pannes soient possibles. C'est pourquoi la fonction de récupération de session est si importante.

La fonction de récupération de session assure un basculement et une reconstruction sans interruption des informations de session de l'abonné en cas de défaillance matérielle ou logicielle du système empêchant la déconnexion d'une session utilisateur entièrement connectée. La récupération de session est effectuée en mettant en miroir les principaux processus logiciels (par exemple, le gestionnaire de session et le gestionnaire AAA) dans le système. Ces processus mis en miroir restent dans un état inactif (mode veille) dans lequel ils n'effectuent aucun traitement jusqu'à ce qu'ils puissent être nécessaires en cas de défaillance logicielle (par exemple, une tâche du gestionnaire de session est abandonnée).

Les tâches telles que les tâches de démultiplexage, le gestionnaire AAA et le gestionnaire VPN intègrent des mécanismes de récupération automatique dans nos systèmes, spécifiquement pour le traitement des informations des abonnés. La récupération de session se rapporte principalement aux scénarios dans lesquels il y a une défaillance dans la tâche sessmgr ou une défaillance au niveau de la carte, et les sessions doivent être récupérées sans aucune perte d'appel.

- Dans le système, un gestionnaire de session en veille est actif sur chaque carte de traitement et peut rapidement prendre le relais en tant que sessmgr principal en cas de défaillance. Un nouveau sessmgr de secours est ensuite créé sur la carte de traitement.

- Lorsqu'un processus sessmgr échoue de manière inattendue, le sessmgr de secours récupère les informations sauvegardées à partir de l'aamgr (gestionnaire AAA) et reconstruit ses sessions.

- Si l'aamgr échoue, l'aamgr de secours interroge le sessmgr pour synchroniser les informations d'abonné appropriées.

- En cas d'échec de demux-mgr, il interroge tous les sessmgr et reconstruit sa base de données d'informations de distribution d'appels.

- Pour assurer la redondance au niveau de la carte, une carte de traitement sert de carte de secours, prête à prendre le relais en cas de panne matérielle ou logicielle. La carte de secours récupère ensuite les sessions à partir d'un administrateur homologue exécuté sur une autre carte.

******** 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