スイッチ : Cisco BPX/IGX/IPX WAN ソフトウェア

WAN スイッチ ソフトウェアのノード単位のアップグレード スクリプト

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


目次


概要

この文書では、IPX スイッチ、IGX 8400 シリーズ スイッチ、または BPX 8600 シリーズ スイッチのソフトウェアを正常にアップグレードできるように、シスコが推奨する 34 のポイントからなるプロセスを説明します。 このアップグレードの対象となるのは、ノード単位のアップグレード機能をサポートする、WAN スイッチ ソフトウェアのリリースが動作するネットワークです。 この文書では、必要な最低限の手順を一覧に示してから、各手順について詳しく説明します。 この文書に示す計画は、Cisco IPX/IGX/BPX などのネットワークのアップグレードですでに実証されています。

この文書は、スイッチ ソフトウェアを正常にアップグレードするための手引きとして使用することを目的としていますが、シスコ セールス エンジニア、システム エンジニア、またはアカウント マネージャによる適切な計画の代替とはなりません。

注意 注意: 下記のことをステップを実行する前に WAN スイッチ ソフトウェア アップグレード プランナーのステップに従うことは必要です。 Upgrade Planner に目を通さずに以下のステップを実行すると、ネットワークに問題が生じるおそれがあります。

前提条件

要件

このドキュメントに関する特別な要件はありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

IPX/IGX/BPX 製品用のスイッチ ソフトウェアのアップグレードには常に相当な計画が必要ではありますが、通常は、知覚されるようなネットワークの停止はほとんど、あるいはまったく起こりません。

ネットワーク サービスに影響を与えずにアップグレードを実現する技術は、この製品の最も初期のバージョンから変わっていません。 リリース 8.4 より前の IPX/IGX/BPX ソフトウェア アーキテクチャでは、ネットワーク内の全ノードで、スイッチ ソフトウェアの同じメジャー リリースを実行している必要がありました。 この要件を満たすには、すべてのノードを同時にアップグレードする必要がありました。

ネットワークのサイズが大きくなるにつれて、アップグレード時に発生する管理トラフィックの量も増加してきました。 その結果、どんなサイズのネットワークでも運用状態でのアップグレードを確実に行えるように、この手順が考案されました。 このアップグレード技術は、ノード単位のアップグレード機能をサポートする 1 つのソフトウェア リリースから、同様にノード単位のアップグレード機能をサポートする別のソフトウェア リリースにアップグレードする場合にお勧めする一連の処理です。

ノード単位の機能を使用すると、多数の手順があってもアップグレード中の IPX/IGX/BPX スイッチだけに合うように調整できます。 この調整機能によって、スイッチ ソフトウェアのアップグレード中の制御が楽になります。

この文書では、アップグレードされるネットワーク ノードを、ターゲット ノードと呼びます。 ターゲット ノードは、ネットワーク ノード全体のサブネットであると想定されます。 100-node ネットワークのターゲットノードの適度な数は 10.です。 スイッチ ソフトウェア リリース 8.4 では、cnffunc コマンドを使用して、ノード単位のアップグレード機能を有効にする必要がある場合があります。

この文書は、リリース 8.4.X 以降の環境で IPX/IGX/BPX をアップグレードするユーザを対象に作成されています。 この文書では、ユーザがこれらのスイッチに関して深い知識を持っていることは想定していませんが、基本的なスイッチの設定について理解していることを想定しています。

スイッチ ソフトウェアのリリース 9.2 からは、IPX プラットフォームはサポート対象外であることに注意してください。 9.2 にアップグレードする場合は、アップグレード前に IPX スイッチを交換しなければならない場合があります。

高レベルの計画

以下に、正常なアップグレードを行うために必要なステップの要約を示します。 ネットワークの規模にかかわらず、すべてのステップを完了する必要があります。

ステージ 1: 計画

タスク 説明
1 スイッチ ソフトウェア、つまり Cisco WAN Manager(CWM)(旧称 StrataView Plus(SV+))の新しいリビジョンを選択する。
2 選択したリリースの既知のソフトウェア障害を評価する。
3 リリース ノートを調べて、このリリース固有のアップグレード ステップについて確認する。
4 カードのファームウェア リビジョンおよびハードウェア リビジョンをチェックして、新しいソフトウェア リリースのサポート対象であることを確認します。
5 スクリプトを作成します。これは、ステージ 3 の特定のセクションに必要なパラメータの変更に役立つオプションの作業です。

ステージ 2: ネットワークの準備

注: このステージは、ソフトウェアをアップグレードする 1 週間前に完了しておく必要があります。

タスク 説明
6 ネットワークのヘルス チェックを行います。
7 スタンバイ コントロール カードをテストします。
8 アップグレード実行時までネットワークを詳細に監視する。
9 CWM(SV+)ステーションをアップグレードする。
10 ネットワーク ノードへのネットワーク管理接続を確認します。

ステージ 3: アップグレード

この段階におけるネットワークへの管理アクセスは、CWM(SV+)トポロジ マップおよび dspcds と dspalms コマンドを使用して、密接に監視する必要があります。

タスク 説明
11 プロビジョニングの凍結を開始する。
12 可能であれば、ネットワーク設定を CWM(SV+)ステーションに保存する。
13 統計情報の収集を停止します。
14 カードのエラー、ソフトウェアのログをクリアし、プロセッサのセルフ テストを無効にします。
15 統計サンプリング状態マシンを無効にする。
16 新しいリビジョンを CWM(SV+)ステーションにロードします。
17 cnfdlparm パラメータを変更します。
18 自動ジョブをすべて停止します。
19 新しいリビジョンをターゲットのネットワーク ノードにロードします。
20 プロセッサ カードの焼き付けを検証します。
21 ネットワークのアップグレードに備えて、パラメータを設定します。
22 すべてのメジャー アラームの原因と、可能であればすべてのマイナー アラームの原因を取り除く。
23 CWM(SV+)ステーションをシャットダウンし、必要に応じて再設定します。
24 必要に応じて、タスク 2 とタスク 3 で定義された回避策を実装します。
25 ネットワークが 30 秒間安定した状態であれば、スイッチ ソフトウェアをアップグレードします。
26 ネットワークを安定させ、お客様固有の検証テストを実行します。
27 スタンバイ プロセッサのロックを解除する。 アップグレードするノードごとに、タスク 25 から 27 までを繰り返します。
28 運用パラメータを設定する。
29 CWM(SV+)ワークステーションを再起動する。
30 ネットワークのヘルス チェックを行います。
31 統計情報の収集を再開する。
32 自動ジョブをすべて再開します。
33 ネットワーク設定を CWM(SV+)に保存する。
34 プロビジョニングの凍結を解除する。

タスク詳細

ステージ 1: 計画

タスク 1 スイッチ ソフトウェア CWM(SV+)の新しいリビジョンを選択します。

どのスイッチ ソフトウェア(ひいては CWM(SV+))を選択すればよいかは、現在のソフトウェア リビジョンやハードウェア要件など、いくつかの変数によって異なります。 Cisco テクニカル サポートに詳細については連絡して下さい。

CWM(SV+)の適切なリリースを選択するには、Cisco.com の『Cisco WAN Manager リリース』文書に掲載された該当するバージョンのリリース ノートを調べます。

注: CWM が統計情報の収集および表示を開始するまでに、アプリケーションのアップグレードまたは再初期化の終了後 1 時間から 2 時間かかります。

タスク 2 選択したリリースの既知のソフトウェア障害を評価する。

ソフトウェア障害の内容によっては、アップグレードを円滑に行うために追加の準備が必要となる場合があります。 これには、次の作業が考えられます。

タスク 3 リリース ノートを調べて、このリリース固有のアップグレード ステップについて確認する。

タスク 2 と同様に、ここでも次の作業が必要になることがあります。

タスク 4 カードのファームウェア リビジョンおよびハードウェア リビジョンをチェックして、新しいソフトウェア リリースのサポート対象であることを確認します。

IPX/IGX/BPX の場合、カードのリビジョンは dspcds コマンドにより入手できます。 このリビジョン情報と、スイッチ ソフトウェアのリリース ノートに記載されているスイッチ ソフトウェア/ファームウェア/ハードウェアの互換性マトリックスに基づいて、なんらかの変更が必要かどうかを評価します。 これらのリリース ノートは、「Cisco WAN スイッチング ソリューション」ページにあります。

冗長プロセッサ カード(NPC、NPM、または BCC)搭載のスイッチでは、両方のカードのファームウェア バージョン、BRAM サイズ、および RAM サイズが一致することを確認してください。

dspcds コマンド

dspcds コマンドを発行すると、スロットごとに次のような出力が表示されます。

3 FRM DTV FRI-V35 BF Standby

出力の各要素の意味は次のとおりです。

出力: 3 FRM DTV FRI - V35 BF スタンバイ
意味 <スロット番号> <カードのタイプ> <フロント カードのリビジョン> <バック カードのタイプ> <バック カードのリビジョン> <カードの状態>

上の出力での <front card revision> セクションは「DTV」です。 これは次のように解釈します。

出力: D T V
意味 カードのモデル カードのハードウェア リビジョン ファームウェアのリビジョン

最初の文字はカードのモデルを示します(この例では「D」)。 これはカードの機能セットを表す記号で、これを変更できるのはシスコとシスコ パートナーだけです。

2 番目の文字(この場合は「T」)は、カードのハードウェア リビジョンを示します。 これが変更されるのは、カードを工場に返送したときだけです。

3 番目の文字はファームウェアのリビジョンを示します(この例では「V」)。 これは同一モデル上でのバリエーションを表すもので、小規模な機能拡張やバグ修正に従って変更されます。 CWM(SV+)ワークステーションから新しいコードをダウンロードしてカードに焼き付けると、この文字が変わります。

特定のファームウェア イメージの番号については、A.B.C の形式で CCO に示されます。

  • A はカード タイプを示します。

  • B はモデルの識別子を示し、これによってカードの持つ機能の大部分がわかります。 たとえば、UVM モデル C (rev. A)にファームウェアDDA が、が UVM モデル D あります(rev. A)にファームウェアDDA があります。 モデル C は(数ある新機能の中でも特に)G.729 圧縮をサポートした最初の UVM モデルでした。 モデル D はモデル C でサポートされているすべての機能をサポートするほか、アイドル コードの圧縮のサポートなどが追加されています。

  • C はファームウェア バージョン レベルを示し、これは通常バグ修正レベルを表します。 上の例で使用されている最新の UVM ファームウェア レベルはリリース E、つまり DDE(UVM モデル D のバージョン E)です。

BPX または IGX に装備されているカードのリリース レベルをチェックするには、dspcds コマンドを使用します。 ノードでのリリース情報の表記法は、Cisco.com でファイル名を示す際に使われる表記法とは異なります。 具体的に言うと、ノードではハードウェアの互換性に関する情報も提供されます。 スイッチ ソフトウェアで使用される表記法は TYPE B.D.C の形式をとります。各記号の意味は次のとおりです。

  • TYPE はカード タイプの完全な名前を示します(UVM など)。

  • B はモデルの識別子を示します。

  • D はハードウェア バージョン レベルを示します。

  • C はファームウェア バージョン レベルを示します。

タスク 5 ステージ 3 の一部のセクションで必要なパラメータ変更を補助するためのスクリプトを記述する(オプション)。

スクリプトの作成およびテストには、次の利点があります。

  • パラメータの変更処理の実行が簡単になる。

  • 新しいリリースのソフトウェアで変更されたコマンドが強調される。

ネットワークのアップグレードを準備するときにパラメータを設定する製品があります。 これまでに、次のソフトウェア パッケージを使用して、正常にアップグレードを完了しています。

ステージ 2: ネットワークの準備

タスク 6 ネットワークのヘルス チェック

付録 A」を参照してください。

タスク 7 スタンバイ コントロール カードをテストします。

付録 B」を参照してください。

タスク 8 アップグレード実行時までネットワークを詳細に監視する。

タスク 6 で既存のネットワークの問題はすべて明らかになるはずですが、念のためにアップグレード実行時までネットワークを監視し、新しいソフトウェア エラーとカード エラーが発生していないことを確認します。 Cisco テクニカル サポートに繰り返し発生するエラーを報告して下さい。

ソフトウェア エラーとカード エラーのチェックについては、「付録 A」を参照してください。

タスク 9 CWM(SV+)ステーションをアップグレードする。

CWM(SV+)リリースは、その 2 つ後までのリリースのソフトウェアを実行しているネットワークであれば、管理することが可能です。

タスク 10 ネットワーク ノードへのネットワーク管理接続を確認します。

帯域内アクセスまたは帯域外アクセスのいずれかによって、個々のネットワーク スイッチに接続できることを確認します。 TELNET によって、ネットワークにある各 IPX/IGX/BPX に接続します。 ネットワークで帯域内アクセスと帯域外アクセスの両方を使用している場合は、それぞれのアクセスを個別にテストします。

ステージ 3: アップグレード

タスク 11 プロビジョニングの凍結を開始する。

アップグレードが完了するまで新しいサービスのプロビジョニングを休止します。

タスク 12 ネットワーク設定を保存する。

設定の保存および復元機能を購入した場合は、ネットワーク設定のスナップショットを CWM(SV+)ワークステーションに保存します。

この手順の詳細は、使用しているソフトウェア リリース用のコマンド リファレンス マニュアルから入手できます。

タスク 13 統計情報の収集を停止し、Statistics Collection Manager をシャットダウンします。

詳細は、「付録 D」を参照してください。

タスク 14 カード エラーおよびソフトウェア ログをクリアし、プロセッサのセルフ テストを無効にします。

アップグレード対象の全ノードで、次のコマンドを使用して、カード エラーおよびソフトウェア ログをクリアします。

  • clrcderrs *

  • clrswlog

  • clrswlog s

プロセッサのセルフ テストを無効にするには、cnftstparm コマンドを入力してから、現在再設定中のノードに関連するプロセッサのタイプを選択します。

タスク 15 統計サンプリング状態マシンを無効にする。

現在、シスコ エンジニアリングでは、アップグレードの loadrev フェーズの間は、統計情報サンプリング状態マシンを無効にしておくことを推奨しています。 以前は、runrev フェーズの間に、統計情報を無効にしていました。

アップグレードするすべてのノードにおいて、off1 コマンドまたは off2 コマンドを使用することで、これらの状態マシンを無効にできます。

次のパラメータを無効にする必要があります。

  • Conn Stat Sampling

  • Line Stat Sampling

  • Port Stat Sampling

注: これらの機能を無効にすると、実質的に dspchstats、dsptrkutl、dspportstats の各統計コマンドが無効になります。 トラブルシューティングの目的でこれらのコマンドが必要になったときは、新しいソフトウェアをロードした(ノードが Upgraded 状態になった)後で、ノードごとに状態マシンを再び使用可能にします。 アップグレードの runrev セクションの前には、再び使用可能にしたすべての状態マシンを無効にする必要があります。 状態マシンを再び有効にするには、on1 または on2 コマンドを使用します。

タスク 16 新しいソフトウェア リビジョンを CWM(SV+)ステーションにロードします。

新しいソフトウェア バージョンを CWM(SV+)ステーションにロードします。 イメージが正常にロードされたことを確認します。 validate_image <filename.img> コマンドを発行して、個々の CWM(SV+)ステーションでリビジョン イメージを検証します。 IPX/IGX/BPX スイッチの場合は、ファイル名が異なることに注意してください。

  • IPX イメージ番号には N が付いています。

  • IGX イメージ番号には G が付いています。

  • BPX イメージ番号には B が付いています。

タスク 17 cnfdlparm パラメータを変更します。

この作業によって、アップグレードのソフトウェア配布フェーズ(タスク 19)での処理が速くなります。 cnfdlparm コマンドを使用して、Session Timeout パラメータと Request Hop Limit パラメータを設定します。 アップグレードされるべきノードがネットワークの同じ位層幾何学領域でクラスタ化される場合、ターゲット(非 CWM)ノードは 4.に低くなる要求 ホップ制限があるかもしれません。 ノード間のホップ数を確認するには、drtop コマンドを発行します。

cnfdlparm コマンド出力では、セッション タイムアウトのフィールドとホップのフィールドを確認します。 アップグレードするノードが同じエリアにある場合は、ホップ制限要求の値を低減できます。 ホップ制限要求を確認するには、drtop コマンドを使用します。

  • すべてのネットワーク ノード: Session Timeout 30000

  • CWM(SV+)ノード: Request Hop Limit 1

  • ターゲット(CWM 以外)ノード: Request Hop Limit 8

タスク 18 自動ジョブをすべて停止します。

ターゲットの IPX/IGX/BPX ノードに設定されているすべての自動ジョブを、削除するか無効にします。

自動ジョブの詳細は、使用しているソフトウェアのリリース用のコマンド リファレンス マニュアルから入手できます。

タスク 19 新しいリビジョンをターゲットのネットワーク ノードにロードします。

そのためには、それぞれのターゲット ノードで、loadrev <new_revision> <node_name> コマンドを実行します。

dsprevs コマンドを実行した結果、すべての冗長ノードに Running プライマリ リビジョンと Upgraded セカンダリ リビジョンが表示されたら、ソフトウェアのダウンロードが完了しています。 セカンダリ リビジョンは、loadrev コマンドで使用したリビジョンと一致している必要があります。 スイッチ ソフトウェアのアップグレード中のプロセッサ カードの状態については、「WAN スイッチ ソフトウェアのアップグレード中のアクティブ コントロール カードとスタンバイ コントロール カードの状態」を参照してください。

冗長ではないノードの場合、セカンダリ リビジョンは Upgraded ではなく、Loaded であると表示されます。

プロセッサカード Electrically Erasable Programmable Read-Only Memory (EEPROM)のプログラミングと接続される障害はソフトウェアエラーと共にフラッシュ故障アラームという結果に終ります。 この種のアラームが発生した場合は、loadrev プロセスをもう一度試してください。 ネットワークで動作するソフトウェア リリースにノードを戻す loadrev コマンドを使用して下さい。 コマンドの構文は以下のとおりです。

loadrev <current_running_revision> <node_name>

このコマンドを入力したら、タスク 19 をもう一度開始します。 それでもエラーが発生する場合は、現在アクティブなカードを交換する必要があります。 その場合は、前に実行したのと同様に、loadrev コマンドを発行して、現在動作中のソフトウェア リリースにノードを戻します。 loadrev コマンドを発行した後で、dspcds コマンドと dsprevs コマンドを発行してノードが安定していることを確認します。 dspcds コマンドはアクティブおよびスタンバイプロセッサカードを表示する必要があります。 dsprevs コマンドはノードのための現在の実行ソフトウェア リリースだけ表示する必要があります。 ノードが安定したら、switchcc コマンドを入力します。 ここで、Standby(以前は、Active であったプロセッサ)プロセッサ カードを交換できます。

「付録 C」を参照してください。

タスク 20 プロセッサ カードの焼き付けを検証します。

注:  手順 20 を実行するのは、すべてのターゲット ノードのスタンバイ プロセッサをアップグレードした後です。 タスク 19 を参照してください。

すべてのターゲット ノードでプロセッサ カードの焼き付けを検証するには、次の作業を実行します。

  1. chkflash コマンドを実行します。

  2. Command プロンプトが返されたら、chkflash コマンド(タイムスタンプのエラー チェック)を実行した結果、記録されたエラーについて、ソフトウェア エラーのログをチェックします。

  3. chkflash コマンドが失敗すると、ソフトウェア エラーの 872、873、または 874 が記録されますが、その他のエラーが発生する場合もあります。

  4. All エラーは Cisco テクニカル サポートに報告する必要があります。 アップグレード プロセスをそのまま続けないでください。 エラーを記録した、1 つ以上のノードにあるソフトウェア リビジョンが破損している可能性があります。

タスク 21 ネットワークのアップグレードに備えて、パラメータを設定します。

パラメータの変更については、「付録 E」を参照してください。

タスク 2 およびタスク 3 で識別した、標準以外の必要な変更を含めます。

タスク 22 すべてのメジャー アラームの原因と、可能であればマイナー アラームの原因もすべて取り除きます。

タスク 25 でソフトウェアをアップグレードするときに、ネットワークにまったくアラームが発生していないことが理想です。 これが実現不可能な場合は、少なくともすべてのメジャー アラームの原因を特定してメモし、アラームを解消するために適切な再設定を行う必要があります。 ターゲット ノードのロード モデルを確認するには、「付録 A」で説明するように chklm コマンドと dsplm コマンドを発行します。

注: 1 つのプロセッサ カードが Upgraded 状態なので、再設定が適切であれば、CLI または CWM(SV+)から IGX/BPX/IPX ノードにログオンして設定を変更する必要はありません。

アップグレードの後で比較できるように、すべてのマイナー アラームを書きとめます。

注: 到達不能なノードがネットワーク上にあるときは、スイッチ ソフトウェアをアップグレードしないでください。

タスク 23 CWM(SV+)ステーションをシャットダウンし、必要に応じて再設定します。

ネットワーク全体をアップグレードする場合は、すべての CWM(SV+)ワークステーションをシャットダウンする必要があります。 CWM(SV+)をシャットダウンするには、CWM(SV+)のメイン メニューから、Stop Core オプションを選択します。 ネットワークの一部をアップグレードする場合は、この作業を実行する必要はありません。

CWM(SV+)を新しいソフトウェア リリースと連携して動作させるために設定の変更が必要な場合は、この時点で実施します。

タスク 24 必要に応じて、タスク 2 とタスク 3 で定義された回避策を実装します。

運用状態でのアップグレードに必要な回避策があれば、タスク 2 とタスク 3 で識別されます。

タスク 25 ネットワークが安定した状態が 30 分続いたら、スイッチ ソフトウェアをアップグレードする。

タスク 19 が正常に終了し、その後で手順 20 から 24 までの処理も正常に完了してから 30 分間、ネットワーク内でトポロジの変更がまったく発生しない場合は、

runrev <new_revision> <node_name>

コマンドをターゲット ノードの 1 つから実行します。 これにより、ネットワーク ノードにある新しいリリースが実行されます。

ターゲット ノードが安定していることを確認するには、次のコマンドを順番に発行します。

コマンド 必要な処置
dspprf IDLE RT が 40 より大きいことを確認して下さい。 そうでない場合、Cisco テクニカル サポートに連絡して下さい。
dsprevs 正しいソフトウェア リビジョンがロードされていることを確認します。
dspcds プロセッサ カードが Active 状態でかつ Locked 状態であることを確認します。
dspalms ターゲット ノードにメジャー アラームがまったくないことを確認します。

注:  アップグレード プロセスでは、ネットワークのクロック ソースが一時的に切り替えられるため、番号の最も大きいネットワーク ノードにおいて runrev コマンドを発行するときには注意する必要があります。 番号の最も小さいまたは最も大きいノードのアップグレードについては、シスコ セールス エンジニア、システム エンジニア、またはアカウント マネージャと調整してください。

タスク 26 ネットワークが安定してから、ネットワーク検証テストを実行します。

注: 上級ユーザ用の runrev インターバルについては、「付録 G」を参照してください。

ターゲット ノードのプロセッサにおいて、すべての管理アップデート作業を完了します。 この処理に要する合計時間は、ネットワーク内にあるノード数によって異なります。 1 つのノードについて、少なくとも 10 分は必要です。 この期間中、Command Line Interface(CLI; コマンドライン インターフェイス)を通じてノードにログインするのは最低限にとどめておきます。

10 分が経過したら、ターゲット ノードにログインし、次のコマンドによってヘルス チェックを行います。

次のコマンドを順番に発行してください。

コマンド 必要な処置
dspprf IDLE RT が 40 より大きいことを確認して下さい。 そうでない場合、Cisco テクニカル サポートに連絡して下さい。
dsprevs 正しいソフトウェア リビジョンがロードされていることを確認します。
dspalms ターゲット ノードにメジャー アラームがまったくないことを確認します。
dspcds スタンバイ プロセッサが Locked 状態であり、かつ Failed 状態のカードがないことを検証します。
dspswlog 新しいソフトウェア エラーについてチェックします。
dspswlog s 新しいソフトウェア エラーについてチェックします。
dspcderrs 新しいカード エラーについてチェックします。
dsptrks すべてのトランクの状態を確認します。
dspnds 到達不能ノードについてチェックします。
dspnode フィーダ シェルフがあれば、その状態を確認します。
dspsloterrs 新しいスロット エラーについてチェックします。

注: 各種の状態マシンをタスク 15 で無効にしたので、dspportstats コマンドや dspchstats コマンドは機能しません。

この期間は、新しいソフトウェアが正常に動作しているかどうかのチェック テストを実行する絶好の機会です。

IPX/IGX/BPX ネットワークと接続しているルータを管理する、すべての外部管理システムに問い合せます。 この問い合せでは、すべてのデバイスが到達可能であることを確認します。

可能であれば、エンド ユーザに連絡して、ネットワーク接続がすべて正常な状態にあるかをチェックするよう依頼します。

注: デシジョンが前のソフトウェアリビジョンに戻す奪取 されるまずないイベントでは Cisco テクニカル サポートは古い修正への切り替え前に連絡する必要があります。 古いリビジョンに切り替えてしまうと、新しいソフトウェアが正常に動作しない理由についての重要な情報が得られなくなります。

タスク 27 スタンバイ プロセッサのロックを解除する。

アップグレードするノードごとに、タスク 25 、タスク 26、およびタスク 27 までを繰り返します。 ノードのアップグレードごとに、ノードが安定していることを確認し、運用テストを実行するための時間を十分とってください。 「付録 F」を参照してください。

タスク 28 運用パラメータを設定する。

タスク 12、タスク 17、および タスク 21 で変更したすべてのパラメータを、タスク 6 でキャプチャした元の設定に戻す必要があります。

注: 実際にパラメータの変更に使用するコマンドは変わることがあります。 また、新しいソフトウェア リリースのもとでネットワークを正しく運用するために、他のパラメータの調整が必要になることもあります。 技術的な推奨事項と新しいデフォルト値については、リリース ノートを参照してください。

タスク 29 CWM(SV+)ステーションを再起動します。

CWM(SV+)のメイン メニューから、Start Core オプションを選択します。

タスク 30 ネットワークのヘルス チェック

付録 A」を参照してください。

タスク 31 統計情報の収集を再開する。

CWM(SV+)のメイン メニューから該当するオプションを選択して、Statistics Collection Manager(SCM; 統計情報収集マネージャ)を再起動します。

関連するすべての統計情報を選択します(「タスク 13」で作成した注意事項を参照)。 次の処理を実行します。

  1. config プルダウン メニューから stats enable を選択します。

  2. すべての統計グループをチェックし、必要な統計タイプを selected セクションに移します。

  3. 次の手順に従って、すべてのノードに stats enable を送信します。

    • config プルダウン メニューから、node selection を選択します。

    • すべてのノードが選択されていることを確認したら、Send Stats Enable オプション ボタンを押し、次に OK を押します。

    • SCM メイン ウィンドウ内にある Outgoing Requests / Incoming Responses ウィンドウを監視して、SNMP put がすべてのノードに送信されたこと、およびそれぞれに対して OK の応答が返されていることを確認します。

  4. -config コマンドを入力します。

  5. -node コマンドを入力します。

  6. すべてのノードが選択されていることを確認したら、Start Statistics Collection オプション ボタンを押して、次に OK をクリックします。

タスク 32 自動ジョブをすべて再開します。

ターゲット IPX/IGX/BPX ノードに設定された全自動ジョブをもう一度有効にする必要があります。 CWM(SV+)ステーションにある cron ジョブもすべて、もう一度有効にする必要があります。

ジョブの詳細については、使用しているソフトウェア リリースに関連するコマンド リファレンス マニュアルを参照してください。

タスク 33 ネットワーク設定を保存する。

詳細は、「タスク 12」を参照してください。

タスク 34 プロビジョニングの凍結を解除する。

付録A: タスク6:: ネットワークのヘルス チェック

次の手順に従ってください。

  1. 次のコマンドを使用してパラメータを検査して下さい。 ネットワーク内にある同じタイプのノードすべてにわたって設定が一貫していることが必要です。 パラメータの違いやデフォルト値との差異があればすべて記録します。

    • cnfnodeparm

    • cnfcmparm

    • cnfdlparm

    • cnffstparm

    • cnfdiagparm

    • cnftstparm

    • cnfprfparm

    • on1

    • on2

    • on3

    • (設定はネットワーク全体に実行されているため、チェックする必要があるのは 1 つのノードだけです)

    • cnffunc

    • dspmnupdt

    • cnftlparm(8.4 以上)

    • cnfsnmp

    • cnfcmb (IGX/IPX だけは、設定広くネットワークはです)

    同じタイプのノード間でのパラメータの違いやデフォルト値との差異がある場合はそれらを評価し、ソフトウェア アップグレードに影響を及ぼさないことを確認します。 アドバイスが必要となる場合 Cisco テクニカル サポートに連絡して下さい。

  2. ネットワークを監査し、最近のソフトウェア エラー(アクティブおよびスタンバイ コントローラ カード)、CPU のアイドル時間、カード エラー、ロード モデルの不一致、トランク エラー、およびアラームについて調べます。 この作業には、次のコマンドを使用します。

    • dspswlog

    • dspswlog s

    • dspcderrs または dspcderrs <slot #>

    • dsptrkerrs

    • dspalmsdspslotalmsdspbusesdspsloterrs (BPX だけのために)

    • dspprf、か dspprfhist

    これらのコマンドを使用して、ノードの CPU が空いている合計時間をチェックします。 これらのコマンドを発行すると、20 秒ごとに、各プロセスが使用する CPU の合計時間がサンプリングされます。 この場合、ノード igx16 では、サンプリング時に 88 % がアイドル状態です。 次に、これらのコマンドの典型的な出力例を示します。

    igx16   TN   StrataCom   IGX 16    8.2.56   Oct. 13 1997 17:47 GMT
            
    Active    0   262079990   -20   262059990   -40   262039990 Current
            
    Proc   RT  HSds LSds      RT  HSds LSds        RT  HSds LSds 
    IDLE   88   43    0       89   46    0         88   65    0 
    RSRC    0   12    0       0   13    0          0   15    0 
    CBUS    0   76    0       0   75    0          0   78    0 
    NETW    0   53    0       0   48    0          0   58    0 
    TRNS    2  199    0       2  187    0          2  216    0 
    FAIL    4    8    0       3    4    0          4    2    0 
    SNMP    0    0    0       0    0    0          0    1    0 
    PROT    0    0    0       0    2    0          0    1    0 
    TXIO    0    0    0       0    0    0          0    0    0 
    ILMI    0    0    0       0    0    0          0    0    0 
    SUMM    2    4    0       3    1    0          2    2    
    
    • chklm または dsplm: これらのコマンドはネットワークの他のすべてのノードと現在のノードのデータベースのセクションを比較します。 chklm コマンドを、順にネットワークの各ノードで実行します。 それが完了したら、最初のノードに戻って dsplm コマンドを実行します。 次に出力例を示します。

      igx16   TN   StrataCom   IGX 16   8.2.56   Oct. 13 1997 17:52 GMT 
      
      Nd T L C LC 
      32 P P P P  

      この例は 2 つのノードが含まれているネットワークに倣います:

      NodeName J/Num
      
      igx16     /16
      igx32     /32
      

      igx16 上で dsplm コマンドを実行すると、igx16 のデータベースの特定のセクションと igx32 の特定のセクションを比較した出力結果が表示されます。 この場合、出力結果の P はパスを示し、すべてが正常であることを示します。 何らかの障害が発生していると、dsplm コマンドの出力画面に F が示されます。

      注: 8.4 より後のソフトウェア リリースでは、ネットワーク トポロジが直前に変更された場合、dsplm コマンドは誤った結果を出力します。

次の手順に従ってください。

  1. 次の点を調査します。

    • 最近のソフトウェア エラー: どのノードでも Cisco テクニカル サポートに絶えず Log エラーまたは記録された最近のエラーが報告する必要がありますあります。

    • カード エラー。 カードは Cisco テクニカル サポートによって自己/バックグラウンドテスト失敗を記録 するか、またはハードウエアエラーの履歴がある調査する必要があります。

    • CPU アイドル時間が 40 % よりも少ないノード(PCC の場合は 20 %): BPX/IGX/IPX ネットワークで CPU アイドル時間がこのような割合になることは通常は見られません。 このようなノードは詳細に調査する必要があります。 アイドル時間が一貫して低い場合、Cisco テクニカル サポートに連絡する必要があります。

    • ロード モデルのエラー。 これらは Cisco テクニカル サポートに報告する必要があります。 ソフトウェア リリース 8.4 以降ではトランク ベースのロード方式が使用されていて、ネットワーク トポロジが変更された直後にロード モデル エラーが示される場合があります。

    • エラーが記録されているトランク。 アップグレード期間中にエラーを解決するか、または管理トラフィックがこれらのトランクを通過しないように設定する必要があります。

    • すべてのアラームを考慮する必要があります。 このチェックの真の目的は、アップグレードの前に特別な介入を必要とするアラーム(バス障害など)がないことを確かめることにあります。

  2. アップグレードを開始する前に、必要な是正措置がすべて完了していることを確認します。

  3. アップグレード中は自動ジョブを削除する必要があるため、それらの場所をメモします。

付録 B タスク 7: スタンバイ コントロール カードのテスト

この作業は、ネットワークのサイズによって異なりますが、ノードあたり約 60 分かかります。

  1. ネットワーク内の各 IPX/IGX/BPX に順番に Service としてログオンし、dspcds コマンドを発行して、どのプロセッサが Active で、どのプロセッサが Standby であるかを調べます。

  2. 各 IPX/IGX/BPX で CC の冗長性を確認します。 cnfnodeparm コマンドを発行して、CC Redundancy Cnfged フィールドが Y であることを確認します。 CC Redundancy Cnfged フィールドが Y であれば、CC の冗長性が有効になっていることを示します。 CC の冗長性が有効になっていない場合、それについて調査し、可能であればもう一度有効にします。

  3. resetcd <card_number > h コマンドを発行して、Standby プロセッサをリセットします。

    注: 誤ってアクティブ カードをリセットすると、そのノードは再構築されます。

  4. NPC/NPM/BCC が Standby モードに戻った後で、dspswlog コマンドと dspswlog s コマンドを発行して、新しいエラーについてソフトウェアのログをチェックします。 フラッシュ プログラミングに障害があると、アラームとコントローラ カードの両方が切り替えられます。 Cisco テクニカル サポートにそのような発生を報告して下さい。

  5. リセットされたカードが Standby に戻った場合は、次のことを実行します。

    • dspqs コマンドを発行して、保留されているアップデートがないかどうかをチェックします。

    • 保留されているアップデートがない場合、switchcc コマンドを発行して、スタンバイ プロセッサに切り替えます。

    • switchcc を実行すると、現在のセッションの接続が解除されます。

  6. IPX/IGX/BPX にもう一度ログインして、ネットワークのヘルスを監視します。 Standby カードは、順番に次の状態に移行します。 Downloader、スタンバイ アップデート。 Standby カードのアップデートは、ノードごとに 3 時間ほどかかる場合があるので、それを考慮してスケジュールを組む必要があります。

  7. NPC/NPM/BCC が Standby モードに戻った後で、dspswlog コマンドと dspswlog s コマンドを発行して、新しいエラーについてソフトウェアのログをチェックします。 フラッシュ プログラミングが失敗するとアラームが発生し、コントローラ カードが切り替わります。 Cisco テクニカル サポートにそのような発生を報告して下さい。

  8. この手順は、ネットワーク内にあるアップグレード対象のノードごとに 1 回ずつ繰り返す必要があります。 次のノードの処理に移る前に、各ノードのスタンバイ カードが Update モードを完了していることを確認します。 ゲートウェイ ノードでプロセッサを切り替えると、CWM(SV+)とネットワークの間の通信が一時的に途絶えます。

    注: BPX の場合は、アップグレードを開始するとき(つまり、最初の loadrev コマンドを実行するとき)にアクティブ カードがスロット 8 にあることが推奨されます。

付録 C タスク 19: ネットワークに新しい修正をロードする手順

タスク 19 を完了するとき考慮するべき 2 つのケースがあります。 次にこの両方のケースを示します。いずれも次のトポロジに基づいています。

/image/gif/paws/10843/wan_switch_software_upgrade_node.gif

ケース 1

CWM(SV+)ワークステーション(上のトポロジ イメージでは SV+ プレフィクスによって表示)が、ネットワークの各ノード タイプのいずれか 1 つと接続されている場合は、タスク 19 を容易に実行できます。

すべてのスイッチがデフォルト設定のままであり、なおかつ CWM(SV+)ワークステーションに適切なソフトウェア リビジョンがロードされている場合に、上記のネットワークに存在する各ノード タイプの中の 1 ノードにそれぞれ新しいソフトウェア リビジョンをダウンロードするには、いずれかのノードで次のコマンドを実行する必要があります。

  • loadrev <new_revision> BPX1

  • loadrev <new_revision> IGX2

  • loadrev <new_revision> IPX

ケース 2

上記のトポロジにおいて、SV+2 および SV+3 が存在せず、全スイッチのタイプ用の新しいソフトウェア リビジョンが SV+1 にだけ存在する場合、タスク 19 を完了するには、一部のスイッチに対して少し再設定を行う必要があります。

ダウンロードはケース 1 と同じコマンドを実行することで開始されますが、この操作では IPX にソフトウェアがロードされるだけです。 新しいソフトウェアを IGX2 と BPX1 にロードするためには、次のように設定を変更する必要があります。

  1. 両方のノードで、cnffunc コマンドを入力すると、download from remote strataview 機能が有効になります。

  2. drtop コマンドを使用して、ターゲット ノード間のホップ数を確認します。 IGX2 は、IPX から 2 ホップ以上離れています。IPX は、CWM(SV+)ステーションが接続しているノードです。 IGX2 での距離の増加に対応するために、cnfdlparm コマンドを使用して、Request Hop Limit パラメータをケース 2 の実際のホップ カウントに設定する必要があります。

  3. ソフトウェアのダウンロードが完了したら、すべての変更を元に戻します。

ケース 1 とケース 2 の両方において次の状態が確認されると、ソフトウェアのダウンロードは完了です。

  • dsprevs コマンドの出力結果に、ノードに Running のプライマリ リビジョンがあると表示される。

  • loadrev コマンドで使用したリビジョンに、Upgraded セカンダリ リビジョンが一致している。

注: 冗長ではないノード(1 個のプロセッサを搭載したノード)の場合、セカンダリ リビジョンは Loaded と表示され、Upgraded とは表示されません。 たとえば、上記のトポロジで BPX1 に装備されているプロセッサ カードが 1 つだけであるとします。 ソフトウェアのダウンロードが完了してから dsprevs コマンドを実行すると、次の出力が表示されます(新しいソフトウェア バージョンが 8.4.09 で、現在のバージョンが 8.1.71 とします)。

BPX1    TN       StrataCom      BPX 15    8.1.71       Oct. 13 1997 17:20 GMT 

                  ------ Primary ------       ----- Secondary ----- 


NodeName          Status     Revision         Status     Revision 

IGX2              Running    8.1.71           Upgraded   8.4.09 
BPX1              Running    8.1.71           Loaded     8.4.09 
IPX               Running    8.1.71           Upgraded   8.4.09 
BPX2              Running    8.1.71 
IGX1              Running    8.1.71 
Failures connected with the programming of the card's electrically erasable programmable 
read-only memory (EEPROM) will result in Flash failure alarms in conjunction with 
software errors. In the event of such an alarm, try the loadrev process again. 
Any further failures will require the card to be replaced. 

ソフトウェアのダウンロードが完了したら(上記を参照)、次のタスクを実行してソフトウェアの焼き付けを検証します。

  1. 新しいソフトウェア リビジョンのあるノードで、chkflash コマンドを実行します。

  2. Command プロンプトが返されたら、chkflash コマンドの結果で記録されたエラーについて、ソフトウェア エラーのログ エントリとタイムスタンプをチェックします。 これには dspswlog コマンドを入力します。

エラーは Cisco テクニカル サポートに報告する必要があります。 アップグレード プロセスを続けないでください。エラーを記録した 1 つのノードまたは複数のノードにあるソフトウェア リビジョンが破損している可能性があります。

付録 D タスク 13: CWM (SV+) TFTP統計収集を無効にする手順

この作業は、アップグレード対象のノードでだけ実行する必要があります。 たとえば、100 台のノードのなかの 10 台だけをアップグレードする場合、10 台のターゲット ノードでだけ統計情報の収集を無効にする必要があります。

  1. 統計収集のステータスを確認します。

    ネットワーク内の各ノードで dspstatparms コマンドを入力して、統計収集が有効と無効のどちらになっているかを確認します。 出力例は統計収集と下記に示しますあります: 太字のテキストのステータス。

    igx16      TN       StrataCom        IGX 16     8.1.71        Date/Time Not Set 
    
    Statistics Configuration Parameters
    
    TFTP Retry Count:             3     TFTP Read Grant Delay (sec):      1
    TFTP ACK time-out (sec):     10     Enable Date:     00/00/00 00:00:00
    Bucket Interval:              0     Enabled from: not enabled
    File Interval:                0     Rt Interval:     00/00/00 00:00 GMT
    Peak Enable Flag:       DISABLED    Nt Second Offset:                 0
    Object Count:                 0          STATS COLLECTION: DISABLED
    Object Subtype Counts:    0 0 0 0        STANDBY UPDATES: ENABLED
    Total File Memory Used:       0 
    Number of File Allocated:     0 
    Current File Size:          531
    Stat Memory Allocated:        0 
    Auto Memory Allocated:        0 
    Auto Mem Rgn Size:       153600 
    
    Last Command: dspstatparm

    上に示されているようにディスプレイの右側でフィールド統計収集: 現在のステータスを示します。 ソフトウェアの以降のリリースではこのフィールドは Interval stats と呼ばれます: そして有効に なる統計情報の実際の数のその他の情報を持っています。

    統計収集が有効になっている場合は、残りのステップに進みます。

  2. 統計収集を無効にします。

    1. 統計情報のマスター ワークステーションで、StrataView Statistics Manager ウィンドウを開きます。 このマシンで SCM が動作していない場合は、CWM(SV+)のメイン メニューから起動する必要があります。

    2. SCM メイン ウィンドウで、config を選択してから、次に Node selection を選択します。 すべてのターゲット ノードが、画面の右側にある Selected Nodes ボックスに表示されている必要があります。 すべてのターゲット ノードが表示されない場合は、各ターゲット ノードの隣にある右矢印をクリックします。

    3. Select Action ボックスの下にある Stop Statistics Collection オプション ボタンを押し、OK ボタンをクリックしてボックスを閉じます。

    4. SCM メイン ウィンドウで、Current Status フィールドは Stopped と表示されている必要があります。

    5. Selected Statistics をすべて記録しておくと、アップグレード完了後にもう一度有効にできます。

    6. config、Stats Enable を選択し、次に統計グループを 1 つずつ順番に選択します。

  3. 個々の統計グループの下に、Statistics Enable / Disable ウィンドウがあります。 このウィンドウ内に、その特定グループの全カテゴリを表示する、Statistics Type ボタンがあります。 たとえば、次のカテゴリは、Connections グループの下に表示されます。

    • 音声

    • データ

    • フレーム リレー

    • ファースト PAD

    • ASI

    • AXIS フレームリレー

    • ATM 接続

    • CE 接続

  4. 個々のカテゴリを選択し、選択済みの統計情報をすべて Unselected ウィンドウに移動する必要があります。 すべてのカテゴリをチェックした段階で、そのグループについては Enable / Disable ウィンドウを閉じて、次のグループに移ります。すべてのグループの処理が終るまで繰り返します。

  5. すべてのグループのチェックが終わったとき、統計タイプはすべて選択解除されたことになります。 Enable / Disable ウィンドウがすべて閉じていることを確認したら、Config を選択し、次に SCM メイン ウィンドウから Node Selection を選択します。 この結果、統計情報をもう一度有効にする必要のあるノードが選択されます。

  6. この段階で、Stats Enable メッセージを各ターゲット ノードに送る必要があります。 Stats Enable メッセージは、1 回に最大 10 個のノードに送信される必要があります。 これを行うには、次の手順に従います。

    1. All という語の隣にある左矢印をクリックして、すべてのノードを選択解除します。

    2. リストにあるターゲット ノードを最大 10 個まで強調表示したら、Selected という語の隣にある右矢印をクリックして、Selected ボックスに強調表示したターゲット ノードを移動します。

    3. Select Action ボックスで、[Send Stats Enable] ラジオ ボタンをクリックして、次に [Apply] ボタンをクリックします。

    4. SCM メイン ウィンドウ内にある Outgoing Requests / Incoming Responses ウィンドウを監視して、SNMP put がすべてのノードに送信されたこと、およびそれぞれに対して OK の応答が返されていることを確認します。

    5. リスト上の次の 10 ノードについて同じ手順を繰り返します。

    6. すべてのノードの処理が終わったら、OK ボタンを選択して、ウィンドウを閉じます。

  7. ネットワーク内の各ノードで dspstatparms コマンドを入力して、すべてのノードの統計収集が無効になっていることを確認します。 show stats 収集がもしこのコマンド: 無効 DISABLED と表示されない場合は、上記で実行したように、Stats Enable メッセージを有効になっているノードに個々に再送信します。 統計収集が有効に されるようにそれでも示されている場合、Cisco テクニカル サポートに連絡して下さい。

付録 E タスク 21: パラメータを設定 して下さい

スイッチ ソフトウェアのアップグレード用に変更することが推奨されるパラメータを以下に示します。 他のパラメータはすべて、現在のオペレーティング ソフトウェアのデフォルト設定にしてください。 ただし、ネットワークのヘルス チェック中にデフォルト値とは異なると識別されても、スイッチ ソフトウェアのアップグレードに影響しないと判断されたパラメータは除きます。

注: 次のパラメータがコマンド内で表示される状態は、ソフトウェア リリースによって異なる場合があります。

IPX と IGX

コマンド: cnfnodeparm

パラメータ アップグレード用の値
Update Initial Delay 10000
Update Per-Node Delay 60000
Comm Break Test Delay 60000
Network Timeout Period 10000
Num Normal Timeouts 50
Comm Fail Interval 30000
Comm Fail Multiplier 6
Standby Update Timer 15
Stby Updates Per Pass 20
Gateway ID Timer 90
GLCON Alloc Timer 90
Comm Fail Delay 240

コマンド: cnfdlparm

パラメータ アップグレード用の値
Session Timeout 30000
Request Hop Limit(loadrev に対してのみ適用) 4

コマンド: cnffunc

パラメータ アップグレード用の値
Logging of conn events in local event log disabled
Logging of conn events in CWM (SV+) event log disabled

コマンド: off1/on1

パラメータ アップグレード用の値
Standby Terminal 有効
Line Diag disabled
Modem Polling disabled
Conn Stat Sampling disabled

コマンド: コマンド:off2 / on2

パラメータ アップグレード用の値
Statistical Sample (Line Stat Sampling) disabled
Statistical Alarm disabled
Job Ready Checker disabled
Power Supply Monitor disabled
FRP Port Sampling (Port Stat Sampling) disabled
Robust Updates disabled
Robust Alarm Updates disabled
Realtime Counters disabled
Update Standby Stats disabled
Junction ID disabled

コマンド: cnffstparm

RTD Measurement time 255

コマンド: cnftstparm

すべてのカード タイプについてセルフ テストとバックグラウンド テストをオフにする

BPX

コマンド: cnfnodeparm

パラメータ アップグレード用の値
Update Initial Delay 10000
Update Per-Node Delay 60000
Comm Break Test Delay 60000
Network Timeout Period 10000
Num Normal Timeouts 50
Comm Fail Interval 30000
Comm Fail Multiplier 6
Standby Update Timer 15
Gateway ID Timer 90
GLCON Alloc Timer 90
Comm Fail Delay 240

コマンド: cnfdlparm

パラメータ アップグレード用の値
Session Timeout 30000
Request Hop Limit(loadrev に対してのみ適用) 4

コマンド: cnffunc

パラメータ アップグレード用の値
Logging of conn events in local event log disabled
Logging of conn events in CWM (SV+) event log disabled

コマンド: off1/on1

パラメータ アップグレード用の値
Standby Terminal 有効
Line Diag disabled
Conn Stat Sampling disabled

コマンド: コマンド:off2 / on2

パラメータ アップグレード用の値
Statistical Sample (Line Stat Sampling) disabled
Statistical Alarm disabled
Job Ready Checker disabled
Card Statistical Alms disabled
Card Stat Sampling disabled
ASI Port Sampling (Port Stat Sampling) disabled
Robust Updates disabled
Robust Alarm Updates disabled
Realtime Counters disabled
Update Standby Stats disabled
Junction ID disabled

コマンド: cnftstparm

すべてのカード タイプについてセルフ テストとバックグラウンド テストをオフにする

付録 F タスク 27: スタンバイプロセッサのロック解除

この手順を実行すると、アクティブ プロセッサのフラッシュに障害が発生した場合に、ノードを再構築せずにプロセッサ カードの切り替えだけを行います。

  1. 個々のターゲット ノードにログインして、次のコマンドを実行します。

    loadrev x.x.x <node_name>(x.x.x は、ダミーのリビジョン名です)

    x.x.x は存在しないリリースなので、ノードは revision x.x.x を無効と宣言します。 dsprevs コマンドを入力して、これを確認します。

  2. プロセッサ カードの冗長性を無効にするには、CC Redundancy Cnfged パラメータを N に設定します。 cnfnodeparm コマンドを入力して実行します。 この結果、スタンバイ NPC/NPM/BCC のアップデート プロセスが開始されます。

    注: カードがスタンバイ状態になるまで待ちます。

  3. プロセッサ カードの冗長性をもう一度有効にするには、CC Redundancy Cnfged パラメータを Y に設定します。 cnfnodeparm コマンドを入力して実行します。

  4. 次のコマンドで焼き付けプロセスを開始します。

    loadrev <new_revision><node_name>

  5. dspdnld コマンドを発行して、フラッシュの消去が開始されることを確認します。

付録 G: runrev間隔のその他の情報

注: 失敗はネットワーク停止という結果にきちんとネットワークを終る可能性があります監視します。

アップグレード手順で述べられる上でメイン文書 セクションで runrev間隔を使用して下さい。 大規模なネットワークでは、runrevタスクは完了するのに長い 時間をかける可能性があります; 従って、実際に必要とされたら、デフォルト runrev間隔を減少させて下さい。 この間隔を調節するいくつかのガイドラインは下記にあります。 これらのガイドラインは用心深く使用し、ネットワークは厳密に監視する必要があります。

runrevタスク間の安全な間隔は大規模なネットワークがトランキングの National またはインターナショナルおよび次数であるかどうかに左右されます。

シングル スレッド最も大きいノードの runrev 毎に 10-5 分にはじまって各 runrevタスク(最も大きいノードは高頻度のノードの接続識別されます)。 アップグレードが警告 の サインなしで進歩する場合、runrevタスク間の間隔は 1 分間隔低いに次第に減らすことができます。

コマンド dspprfhist、dsplog および dspqs を使用して CPU負荷、ログおよび更新を監視して下さい。 過度 の ネットワーク メッセージングによる到達不能 アラームのような警告 の サインのために監視して下さい。 アイドル時間が dspprfhist と余りに低い(10% 以下)示されている場合アップグレード プロセスを中断し、低いアイドル時間を調査して下さい。 アップグレードを中断するときアイドル時間が正常な値に戻ったら、runrevs 間のより大きい間隔のアップグレードを続行して下さい。

間隔はより少し runrevs 間のより 1 分 dspprfhistdspqs および dsplog を監視すること困難にします。 たとえば各 dspprfhist 間隔は 20 秒であり、下落 傾向のために視聴するために少なくとも 2 つの間隔を監視する必要があります。 従って、1 分以下間隔の runrevs を実行しないで下さい。

コマンド dsptech のディスプレイはスイッチを監視するために簡潔な概要を提供します。

アップグレード手順で既述のとおりに、アップグレード プロセスの間に Cisco WAN Manager をシャットダウンして下さい。 これをしない場合、Gateway ノードをより厳しく監視することを確かめて下さい。

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

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


関連情報


Document ID: 10843