Sommario

Introduzione

Panoramica

Scenario di arresti anomali

Motivo dell'arresto anomalo

Tipi diversi di arresto anomalo

Requisito per i log iniziali

Fasi dell'analisi

Ripristino della sessione

Introduzione

Questo documento descrive come trovare e risolvere i problemi di arresto anomalo di StarOs Facility.

Panoramica

In alcuni casi, la logica di sistema può interrompersi, causando il riavvio di un'attività software per ripristinare il corretto funzionamento. Questo può causare un arresto anomalo del processo. Gli arresti anomali delle strutture operative vengono spesso segnalati in StarOS e le azioni necessarie possono essere intraprese in base alla causa principale dell'incidente. Per identificare gli arresti anomali sul nodo, è possibile utilizzare questo 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

Arresti anomali simili vengono consolidati in un unico record. Nel record viene visualizzato il numero di volte in cui si è verificato questo tipo di arresto anomalo.

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

Dentro  show snmp trap history verbosel'output mostra che alcuni processi si sono arrestati in modo anomalo:

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

Scenario di arresti anomali

I motivi degli arresti anomali possono essere diversi:

1. Diversi scenari di flusso di chiamate

2. Problemi di memoria

3. Problema di configurazione

4. Guasti hardware

Motivo dell'arresto anomalo

In StarOS sono presenti più strutture di attività con le loro funzionalità individuali in modo che, in base alle funzioni, ogni volta che la struttura incontra un input di questo tipo in uno stato di errore, si blocca la struttura per recuperare da quello stato di errore.

Tipi diversi di arresto anomalo

1. Asserzione non riuscita:

********************* 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. Errore di segmentazione:

********************* 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. Segnale di errore irreversibile:

********************* 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 per i log iniziali

Il registro di arresto anomalo del sistema costituisce una valida fonte di informazioni sugli eventi di arresto anomalo. In caso di guasto del software, StarOS acquisisce e memorizza dati importanti che possono aiutare a determinare la causa del guasto. Queste informazioni possono essere memorizzate nella memoria di sistema oppure trasferite e salvate su un server di rete.

Core File o Mini Core File: i file core corrispondono ai PID in cui si è verificato l'arresto anomalo. I file core sono denominati nel formato "crash-<card no>-<cpu>-<pid>-<unixtime>-core". Queste informazioni sono disponibili nell'output del comando "show crash list".

File Minicore: questo file contiene informazioni sull'operazione non riuscita, tra cui l'analisi dello stack corrente, gli esempi di profiler passati, gli esempi di attività di memoria passate e altri dati aggregati in un formato di file proprietario.

Core Dump (o Full Core): un core dump fornisce un dump completo della memoria del processo subito dopo il crash. Questo dump della memoria è spesso essenziale per identificare la causa principale del guasto del software.

Firme di arresto anomalo del sistema: le firme di arresto anomalo possono essere esaminate da Show Support Details (SSD) condiviso o da altre fonti rilevanti.

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

Se si desidera conoscere la firma dell'arresto anomalo 1, eseguire una ricerca in SSD con CRASH #01 o nella CLI utilizzando 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

Esaminare Show Support Details (SSD) e syslog durante l'indicatore orario specifico in cui si è verificato il problema.

Fasi dell'analisi

1. È necessario controllare lo stack/la firma dell'arresto anomalo del sistema e controllare se ci sono bug per quella particolare firma dell'arresto anomalo.

2. Necessità di analizzare il corefile/minicore per analizzare la traccia di ritorno e per ottenere un indizio su quale funzione si è verificato il crash della struttura.

3. Una volta eseguito il debug del corefile, è necessario verificare i sintomi con il difetto del software e se esiste un difetto del software per una firma di arresto anomalo e una backtrace simili.

Ripristino della sessione

Il software StarOs è progettato per gestire sia condizioni/eventi previsti che condizioni/eventi imprevisti. Mentre Cisco cerca di avere un software perfetto, inevitabilmente ci sono degli errori e degli arresti anomali sono possibili. Ecco perché la funzione di ripristino della sessione è così importante.

La funzione di ripristino della sessione fornisce il failover e la ricostruzione senza interruzioni delle informazioni sulla sessione del sottoscrittore in caso di guasto hardware o software all'interno del sistema che impedisca la disconnessione di una sessione utente completamente connessa. Il ripristino della sessione viene eseguito eseguendo il mirroring dei principali processi software (ad esempio, il gestore delle sessioni e il gestore AAA) all'interno del sistema. Questi processi con mirroring rimangono in stato di inattività (modalità standby), in cui non eseguono alcuna elaborazione finché non possono essere necessari in caso di errore del software (ad esempio, l'interruzione di un'attività di un gestore di sessione).

Attività come le attività demux, AAA Manager e VPN Manager dispongono di meccanismi di ripristino automatico integrati nei nostri sistemi, specificamente per la gestione delle informazioni degli abbonati. Il ripristino della sessione si riferisce principalmente agli scenari in cui si verifica un errore nell'attività sessmgr o un errore a livello di scheda e le sessioni devono essere ripristinate senza alcuna perdita di chiamate.

- Nel sistema, un gestore delle sessioni in standby è attivo su ciascuna scheda di elaborazione e può assumere rapidamente il ruolo di gestore delle sessioni primario in caso di guasto. Viene quindi creato un nuovo sessmgr in standby sulla scheda di elaborazione.

- Quando un processo sessmgr si interrompe in modo imprevisto, sessmgr in standby recupera le informazioni di backup da aamgr (AAA manager) e ne ricrea le sessioni.

- Se l'operazione non riesce, aamgr in standby interroga sessmgr per sincronizzare le informazioni rilevanti sul sottoscrittore.

- In caso di errore di demux-mgr, esegue una query su tutti i sessmgrs e ricostruisce il proprio database di informazioni sulla distribuzione delle chiamate.

- Per garantire la ridondanza a livello di scheda, una scheda di elaborazione funge da standby, pronta per essere utilizzata in caso di guasto hardware o software. La scheda di standby recupera quindi le sessioni da un peer manager in esecuzione su una scheda diversa.

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