Tâches du gestionnaire de session ASR5x00 - Description de la fonction, des pannes, des opérations de récupération et des journaux de panne

Introduction

Ce document décrit et explique la fiabilité du logiciel, la disponibilité du service et les fonctionnalités de basculement pour la gamme Cisco ASR 5x00. Il présente la définition d'une panne logicielle sur ASR5x00 et les effets de la panne logicielle. L'article poursuit en précisant que même en cas de panne logicielle inattendue, comment l'ASR5x00 peut atteindre l'objectif d'une disponibilité de classe opérateur en raison des fonctionnalités inhérentes de résilience et de disponibilité des logiciels. L'abonné mobile ne devrait jamais avoir à penser à la disponibilité du service. L'objectif de Cisco est de ne pas perdre de session en raison de pannes matérielles ou logicielles uniques, notamment la perte d'un système complet, c'est-à-dire la fiabilité de niveau voix. Les fonctionnalités de fiabilité du logiciel sur ASR5x00 sont ciblées pour atteindre les objectifs de disponibilité du service de classe opérateur même dans les cas où des pannes imprévues peuvent survenir sur le réseau d'un opérateur.

Architecture logicielle : Conçu pour la résilience

L'ASR5x00 comprend un ensemble de tâches logicielles réparties sur les cartes PSC (Packet Services Card) ou DPC (Data Processing Card) et SMC (System Management Card) ou les cartes MIO (Management and I/O) conçues pour exécuter diverses fonctions spécifiques.

Par exemple, la tâche gestionnaire de session est chargée de gérer les sessions d'un ensemble d'abonnés et d'exécuter des services en ligne tels que P2P (Peer-to-peer), DPI (Deep Packet Inspection), etc., sur le trafic utilisateur. La tâche du gestionnaire AAA (Authentication, Authorization, and Accounting) est responsable de la génération des événements de facturation afin d'enregistrer l'utilisation du trafic des abonnés, etc. Les tâches du gestionnaire de session et du gestionnaire AAA s'exécutent sur la carte PSC/DPC.

La carte SMC/MIO est réservée aux opérations et à la maintenance (O&M) et aux tâches liées à la plate-forme. Le système ASR5x00 est virtuellement compartimenté en différents sous-systèmes logiciels, tels que le sous-système session pour le traitement des sessions d'abonnés et le sous-système VPN responsable de l'attribution d'adresses IP, du routage, etc. Chaque sous-système a une tâche de contrôleur qui supervise l'état du sous-système qu'il contrôle. Les tâches du contrôleur s'exécutent sur la carte SMC/MIO. Les tâches du gestionnaire de session et du gestionnaire AAA sont associées afin de gérer la session d'un abonné à des fins de contrôle, de trafic de données et de facturation. Lorsque la récupération de session est activée dans le système, chaque tâche du gestionnaire de session sauvegarde l'état de son ensemble d'états d'abonnés avec une tâche du gestionnaire AAA homologue à récupérer en cas de panne du gestionnaire de session.

Qu'est-ce qu'un accident ?

Une tâche de l'ASR5x00 peut potentiellement se bloquer si elle rencontre une situation de panne pendant un fonctionnement normal. Une panne ou une panne logicielle dans l'ASR5x00 est définie comme une sortie ou une fin inattendue d'une tâche dans le système. Une panne peut se produire si le code logiciel tente d'accéder aux zones de mémoire interdites (telles que les structures de données corrompues), rencontre une condition dans le code qui n'est pas attendue (telle qu'une transition d'état non valide), etc. Un plantage peut également être déclenché si la tâche ne répond plus à la tâche de surveillance du système et si l'analyse tente de tuer et de redémarrer la tâche. Un événement de panne peut également être explicitement déclenché (par opposition à inattendu) dans le système lorsqu'une tâche est forcée de vider son état actuel par une commande CLI ou par le moniteur système afin d'analyser l'état de la tâche. Un événement de panne prévu peut également se produire lorsque les tâches du contrôleur système redémarrent elles-mêmes afin de corriger une situation avec une tâche de gestionnaire qui échoue à plusieurs reprises.

Effets d'une panne d'un gestionnaire de session

En fonctionnement normal, une tâche gestionnaire de session gère un ensemble de sessions d'abonnés et le trafic de données associé pour les sessions, ainsi qu'une tâche gestionnaire AAA d'appairage qui gère la facturation pour ces sessions d'abonnés. Lorsqu'un plantage du gestionnaire de session se produit, il cesse d'exister dans le système. Si la récupération de session est activée dans le système, une tâche de gestionnaire de session de secours est effectuée pour devenir active dans la même carte PSC/DPC. Cette nouvelle tâche de gestionnaire de session rétablit les sessions d'abonnés lorsqu'elle communique avec la tâche de gestionnaire AAA homologue. L'opération de récupération varie de 50 ms à quelques secondes en fonction du nombre de sessions actives dans le gestionnaire de sessions au moment du plantage et de la charge CPU globale sur la carte, etc. Il n'y a aucune perte dans les sessions d'abonnés qui ont déjà été établies dans le gestionnaire de session d'origine dans cette opération. Toute session d'abonné en cours d'établissement au moment de la panne sera probablement également restaurée en raison de retransmissions de protocole, etc. Tous les paquets de données qui étaient en transition via le système au moment de la panne peuvent être considérés comme associés à une perte de réseau par les entités communicantes de la connexion réseau et seront retransmis et la connexion sera effectuée par le nouveau gestionnaire de session. Les informations de facturation des sessions transportées par le gestionnaire de sessions seront conservées dans le gestionnaire AAA homologue.

Quand l'exploitant devrait-il s'inquiéter ?

Lorsqu'un plantage du gestionnaire de sessions se produit, la procédure de récupération se produit comme décrit précédemment et le reste du système reste inchangé par cet événement. Un plantage dans un gestionnaire de session n'a pas d'impact sur les autres gestionnaires de session. À titre d'orientation pour l'opérateur, si plusieurs tâches de gestionnaire de session sur la même carte PSC/DPC se bloquent simultanément ou dans les 10 minutes qui suivent l'une de l'autre, il se peut que le système ne soit pas en mesure de démarrer de nouveaux gestionnaires de session assez rapidement pour remplacer les tâches en panne. Cela correspond à un scénario de double défaillance où la perte de sessions peut se produire. Lorsque la récupération n'est pas possible, le gestionnaire de sessions est simplement redémarré et prêt à accepter de nouvelles sessions.

Lorsqu'un gestionnaire de session donné tombe en panne à plusieurs reprises (par exemple lorsqu'il rencontre la même condition de panne à plusieurs reprises), la tâche du contrôleur de session prend note et se redémarre dans une tentative de restauration du sous-système. Si la tâche du contrôleur de session ne peut pas stabiliser le sous-système de session et se redémarre continuellement dans cet effort, l'étape suivante de la remontée est que le système passe à une carte SMC/MIO de secours. Dans l'éventualité improbable où il n'y a pas de carte SMC/MIO de secours ou si une défaillance se produit lors de l'opération de commutation, le système redémarre lui-même.

Les gestionnaires de session tiennent également à jour des statistiques pour chaque nom de point d'accès (APN), les services, les fonctionnalités, etc., qui seront définitivement perdus en cas de panne. Par conséquent, une entité externe qui recueille périodiquement des statistiques sur les bulkstats observe une baisse dans les statistiques lorsqu'un ou plusieurs incidents se produisent. Cela peut se manifester par une diminution dans une représentation graphique des statistiques dessinées sur un axe temporel.

Note: Un châssis type équipé de cartes PSC 7-14 ou DPC 4-10 a environ 120-160 gestionnaires de session, selon le nombre de cartes PSC/DPC, et un seul crash entraînera la perte d'environ 1/40^{ème ou 1/80 ème} des statistiques. Lorsqu'un gestionnaire de session de secours prend le relais, il commence à accumuler à nouveau les statistiques à partir de zéro.

Comment savoir si un accident s'est produit ?

Un plantage déclenche un événement de déroutement SNMP vers une station de surveillance réseau, tel que le service EMS (Event Monitoring Service) et par des événements syslog. Les plantages qui se sont produits dans le système peuvent également être observés avec la commande show crash list. Notez que cette commande répertorie à la fois les événements de panne inattendus et attendus, comme décrit précédemment. Ces deux types d'événements de collision peuvent être distingués au moyen d'un en-tête qui décrit chaque incident.

Un plantage de tâches suivi d'une récupération de session réussie est indiqué par ce message de journal :

"Death notification of task <name>/<instance id> on <card#>/<cpu#> sent to parent
 task <parent name>/<instance id> with failover of <task name>/<instance id>
 on <card#>/<cpu#>"

Un plantage de tâche qui n'a pas pu être récupéré est indiqué par ce message de journal :

"Death notification of task <name>/<instance id> on <card#>/<cpu#> sent to parent
 task <parent name>/<instance id>"

En résumé, avec la récupération de session activée, dans la plupart des cas, les plantages ne seront pas remarqués car ils n'ont aucun impact sur les abonnés. Il faut entrer la commande CLI ou regarder les journaux ou la notification SNMP pour détecter toute occurrence de plantages.

Exemple :

 ******** show crash list *******
Tuesday May 26 05:54:14 BDT 2015
=== ==================== ======== ========== =============== =======================
#           Time         Process  Card/CPU/        SW          HW_SER_NUM
                                     PID         VERSION       MIO / Crash Card
=== ==================== ======== ========== =============== =======================

1   2015-May-07+11:49:25 sessmgr  04/0/09564 17.2.1          SAD171600WS/SAD172200MH
2   2015-May-13+17:40:16 sessmgr  09/1/05832 17.2.1          SAD171600WS/SAD173300G1
3   2015-May-23+09:06:48 sessmgr  03/1/31883 17.2.1          SAD171600WS/SAD1709009P
4   2015-May-25+15:58:59 sessmgr  09/1/16963 17.2.1          SAD171600WS/SAD173300G1
5   2015-May-26+01:15:15 sessmgr  04/0/09296 17.2.1          SAD171600WS/SAD172200MH

 ******** show snmp trap history verbose *******
 Fri May 22 19:43:10 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:29 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:30 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 9 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1754 calls recovered 1754 all call lines 1754 time elapsed ms 1108.
 Fri May 22 19:43:32 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:44:49 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:44:49 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:49 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:51 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 7 Cpu Number 0 fetched from aaa mgr 1741 prior to audit 1741 passed audit
 1737 calls recovered 1737 all call lines 1737 time elapsed ms 1047.
 Fri May 22 19:44:53 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:50:04 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 221 card 2 cpu 1 
: Fri May 22 19:50:04 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 221 on card 2 cpu 1
 Fri May 22 19:50:04 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 221 on card 2 cpu 1
Fri May 22 19:50:05 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 2 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1749 calls recovered 1750 all call lines 1750 time elapsed ms 1036.

 ******** show snmp trap history verbose *******
 Fri May 22 19:43:10 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:29 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:30 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 9 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1754 calls recovered 1754 all call lines 1754 time elapsed ms 1108.
 Fri May 22 19:43:32 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:44:49 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:44:49 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:49 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:51 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 7 Cpu Number 0 fetched from aaa mgr 1741 prior to audit 1741 passed
 audit 1737 calls recovered 1737 all call lines 1737 time elapsed ms 1047.
 Fri May 22 19:44:53 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:50:04 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 221 card 2 cpu 1 
: Fri May 22 19:50:04 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 221 on card 2 cpu 1
 Fri May 22 19:50:04 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 221 on card 2 cpu 1
Fri May 22 19:50:05 2015 Internal trap notification 183 (SessMgrRecoveryComplete
) Slot Number 2 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1749 calls recovered 1750 all call lines 1750 time elapsed ms 1036.

 ******** show logs  *******
2015-May-25+23:15:53.123 [sitmain 4022 info] [3/1/4850 <sitmain:31> sittask.c:4762]
 [software internal system critical-info syslog] Readdress requested for facility
 sessmgr instance 5635 to instance 114
2015-May-25+23:15:53.122 [sitmain 4027 critical] [3/1/4850 <sitmain:31>
 crash_mini.c:908] [software internal system callhome-crash] Process Crash Info:
 time 2015-May-25+17:15:52(hex time 556358c8) card 03 cpu 01 pid 27118 procname
 sessmgr  crash_details 
Assertion failure at acs/acsmgr/analyzer/ip/acs_ip_reasm.c:2970
  Function: acsmgr_deallocate_ipv4_frag_chain_entry()
  Expression: status == SN_STATUS_SUCCESS
  Proclet: sessmgr (f=87000,i=114)
  Process: card=3 cpu=1 arch=X pid=27118 cpu=~17% argv0=sessmgr
  Crash time: 2015-May-25+17:15:52 UTC
  Recent errno: 11 Resource temporarily unavailable
  Stack (11032@0xffffb000):
    [ffffe430/X] __kernel_vsyscall() sp=0xffffbd28
    [0af1de1f/X] sn_assert() sp=0xffffbd68
    [0891e137/X] acsmgr_deallocate_ipv4_frag_chain_entry() sp=0xffffbde8
    [08952314/X] acsmgr_ip_frag_chain_destroy() sp=0xffffbee8
    [089d87d1/X] acsmgr_process_tcp_packet() sp=0xffffc568
    [089da270/X] acs_process_tcp_packet_normal_path() sp=0xffffc5b8
    [089da3fd/X] acs_tcp_analyzer() sp=0xffffc638
    [0892fb39/X] do_acsmgr_process_packet() sp=0xffffc668
    [08940045/X] acs_ip_lean_path() sp=0xffffc6b8
    [0887e309/X] acsmgr_data_receive_merge_mode() sp=0xffffc9d8
    [0887f323/X] acs_handle_datapath_events_from_sm_interface() sp=0xffffca08
    [037c2e1b/X] sessmgr_sef_initiate_data_packet_ind() sp=0xffffca88
    [037c2f50/X] sessmgr_pcc_intf_send_data_packet_ind() sp=0xffffcaf8
    [061de74a/X] sessmgr_pcc_fwd_packet() sp=0xffffcb58
    [0627c6a4/X] sessmgr_ipv4_process_inet_pkt_part2_slow() sp=0xffffcf68
    [06318343/X] sessmgr_ipv4_process_inet_pkt_pgw_ggsn() sp=0xffffd378
    [0632196c/X] sessmgr_med_ipv4_data_received() sp=0xffffd418
    [0633da9a/X] sessmgr_med_data_receive() sp=0xffffd598
    [0afb977c/X] sn_epoll_run_events() sp=0xffffd5e8
    [0afbdeb8/X] sn_loop_run() sp=0xffffda98
    [0ad2b82d/X] main() sp=0xffffdb08

2015-May-25+23:15:53.067 [rct 13038 info] [5/0/7174 <rct:0> rct_task.c:305]
 [software internal system critical-info syslog] Death notification of task
 sessmgr/114 on 3/1 sent to parent task sessctrl/0 with failover of sessmgr/5635 on 3/1
2015-May-25+23:15:53.065 [evlog 2136 info] [5/0/7170 <evlogd:0> odule_persist.c:3102]
 [software internal system critical-info syslog] Evlogd crashlog: Request received to
 check the state of persistent crashlog.
2015-May-25+23:15:53.064 [sitmain 4099 info] [3/1/4850 <sitmain:31> crash_mini.c:765]
 [software internal system critical-info syslog] have mini core, get evlogd status for
 logging crash file 'crashdump-27118'
2015-May-25+23:15:53.064 [sitmain 4017 critical] [3/1/4850 <sitmain:31> sitproc.c:1544]
 [software internal system syslog] Process sessmgr pid 27118 died on card 3 cpu 1
 signal=6  wstatus=0x86
2015-May-25+23:15:53.048 [sitmain 4074 trace] [5/0/7168 <sitparent:50> crashd.c:1130]
 [software internal system critical-info syslog] Crash handler file transfer starting
 (type=2 size=0 child_ct=1 core_ct=1 pid=23021)
2015-May-25+23:15:53.047 [system 1001 error] [6/0/9727 <evlogd:1> evlgd_syslogd.c:221]
 [software internal system syslog] CPU[3/1]:  xmitcore[21648]: Core file transmitted to
 card 5 size=663207936 elapsed=0sec:908ms 
2015-May-25+23:15:53.047 [system 1001 error] [5/0/7170 <evlogd:0> evlgd_syslogd.c:221]
 [software internal system syslog] CPU[3/1]:  xmitcore[21648]: Core file transmitted to
 card 5 size=663207936 elapsed=0sec:908ms 
2015-May-25+23:15:53.047 [sitmain 4080 info] [5/0/7168 <sitparent:50> crashd.c:1091]
 [software internal system critical-info syslog] Core file transfer to SPC complete,
 received 8363207936/0 bytes 

 ******** show session recovery status verbose *******
Tuesday May 26 05:55:26 BDT 2015
Session Recovery Status:
  Overall Status        : Ready For Recovery
  Last Status Update    : 8 seconds ago

              ----sessmgr---  ----aaamgr----  demux
 cpu state    active standby  active standby  active  status
---- -------  ------ -------  ------ -------  ------  -------------------------
 1/0 Active   24     1        24     1        0       Good                     
 1/1 Active   24     1        24     1        0       Good                     
 2/0 Active   24     1        24     1        0       Good                     
 2/1 Active   24     1        24     1        0       Good                     
 3/0 Active   24     1        24     1        0       Good                     
 3/1 Active   24     1        24     1        0       Good                     
 4/0 Active   24     1        24     1        0       Good                     
 4/1 Active   24     1        24     1        0       Good                     
 5/0 Active   0      0        0      0        14      Good (Demux)             
 7/0 Active   24     1        24     1        0       Good                     
 7/1 Active   24     1        24     1        0       Good                     
 8/0 Active   24     1        24     1        0       Good                     
 8/1 Active   24     1        24     1        0       Good                     
 9/0 Active   24     1        24     1        0       Good                     
 9/1 Active   24     1        24     1        0       Good                     
10/0 Standby  0      24       0      24       0       Good                     
10/1 Standby  0      24       0      24       0       Good

Architecture de journalisation des incidents

Les journaux de panne enregistrent toutes les informations possibles relatives à une panne logicielle (vidage complet du coeur de réseau). En raison de leur taille, ils ne peuvent pas être stockés dans la mémoire système. Par conséquent, ces journaux ne sont générés que si le système est configuré avec une URL qui pointe vers un périphérique local ou un serveur réseau où le journal peut être stocké.

Le journal des incidents est un référentiel persistant d'informations sur les événements de panne. Chaque événement est numéroté et contient du texte associé à un processeur (minicore), une unité de traitement réseau (NPU) ou un plantage du noyau. Les événements consignés sont enregistrés dans des enregistrements de longueur fixe et stockés dans /flash/crashlog2.

Lorsque survient un plantage, ces informations sont stockées :

1. L'enregistrement d'événement est stocké dans le fichier /flash/crashlog2 (journal de panne).
2. Le fichier minicore, NPU ou kernel dump associé est stocké dans le répertoire /flash/crsh2.
3. Un vidage complet du coeur est stocké dans un répertoire configuré par l'utilisateur.

Synchronisation des événements de panne et des minicores entre les cartes de gestion

Le crashlog est unique à chacune des cartes de gestion, donc si un crash survient lorsque la carte « 8 » est active, elle sera connectée à la carte « 8 ». Un basculement ultérieur n'afficherait plus le plantage dans le journal. Pour récupérer ce plantage, il faut revenir à la carte « 8 ». Le journal des événements de panne et les vidages sont uniques aux cartes de gestion actives et de secours. Par conséquent, si une panne survient sur une carte active, le journal des événements de panne et les vidages associés sont stockés uniquement sur une carte active. Ces informations de panne ne sont pas disponibles sur la carte de secours. Chaque fois que les cartes changent en raison d'une panne de la carte active et que les informations de panne ne sont plus affichées sur la carte qui prend le relais, les informations de panne ne peuvent être récupérées que sur la carte active actuelle. Pour récupérer la liste de blocage de l'autre carte, un basculement est nécessaire à nouveau. Afin d'éviter cette commutation et d'obtenir les informations de panne à partir de la carte de secours, la synchronisation entre deux cartes de gestion et la maintenance des dernières informations de panne sont nécessaires.

L'événement d'écrasement entrant sera envoyé au SMC/MIO de secours et enregistré dans le fichier crashlog de secours de la même manière. Les vidages Minicore, NPU ou de noyau sur la mémoire flash de SMC/MIO actif doivent être synchronisés avec SMC/MMIO de secours avec la commande rsync. Lorsqu'une entrée crashlog ou la liste entière est supprimée par la commande CLI, elle doit être effacée sur les SMC/MIO actifs et de secours. Il n'y a aucun impact sur la mémoire. Toute l'activité de synchronisation liée à une panne sera effectuée par l'evlogd de la carte SMC/MIO de secours, car l'evlogd de secours est moins chargé et la carte de secours dispose de suffisamment d'espace pour l'activité de synchronisation. Par conséquent, les performances du système ne seront pas affectées.

Commandes

Ces commandes peuvent être utilisées afin de résoudre les problèmes :

#show support details

#show crash list

#show logs

#show snmp trap history verbose

#show session recovery status verbose

#show task resources facility sessmgr instance <>

#show task resources facility sessmgr all

Les fichiers corefiles sont générés après un plantage. Généralement, les opérateurs les stockent dans un serveur externe. Le nom du fichier corefile ressemble généralement à crash-<Cardnum>-<CPU Num>-<Hex timestamp>-coeur.gcrash-09-00-5593a1b8-core.

Lorsque survient un plantage, ces informations sont stockées :

• L'enregistrement d'événement est stocké dans le fichier /flash/crashlog2 (journal de panne).
• Le fichier minicore, NPU ou kernel dump associé est stocké dans le répertoire /flash/crsh2.

Résumé

Tous les logiciels ASR5x00 sont conçus pour gérer à la fois les conditions/événements prévus et les conditions/événements imprévus. Alors que Cisco s'efforce d'avoir un logiciel parfait, il y aura inévitablement des erreurs et des plantages possibles. C'est pourquoi la fonctionnalité de récupération de session est si importante. La recherche de la perfection par Cisco réduira au minimum le nombre d'incidents et la récupération des sessions permettra de poursuivre les sessions après un incident. Néanmoins, il est important que Cisco continue à s'efforcer d'obtenir des logiciels parfaits. Moins de collisions réduiront la probabilité de plusieurs collisions simultanées. Bien que la récupération de session guérit de manière transparente un seul incident, la récupération après plusieurs incidents simultanés est conçue un peu différemment. Les opérateurs doivent rarement (ou jamais) subir plusieurs plantages simultanés, mais si cela devait se produire, l'ASR5x00 est conçu pour récupérer l'intégrité du système comme priorité la plus élevée, éventuellement au détriment de certaines sessions d'abonnés.