ワイヤレス : Cisco ASR 5000 シリーズ

ASR5x00 セッションマネージャ タスク-機能、クラッシュ、リカバリ オペレーションおよびクラッシュ ログの説明

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 25 日) | フィードバック

概要

この資料は Cisco 集約 サービス ルータ(ASR) 5x00 シリーズ用のソフトウエア 信頼性、サービス アベイラビリティおよびフェールオーバー 機能を説明し、説明したものです。 それは ASR5x00 のソフトウェア の クラッシュのための定義およびソフトウェア の クラッシュの効果を示します。 技術情報は ASR5x00 が固有ソフトウェア 復元力による「キャリアクラスの」アベイラビリティおよび機能 アベイラビリティのの目標を提供どのようにできるか予想外ソフトウェア の クラッシュの場合にはそれを確立することを続きます。 モバイル サブスクライバは決してサービスのアベイラビリティについて考えなければならないべきではありません。 Cisco の目標はあらゆる単一 ハードウェアまたはソフトウェア障害によるセッション ロス完全なシステムの損失が含まれている、要するに-音声帯域信頼性ではないです。 ASR5x00 のソフトウエア 信頼性 機能は不慮失敗がオペレータのネットワークで発生するかもしれなければ「キャリアクラスの」サービス アベイラビリティのための目標を達成できるために目標とされます。

Krishna Kishore D V によって貢献される、Cisco TAC エンジニア。

ソフトウェアアーキテクチャ: 復元力のために設計されている

ASR5x00 にパケット サービス カード(PSC)またはデータ処理カード(DPC)およびいろいろ特定の機能を行うように設計されているシステム管理 カード(SMC)または管理および I/O (縮小)カードを渡って配られるソフトウェア タスクの収集があります。

たとえば、セッションマネージャ タスクは一組のサブスクライバのためのセッションを処理する役割がありピアツーピアのようなインライン サービスを行うために(P2P)、ユーザトラフィックの強度 の パケット インスペクション(解像度)、等。 認証、許可、アカウンティング(AAA)マネージャ タスクは請求イベントの生成に責任がある加入者トラフィック 使用方法を等記録するためです。 セッションマネージャおよび PSC/DPC カードで動作する AAA マネージャ タスク。

SMC/MIO カードは維持 管理のために予約済みです(O&M)およびプラットフォーム関連するタスク。 ASR5x00 システムはサブスクライバ セッションを処理するためのセッション サブシステムおよび IP アドレス 割り当てに責任がある、ルーティング、等 VPN サブシステムのような異なるソフトウェア サブシステムに事実上区分されます。 それが制御するサブシステムの健全性を監督する各サブシステムにコントローラ タスクがあります。 SMC/MIO カードで動作するコントローラ タスク。 セッションマネージャおよび AAA マネージャはタスク制御、データトラフィックおよび計算の目的でサブスクライバのセッションを処理するために一緒に組み合わせられます。 セッション リカバリがシステムで有効に なるとき、各セッションマネージャ タスクはセッションマネージャ クラッシュの場合に回復 されるべきピア AAA マネージャ タスクのサブスクライバ状態のセットの状態をバックアップします。

クラッシュとは何か。

ASR5x00 のタスクは正常な動作の間に障害状態に出会う場合可能性としてはクラッシュできます。 ASR5x00 のクラッシュかソフトウェア エラーはシステムのタスクの予想外終了または終了であるために定義されます。 クラッシュはソフトウェアコードが(破損したデータ構造のような)禁止されているアクセスメモリ エリアに、等出会えば(無効 な 状態遷移のような)期待されないコードの条件に、試みる場合起こる場合があります。 クラッシュはまたタスクがシステム モニタ タスクに無理解になり、モニタがタスクを止め、再起動するように試みれば場合引き起こすことができます。 クラッシュ イベントはまたシステムで現在のステートをダンプするようにタスク状態を分析するためにタスクが CLI コマンドまたはシステム モニタによって強制されるとき明示的に(予想外に対して)引き起こすことができます。 期待されたクラッシュ イベントはまたシステムコントローラ タスクが正しい彼ら自身を可能性としては繰り返し失敗するマネージャ タスクの状況再起動するとき起こる場合があります。

セッションマネージャ クラッシュの効果

それらのサブスクライバ セッションのための請求を処理する正常な動作の下で、セッションマネージャ タスクはピアリング AAA マネージャ タスクと共に一組のセッションのためのサブスクライバ セッションおよび関連するデータ トラフィックを処理します。 セッションマネージャ クラッシュは発生するときシステムにあり終えます。 セッション リカバリがシステムで有効に なる場合、スタンバイ セッションマネージャ タスクは同じ PSC/DPC カードでアクティブになるためになされます。 この新しいセッションマネージャ タスクはピア AAA マネージャ タスクと通信すると同時にサブスクライバ セッションを復帰させます。 リカバリ オペレーションは 50 ミリ秒からセッションの数に依存したクラッシュの時にセッションマネージャおよびカードの全面的な CPU負荷で等アクティブだった数秒まで及びます。 サブスクライバ セッションに損失がありませんこのオペレーションのオリジナル セッション マネージャで既に確立された。 どのサブスクライバ セッションでもまたクラッシュの時に確立の過程においてあった多分プロトコル 再送信が等復元する原因です。 クラッシュの時にシステムによって遷移にできるあり、および接続は新しいセッションマネージャによって再送信されるネットワーク接続の通信エンティティによってネットワーク損失と関連付けられると仮定されて運ばれますどのデータパケットでも。 セッションマネージャが伝送したピア AAA マネージャでセッションのための請求情報は維持されます。

オペレータはいつ心配している得る必要がありますか。

セッションマネージャ クラッシュが発生するとき、回復手順は以前に記述されていてシステムの他がこのイベントによって変化しなく残るように起こり。 1 人のセッションマネージャのクラッシュは他のセッションマネージャに影響を与えません。 クラッシュされたタスクのインポートを奪取 しにはシステムが新しいセッションマネージャを始められる十分に速くかもしれませんのでオペレータへの指導として、同じ PSC/DPC カードクラッシュの同時にまたは互いの 10 分以内のマルチセッション マネージャ タスクが、そこにセッションの損失であるかもしれません場合。 これはセッションの損失が発生する場合がある二重エラー シナリオに対応します。 リカバリが実行不可能なとき、セッションマネージャは新しいセッションを受け入れて準備ができています単に再起動し。

ある特定のセッションマネージャが(それのような同じ障害状態に何回も出会います)繰り返しクラッシュする時、セッション コントローラ タスクはメモを奪取 し、サブシステムを復元するために再起動します。 セッション コントローラ タスクがセッション サブシステムを安定させることができ、この努力でそれ自身を絶えず再起動する場合、拡大の次 の ステップはスタンバイ SMC/MIO カードに切り替えるべきシステムのためです。 まずないイベントではスタンバイ SMC/MIO カードがないことまたは失敗がスイッチオーバ オペレーションで直面すれば、システムはそれ自身をリブートします。

セッションマネージャはまたクラッシュが発生するとき各アクセス ポイント ネーム(APN)のための統計情報を、サービス、永久に失われる functionalites、等維持します。 従って bulkstats を集める外部 エンティティは定期的に 1つ以上のクラッシュが発生する場合統計情報のすくいを観察します。 これは時間軸引かれる統計情報のグラフィカル表示のすくいとして明示できます。

: 7-14 PSC か 4-10 DPC カードと読み込まれる典型的なシャーシは PSC/DPC カードの番号に依存している 120-160 セッションマネージャについて持ち単一クラッシュは統計情報の約 1/40Th または 1/80Th の損失という結果に終ります。 スタンバイ セッションマネージャが引き継ぐとき、それはゼロからの統計情報を再度集め始めます。

クラッシュが発生したかどうかわかる方法か。

クラッシュはネットワーク モニタリング モニタリングステーションに、イベントモニタリング サービス(EMS)のようなおよび syslog イベントによって SNMPトラップ イベントを引き起こします。 システムに発生したクラッシュはまた提示クラッシュ list コマンドで観察することができます。 ことにこの先に記述されているようにおよび期待されたクラッシュ イベント予想外コマンド リスト注目して下さい。 これら二つのクラッシュ の タイプ イベントは各クラッシュを記述するヘッダによって顕著である場合もあります。

成功したセッション リカバリに先行しているタスク クラッシュはこのログメッセージによって示されます:

"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#>"

回復できなかったタスク クラッシュはこのログメッセージによって示されます:

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

要約すると、有効に されて セッション リカバリがほとんどの場合クラッシュはサブスクライバ影響がないので注意されません。 1 つはログか SNMP 通知でクラッシュの発生を検出するために CLI コマンド、か一見を入力しなければなりません。

次に、例を示します。

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

クラッシュ ロギング アーキテクチャ

ソフトウェア の クラッシュ(完全なコアダンプ)に関係するクラッシュ ログはすべての可能性のある 情報を記録します。 サイズが原因で、それらはシステムメモリで保存することができません。 従って、これらのログはシステムがローカルデバイスかログが保存することができるネットワークサーバを指す URL で設定される場合その時だけ生成されます。

クラッシュ ログはクラッシュ催物の表示部分の耐久性があるリポジトリです。 各イベントは番号が付いて、CPU (minicore)、ネットワーク 演算処理装置(NPU)、またはカーネル クラッシュと関連付けられるテキストが含まれています。 記録 された イベントは固定長レコードに記録され、/flash/crashlog2 で保存されます。

クラッシュが発生する時はいつでも、このクラッシュ情報は保存されます:

  1. イベント レコードは /flash/crashlog2 ファイル(クラッシュ ログ)で保存されます。
  2. 関連する minicore、NPU、またはカーネル ダンプする ファイルは /flash/crsh2 ディレクトリで保存されます。
  3. 完全なコアダンプはユーザ設定 ディレクトリで保存されます。

管理カード間のクラッシュ イベントおよび Minicores の同期

カード "8" がアクティブであると crashlog は管理カードのそれぞれにユニークです、従ってクラッシュが発生すればログオンされたカード "8" です。 それ以降の切り替えはもはやログのクラッシュを表示する。 このクラッシュを、スイッチバックするはカード "8" に取得するためにされなければなりません。 クラッシュ イベントログおよびダンプはアクティブな、スタンバイ管理カードにユニークです、従ってクラッシュがアクティブ カードにそして発生すればクラッシュ イベントログおよび関連ダンプはアクティブ カードだけで保存されます。 このクラッシュ情報はスタンバイカードで利用できません。 アクティブ カードのクラッシュによるカード引き継ぐスイッチオーバおよびクラッシュ情報がカードでもはや表示する時はいつでも、クラッシュ情報は現在のアクティブ カードからだけ検索することができます。 他のカードのクラッシュ リストを取得するために、スイッチオーバが再度必要となります。 このスイッチオーバを避け、スタンバイカードからのクラッシュ情報を得るために、2 つの管理カード間の同期がおよびクラッシュ情報のメンテナンスは必要となります。

到着クラッシュ イベントはスタンバイ SMC/MIO に送られ、同じような方法のスタンバイの crashlog ファイルで保存されます。 アクティブ SMC/MIO のフラッシュするの Minicore、NPU、またはカーネル ダンプは rsync コマンドでスタンバイ SMC/MMIO に同期される必要があります。 crashlog エントリか全リストは CLI コマンドによって削除されるとき、アクティブな、スタンバイ SMCs/MIOs で消す必要があります。 メモリに影響がありません。 すべてのクラッシュ関連同期 アクティビティはスタンバイ SMC/MIO カードの evlogd によってスタンバイ evlogd がより少なくロードされるスタンバイカードに同期 アクティビティのための十分な余地があるので、行われ。 従ってシステムのパフォーマンスは影響を受けていません。

コマンド

これらのコマンドは問題を解決するために使用することができます:

#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

Corefiles はクラッシュの後で生成されます。 通常オペレータは外部サーバでそれらを保存します。 crash-<Cardnum>-<CPU Num>-<Hex timestamp>-coree.gcrash-09-00-5593a1b8-core のように corefile 通常名前見え。

クラッシュが発生する時はいつでも、このクラッシュ情報は保存されます:

  • イベント レコードは /flash/crashlog2 ファイル(クラッシュ ログ)で保存されます。
  • 関連する minicore、NPU、またはカーネル ダンプする ファイルは /flash/crsh2 ディレクトリで保存されます。

要約

ASR5x00 ソフトウェアすべては予知された状態/イベントを両方処理するようにおよび不慮状態/イベントを設計されています。 Cisco は完全なソフトウェアがあるように努力する間、当然誤りはあり、クラッシュは可能性のあるです。 そういうわけでセッション 回復機能はとても重要です。 Cisco は完全さのために最小限に抑えますクラッシュの発生回数を努力し、セッション リカバリはセッションがクラッシュの後で続くようにします。 それにもかかわらず Cisco が完全なソフトウェアを実現させるように努力し続けることは、重要です。 少数のクラッシュは同時に起こる複数のクラッシュの確率を下げます。 セッション リカバリがシームレスに 単一クラッシュを直す間、複数の同時クラッシュからのリカバリは別様に少し設計されています。 オペレータはまれに(または決して)複数の同時クラッシュを経験する必要がありますそのような物が発生することサブスクライバ セッションの犠牲で高優先順位としてシステム 保全を、可能性のある 回復 するように ASR5x00 は設計されています。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 119224