Catalyst 4500 シリーズ　スイッチ Cisco IOS ソフトウェアコンフィギュレーションガイド リリース IOS-XE 3.1.0 SG

関連資料

Stateful Switchover

SSO 機能の開発は、Cisco IOS XE スイッチで構成されたネットワークの可用性を向上させるプログラム全体の 1 ステップに過ぎません。

デュアル スーパーバイザ エンジンをサポートする特定のシスコ ネットワーキング デバイス上で、SSO はスーパーバイザ エンジンの冗長構成を活用してネットワークのアベイラビリティを向上させます。SSO は、スーパーバイザ エンジンの 1 つをアクティブ プロセッサ、もう一方をスタンバイ プロセッサとして設定することにより、これを実現します。2 つのスーパーバイザ エンジン間の初期同期後に、SSO は両方のスーパーバイザ エンジンのステート情報を動的にリアルタイムで同期化します。

アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへのスイッチオーバーは、アクティブ スーパーバイザ エンジンが故障するか、ネットワーキング デバイスから取り除かれたときに発生します。

Cisco NSF は、SSO と併用します。Cisco NSF によって、スイッチオーバー後にルーティング プロトコル情報が復元される間、データ パケットの転送が既知のルートで続行されます。Cisco NSF を使用すると、ピア ネットワーキング デバイスでルーティング フラップが発生することがなくなるため、カスタマーに対するサービス停止を回避できます。

図 6-1 は、サービス プロバイダー ネットワークに SSO が展開される一般的な方法を示します。この例では、CiscoNSF/SSO がサービス プロバイダー ネットワークのアクセス レイヤ（エッジ）でイネーブルにされています。このポイントで障害が発生すると、サービス プロバイダー ネットワークへのアクセスが必要なエンタープライズ カスタマーのサービスを損なう可能性があります。

隣接デバイスが Cisco NSF に参加している必要がある Cisco NSF プロトコルでは、このようなネイバー ディストリビューション レイヤ デバイス上に Cisco NSF 認識ソフトウェア イメージをインストールする必要があります。目的に応じて、ネットワークのコア レイヤで Cisco NSF および SSO 機能を展開することもできます。これを行うと、特定の障害が発生した場合のネットワーク機能およびサービスの復元に必要な時間を短縮できるため、可用性が向上します。

図 6-1 Cisco NSF/SSO ネットワーク構成：サービス プロバイダー ネットワーク

アベイラビリティの向上は、シングル ポイント障害が存在するネットワーク内の他のポイントに Cisco NSF/SSO を展開することによって得られます。図 6-2 は、エンタープライズ ネットワーク アクセス レイヤに Cisco NSF/SSO を適用するもう 1 つの展開方法を示します。この例では、エンタープライズ ネットワーク内の各アクセス ポイントが、ネットワーク設計内の他のシングル ポイント障害を表します。この例では、スイッチオーバーまたは計画されたソフトウェア アップグレードが行われても、エンタープライズ カスタマー セッションは中断することなくネットワーク内で稼動し続けます。

図 6-2 Cisco NSF/SSO ネットワーク構成：エンタープライズ ネットワーク

SSO の詳細については、『Stateful Switchover』を参照してください。

NSF

Cisco NSF は、Cisco IOS XE ソフトウェアの SSO 機能と連動します。SSO は、Cisco NSF の前提条件です。NSF は、SSO と連動して、スイッチオーバー後にユーザがネットワークを使用できない時間を最小限に抑えます。Cisco NSF の主要目的は、スーパーバイザ エンジンのスイッチオーバー後にも IP パケットの転送を継続させることです。

通常、ネットワーク デバイスが再起動すると、そのデバイスのすべてのルーティング ピアは、デバイスがダウンし、そのあと再びアップになったことを検知します。このような移行によって、いわゆるルーティング フラップが発生します。ルーティング フラップは、複数のルーティング ドメインに広がる場合があります。ルーティングの再起動によって発生するルーティング フラップは、ルーティング動作を不安定にし、ネットワーク全体のパフォーマンスに悪影響を及ぼします。Cisco NSF は、SSO 対応のデバイスにおけるルーティング フラップを抑止することによって、ネットワークの安定性を保ちます。

Cisco NSF によって、スイッチオーバー後にルーティング プロトコル情報が復元される間、データのパケットの転送が既知のルートで続行されます。Cisco NSF を使用すると、ピア ネットワーキング デバイスでルーティング フラップが発生することがありません。スイッチオーバー時に、故障したアクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンが制御を引き継ぐ間も、データ トラフィックが転送されます。Cisco NSF 動作で重要なのは、スイッチオーバー時に物理リンクがアップの状態を維持できる点と、アクティブ スーパーバイザ エンジン上の Forwarding Information Base（FIB; 転送情報ベース）との同期性が保たれる点です。

ISSU プロセス

ISSU プロセスを使用すれば、システムによるパケット転送を中断することなく、Cisco IOS XE ソフトウェアのアップグレードまたはダウングレードを実行することができます（ISSU プロセス中に使用されるコマンドのイラストについては、図 6-8 を参照してください）。Cisco IOS XE ISSU は Cisco IOS XE ハイ アベイラビリティ インフラストラクチャ（Cisco NSF/SSO およびハードウェアの冗長構成）を利用し、システムの稼動中に変更ができるようにすることによって、ソフトウェアのアップグレードに伴うダウンタイムをなくします（ を参照）。

SSO/NSF モードは、アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへの設定とランタイム ステートの同期をサポートしています。このプロセスでは、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方の IOS XE ソフトウェア イメージを同じにする必要があります。アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンのイメージが異なる場合は、その 2 つのバージョンの Cisco IOS XE が別々の機能とコマンドのセットをサポートしていても、ISSU によって 2 つのスーパーバイザ エンジンの同期を維持することができます。

図 6-3 ISSU プロセスでのハイ アベイラビリティ機能およびハードウェアの冗長構成

ISSU 対応スイッチは、2 つのスーパーバイザ エンジン（アクティブとスタンバイ）と 200 以上のラインカードで構成されています。ISSU プロセスを開始する前に、両方のスーパーバイザ エンジンのファイル システムに Cisco IOS XE ソフトウェアをコピーします（図 6-4 を参照）。

（注） 下の図で、Cisco IOS XE 3.x.y SG は現行バージョンを示し、Cisco IOS XE 3.z.y SG は移行するイメージを示しています。

図 6-4 両方のスーパーバイザ エンジン上での新しいバージョンの Cisco IOS XE ソフトウェアのコピー

両方のファイル システムに Cisco IOS XE ソフトウェアをコピーしたら、新しいバージョンの Cisco IOS XE ソフトウェアをスタンバイ スーパーバイザ エンジンにロードします（図 6-5 を参照）。

（注） ISSU 機能がないと、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンで異なるバージョンの Cisco IOS XE イメージが動作している場合に、それらのスーパーバイザ エンジン間で SSO/NSF が機能しません。

図 6-5 スタンバイ スーパーバイザ エンジン上での新しいバージョンの Cisco IOS XE ソフトウェアのロード

スイッチオーバー（Route Processor Redundancy（RPR）ではなく、NSF/SSO）のあと、スタンバイ スーパーバイザ エンジンが新しくアクティブになったスーパーバイザ エンジンとして機能を引き継ぎます（ を参照）。

図 6-6 スタンバイ スーパーバイザ エンジンへのスイッチオーバー

以前のアクティブ スーパーバイザ エンジンに古い Cisco IOS XE イメージがロードされているため、新しいアクティブ スーパーバイザ エンジンで問題が発生した場合は、中断して、古いソフトウェア イメージを実行している以前のアクティブ スーパーバイザ エンジンへのスイッチオーバーを実行することができます。その後で、以前のアクティブ スーパーバイザ エンジンに新しいバージョンの Cisco IOS XE ソフトウェアをロードして、新しいスタンバイ スーパーバイザ エンジンにします（ を参照）。

図 6-7 新しいスタンバイ スーパーバイザ エンジンへの新しい Cisco IOS XE ソフトウェアのロード

に、ISSU プロセス中の各ステップを示します。

図 6-8 ISSU プロセス中の各ステップ

（注） Accept version は、ロールバック タイマーを停止します。

ISSU アップグレードの実行：2 つの方法

ISSU のアップグレード方法には、4 つのコマンドを使用した手動方式と 1 つのコマンドを使用した自動方式の 2 種類があります。

通常の ISSU アップグレード プロセスには、4 種類の ISSU exec コマンド
（issu loadversion、issu runversion、issu acceptversion、issue commitversion）の発行とコマンドが成功したかどうかを評価するための追加の show コマンドの実行が含まれます。ISSU プロセスは複雑ですが、サービスの中断を想定しないようにする必要があります。複数の ISSU コマンドを使用する場合は、サービスを中断させないように配慮する必要があります。ただし、シナリオによっては、このアップグレード手順がややこしく、最小限のものになる場合があります。代表例は、多数の Catalyst 4500 スイッチ上での ISSU アップグレードを伴うネットワーク アップグレードです。このような場合は、最初に、1 台のスイッチ上で通常（4 つのコマンド）の ISSU アップグレード手順を実行して正常なアップグレードを確認することを推奨します。その後で、1 つの issu changeversion コマンドを使用して、ネットワーク内の残りの Catalyst 4500 スイッチ上で自動 ISSU を実行します。

changeversion プロセス

issu changeversion コマンドは、1 ステップで完了する ISSU アップグレード サイクルを起動します。このコマンドは、4 つの標準コマンド（issu loadversion、issu runversion、issu acceptversion、および issu commitversion）すべてのロジックをユーザの介在なしで実行するため、単一の CLI ステップを通したアップグレードの簡略化が図られます。

加えて、issu changeversion では、将来のアップグレード プロセスをスケジュールすることができます。これにより、中断による被害が最小限のときに複数のシステムのアップグレードを連続的に実行するようにステージングすることができます。

スタンバイ スーパーバイザ エンジンが初期化して、システムが terminal 状態（RPR/SSO）に到達したら、アップグレード プロセスが完了し、BOOT 変数が新しい IOS XE ソフトウェア イメージに恒久的に書き変えられます。そのため、どの RP をリセットしてもシステムは新しいソフトウェア イメージをブートします。状態遷移が起きたことをアップグレードのモニタ者に通知するために、コンソール メッセージと syslog メッセージが生成されます。

通常の ISSU アップグレード手順と同様に、issu changeversion コマンドで開始されたインプロセス アップグレード手順は issu abortversion コマンドで中止することができます。アップグレード中にシステムで何らかの問題が検出されたり、システム異常が検出されたりした場合は、アップグレードが自動的に中止されます。

4 ステップ手動アップグレード プロセス中に issu runversion コマンドを入力したときに、互換性のない ISSU クライアントが存在した場合は、アップグレード プロセスからその内容と副作用が報告されるため、ユーザがアップグレードを中止することができます。1 ステップ アップグレード プロセスの実行中に、プロセスが runversion ステートに到達すると、ベース クライアントに互換性があれば自動的にアップグレードを継続し、クライアントに互換性がなければ自動的にアップグレードを中止します。ユーザが RPR モードでアップグレード手順を継続したい場合は、通常の ISSU コマンド セットを使用して、issu loadversion コマンドの入力時に force オプションを指定する必要があります。

Changeversion：Quick オプション（LV から INIT まで）

issu changeversion コマンドには、自動 ISSU アップグレードの実行に必要な時間を短縮可能な quick コマンド オプションがあります。quick コマンド オプションが指定された場合は、ISSU アップグレードの状態遷移が前述の状態遷移と異なります。このオプションを使用した場合は、loadversion ステージまでのソフトウェア ロジックは前述と同じですが、runversion と commitversion を実行するロジックが結合されます。このロジックでは、新しいスタンバイ（以前のアクティブ）スーパーバイザ上に古いソフトウェア バージョンをロードするアップグレード手順内のステップが省略されるため、自動 ISSU アップグレードに必要な時間が約 3 分の 1 短縮されます。

Changeversion のスケジューリング：in オプションと at オプション

issu changeversion には、将来の自動 ISSU アップグレードをスケジュール可能な in コマンド オプションと at コマンド オプションがあります。

at コマンド オプションは、特定の時刻に自動 ISSU アップグレードを開始するようにスケジュールします。このオプションを使用して、次の 24 時間以内にアップグレードを開始する正確な時刻（hh:mm、24 時間形式）を指定します。

in コマンド オプションは、一定時間が経過後に自動 ISSU アップグレードを開始するようにスケジュールします。このオプションを使用して、アップグレード開始までの時間数と分数（hh:mm 形式）を指定します。最大値は 99:59 です。

Changeversion 展開シナリオ

issu changeversion コマンドの代表的な使用シナリオは、大規模な設置基盤を有する経験豊富なユーザ向けです。このようなユーザの多くは、実稼動ネットワークと同様のトポロジと設定を使用して新しいイメージを検証します。この検証プロセスは、従来の複数コマンド プロセスと新しい issu changeversion コマンド プロセスの両方を使用して実行する必要があります。ユーザが IOS XE ソフトウェア イメージを認定して本格展開する段階では、単一コマンド プロセスを使用して、効率的にネットワークをアップグレードすることができます。

インプロセス Changeversion 手順の中止

issu changeversion コマンドの機能は、ユーザの介在なしで ISSU ソフトウェア アップグレードを実行するように設計されています。ただし、アップグレードはさまざまなステートを移動するため、コンソールに数多くのステータス メッセージが表示されます。自動アップグレード中にピアまたはその他のネットワーク要素から何らかの異常が通知された場合は、commitversion 処理の前に issu abortversion コマンドを使用してプロセス内の任意の時点でアップグレードを手動で中止することができます。

ISSU の実行に関するガイドライン

ISSU プロセスの実行中は、次のガイドラインに注意してください。

• ISSU を使用している場合でも、メンテナンス ウィンドウの間にアップグレードを実行することを推奨します。

• ISSU プロセス中は、設定の変更が必要になるような新しい機能をイネーブルにしないでください。

（注） このような新しい機能をイネーブルにした場合は、コマンドが新しいバージョンでしかサポートされないため、システムが RPR モードに遷移します。

• ダウングレード シナリオでは、Cisco IOS XE ソフトウェア ハンドルのダウングレード リビジョンで使用できない機能があった場合に、ISSU プロセスの開始前にその機能をディセーブルにする必要があります。

互換性マトリクス

ISSU では、ソフトウェア バージョン間の互換性を判別するための追加情報が必要になります。そのため、互換性マトリクスは、他の IOS XE ソフトウェア イメージとの問題に関する情報を含むように定義されます。

この互換性マトリクスは、2 つのソフトウェア バージョン（1 つは、アクティブ スーパーバイザ エンジンで実行されるソフトウェア バージョンで、もう一方はスタンバイ スーパーバイザ エンジンで実行されるソフトウェア バージョン）の互換性を表し、これによって、システムは実現可能な最も高度な動作モードを判別できます。バージョンに互換性がないと、SSO 動作モードに進むことができません。

互換性マトリクスは、ある Cisco IOS XE ソフトウェア イメージと、指定されたサポート ウィンドウに含まれる他のすべての Cisco IOS XE ソフトウェア バージョン（たとえば、その IOS XE ソフトウェア イメージが「認識」しているすべてのソフトウェア バージョン）との互換性関係を示し、IOS XE ソフトウェア イメージごとに作成され、リリースされます。マトリクスには、自身のリリースと以前のリリース間の互換性の情報が含まれています。常に最新のリリースに、その分野の既存のリリースとの互換性に関する最新情報が含まれます。互換性マトリクスは、Cisco IOS XE ソフトウェア イメージや Cisco.com から入手可能なため、ISSU プロセスを使用してアップグレードを実行できるかどうかを事前に判断することができます。

古い Cisco IOS XE ソフトウェアと新しい Cisco IOS XE ソフトウェアに互換性があれば、ISSU プロセスを実行することができます。互換性マトリクス情報では、次のようにリリース間の互換性が示されます。

• Compatible（互換性がある）：ベースレベルのシステム インフラストラクチャとすべてのオプションの HA 認識サブシステムに互換性があります。これらのバージョン間のインサービス アップグレードまたはダウングレードが行われても、サービスに対する影響は最小限ですみます。マトリクス エントリでは、このようなイメージに対して Compatible（C）が指定されます。

• Base-level compatible（ベースレベルで互換性がある）：1 つまたは複数のオプションの HA 認識サブシステムに互換性がありません。これらのバージョン間のインサービス アップグレードまたはダウングレードは正常に行われますが、サブシステムによっては、Cisco IOS XE の古いバージョンから新しいバージョンへの移行中のステートを維持できない場合があります。マトリクス エントリでは、このようなイメージに対して Base-level compatible（B）が指定されます。

• Incompatible（互換性がない）：SSO が正常に機能するステートフルな方法で相互運用が可能なシステム インフラストラクチャのコア セットが Cisco IOS XE 内に存在する必要があります。これらの必要な機能またはサブシステムのいずれかが相互運用できない場合は、Cisco IOS XE ソフトウェア イメージの 2 つのバージョンに互換性がないと判断されます。これらのバージョン間でインサービス アップグレードまたはダウングレードを行うことはできません。マトリクス エントリでは、このようなイメージに対して Incompatible（I）が指定されます。アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの Cisco IOS XE のバージョンに互換性がない場合は、システムがアップグレード プロセス中に RPR モードで動作します。

• Cisco IOS XE は、STANDBY の起動中に、アクティブ IOS XE ソフトウェアとスタンバイ IOS XE ソフトウェアの互換性を動的に判断します。マトリクスは "x" で表されます。

任意のシステムの 2 つのソフトウェア バージョン間の互換性マトリクス データを表示するには、show issu comp-matrix stored コマンドを入力します。

（注） このコマンドは、ISSU プロセスが開始したあとにだけ使用できるので、確認する場合にだけ有効です。ISSU を開始する前に互換性マトリクスをチェックする場合に便利です。Feature Navigator を使用すると、必要な情報を取得できます。

http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

ISSU に対する SNMP サポート

SNMP for SSO は、SNMP 設定と、アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへの SSO をサポートする MIB を同期させるメカニズムを提供します。

Cisco Feature Navigator を使用した互換性の検証

Cisco Feature Navigator の ISSU アプリケーションでは、次の内容を実行することができます。

• 特定のソフトウェア バンドルを選択します。

• 選択したソフトウェア イメージと互換性のあるソフトウェア イメージを特定します。

• 2 つの IOS XE ソフトウェア イメージを比較して、ソフトウェア イメージの互換性レベル（つまり、compatible、base-level compatible、および incompatible）を把握します。または、動的に決定されます。

• 2 つのソフトウェア イメージを比較して、ISSU クライアントごとの互換性を確認します。

• ソフトウェア イメージに関するリリース ノートへのリンクを入力します。

ISSU ソフトウェア インストレーションの確認

ISSU プロセスには、5 つの有効なステート（disabled、init、load version、run version、および system reset）があります。show issu state コマンドを使用すると、現在の ISSU ステートを取得できます。

• Disabled ステート：エンジンがリセットされている間のスタンバイ スーパーバイザ エンジンの状態

• init ステート：ISSU プロセスが開始する前の、2 つのスーパーバイザ エンジン（アクティブとスタンバイ）の初期ステート。ISSU プロセスが完了したあとの最終ステートでもある。

• Load Version（LV）ステート： スタンバイ スーパーバイザ エンジンに新しいバージョンの Cisco IOS XE ソフトウェアがロードされます。

• Run Version（RV）ステート：issu runversion コマンドによって、スーパーバイザ エンジンのスイッチオーバーが強制されるステート。新しいアクティブ スーパーバイザ エンジンが新しい Cisco IOS XE ソフトウェア イメージを実行します。

• ISSU の実行中に停電などで両方のスーパーバイザ エンジンがリセットされた場合は、ISSU コンテキストが失われ、init ステートに戻ります。両方のスーパーバイザ エンジンが古いソフトウェアに戻ります。

show コマンドを入力して、ISSU プロセス中のステートに関する情報を表示することによって、ISSU ソフトウェア アップグレードを確認することができます。

次に、ISSU プロセス中のスーパーバイザ エンジンのステートと現在のステータスを表示する例を示します。

Switch> enable

Switch# show issu state

Switch# show redundancy

ISSU プロセスを開始する前の冗長モードの確認

ISSU プロセスを開始する前に、システムの冗長モードを確認して、NSF/SSO を必ず設定するようにしてください。

次に、システムが SSO モードを開始しており、スロット 3 がアクティブ スーパーバイザ エンジンで、スロット 4 がスタンバイ スーパーバイザ エンジンであることを確認する例を示します。両方のスーパーバイザ エンジンが同じ Cisco IOS XE ソフトウェア リリースを実行しています。

ISSU プロセスを開始する前の ISSU ステートの確認

アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンがアップして ISSU Init ステートになっており、両方のスーパーバイザ エンジンが同じ最新イメージを実行していることを確認します。

次に、プロセスが開始する前に ISSU ステートを表示する例を示します。

新しいバージョンの Cisco IOS XE ソフトウェアが両方のスーパーバイザ エンジン上に存在する必要があります。スーパーバイザ エンジンごとに表示されるディレクトリ情報に新しいバージョンが存在することが示されます。

スタンバイ スーパーバイザ エンジン上での新しい Cisco IOS XE ソフトウェアのロード

ここでは、ISSU を使用して、スタンバイ スーパーバイザ エンジンに新しいバージョンの Cisco IOS XE ソフトウェアをロードする方法について説明します。

前提条件

• 新しいバージョンの Cisco IOS XE ソフトウェア イメージが、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方のファイル システムにすでに存在することを確認します。また、適切なブート パラメータ（BOOT 文字列と設定レジスタ）が、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンに設定されていることを確認します。

• （任意）追加のテストおよびコマンドを実行して、あとで比較するために必要なピアおよびインターフェイスの現在のステートを判別します。

• システム（アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方）が SSO 冗長モードになっていることを確認します。システムが RPR モードになっていても、ISSU CLI コマンドを使用してシステムをアップグレードすることができますが、アップグレード中に失われるパケット数が増える可能性があります。

スーパーバイザ エンジンに SSO モードを設定する方法の詳細については、『 Stateful Switchover 』を参照してください。

• ISSU が機能するためには、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジン上の IOS XE ファイル名が一致する必要があります。

アクティブ スーパーバイザ エンジンで次の手順を実行します。

次に、ISSU プロセスを開始して、スタンバイ スーパーバイザ エンジンを STANDBY HOT ステートで起動し、スタンバイ スーパーバイザ エンジン スロット（6）に新しい IOS XE ソフトウェア イメージをロードする例を示します。

次に、forced オプションによってシステムが RPR モードに移行する例を示します。

次に、冗長モードが RPR として表示される例を示します。

スタンバイ スーパーバイザ エンジンへの切り替え

この作業では、新しい Cisco IOS XE ソフトウェア イメージを実行しているスタンバイ スーパーバイザ エンジンへのスイッチオーバー方法について説明します。アクティブ スーパーバイザ エンジンで次の手順を実行します。

次に、以前のスタンバイ スーパーバイザ エンジン（スロット 6）へのスイッチオーバーを起動して、以前のアクティブ スーパーバイザ エンジンをリセットしたうえで古い IOS XE ソフトウェア イメージをリロードしてスタンバイ スーパーバイザ エンジンにする例を示します。

この時点でスイッチオーバーが発生します。古いアクティブ スーパーバイザ エンジンがスタンバイになってから、新しいアクティブ スーパーバイザ エンジン上で次の命令を実行します。

（注） 新しくアクティブになったスーパーバイザ エンジンは現在新しいソフトウェア バージョンを実行し、スタンバイ スーパーバイザ エンジンは古いソフトウェア バージョンを実行し、STANDBY HOT ステートの状態です。

runversion が完了すると、新しくアクティブになったスーパーバイザ エンジンが新しいソフトウェア バージョンを実行し、アクティブだったスーパーバイザ エンジンがスタンバイ スーパーバイザ エンジンになります。スタンバイがリセットされたうえでリロードされますが、以前のソフトウェア バージョンのまま、STANDBY HOT ステータスでオンラインに戻ります。次に、これらの状態を確認する例を示します。

ISSU ロールバック タイマーの停止（任意）

ここでは、ロールバック タイマーを停止する方法について説明します。これは、任意で行う操作です。

ロールバック タイマーがタイムアウトするまで次の手順を実行しなかった場合は、自動的に ISSU プロセスが中止され、元の Cisco IOS XE ソフトウェア バージョンに戻されます。デフォルトのロールバック タイマーは 45 分です。

行う必要がある操作は、次のように判断します。

• スイッチを長時間 runversion ステートにしておく場合は、acceptversion コマンドを入力して、ロールバック タイマーを停止する必要があります。その後で、新しいソフトウェアを確認して、commitversion コマンドを入力します（以降のセクションを参照）。

• 45 分間のロールバック タイマー ウィンドウ（または設定された値）内で commitversion 処理に進む場合は、acceptversion コマンドを使用して、ロールバック タイマーを停止する必要がありません。

（注） issu runversion コマンドのあと、任意で issu acceptversion コマンドを実行することができます。

次に、停止する前のタイマーを表示する例を示します。次の例では、「Automatic Rollback Time」情報に、自動ロールバックが行われるまでの時間が示されています。

新しいスタンバイ スーパーバイザ エンジン上での新しい Cisco IOS XE ソフトウェアのロード

ここでは、新しいスタンバイ スーパーバイザ エンジンに新しいバージョンの Cisco IOS XE ソフトウェアをロードする方法について説明します。

アクティブ スーパーバイザ エンジンで次の手順を実行します。

次に、現在のスタンバイ スーパーバイザ エンジン（スロット 1）をリセットして、新しい Cisco IOS XE ソフトウェア バージョンをリロードする例を示します。commitversion コマンドを入力すると、スタンバイ スーパーバイザ エンジンが STANDBY HOT ステートで起動します。

次の命令を使用して、スタンバイ スーパーバイザ エンジンに新しいソフトウェアがリロードされていることを確認します。

ISSU プロセスが完了しました。この段階で、さらに Cisco IOS XE ソフトウェア バージョンのアップグレードまたはダウングレードを行うには、新しい ISSU プロセスの起動が必要になります。

changeversion を使用した ISSU アップグレードの自動化

ここでは、issu changeversion コマンドを使用して 1 ステップ ISSU アップグレードを実行する方法について説明します。

前提条件

• 新しいバージョンの Cisco IOS XE ソフトウェア イメージが、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方のファイル システムにすでに存在することを確認します。また、適切なブート パラメータ（BOOT 文字列と設定レジスタ）が、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンに設定されていることを確認します。

• （任意）追加のテストおよびコマンドを実行して、あとで比較するために必要なピアおよびインターフェイスの現在のステートを判別します。

• システム（アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方）が SSO 冗長モードになっていることを確認します。システムが RPR モードになっていても、ISSU CLI コマンドを使用してシステムをアップグレードすることができますが、アップグレード中に失われるパケット数が増える可能性があります。

スーパーバイザ エンジン上で SSO モードを設定する方法については、ステートフル スイッチオーバーに関するマニュアルを参照してください（ 第 5 章「RPR および SSO を使用したスーパーバイザ エンジンの冗長設定」 を参照）。

• ISSU が機能するためには、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジン上の IOS XE ソフトウェア イメージのファイル名が一致する必要があります。

アクティブ スーパーバイザ エンジンで次の手順を実行します。

次に、現在のアクティブ スーパーバイザ エンジン用のスロットであるスロット番号 5 で issu changeversion コマンドを使用して ISSU アップグレード プロセスを開始する例を示します。show issu state detail コマンドと show redundancy コマンドの出力が含まれており、アップグレード手順前後のスーパーバイザ ステートが確認できます。

（注） 下の出力に含まれている成功メッセージは遅れて表示されます。これは、ISSU アップグレード手順が ISSU ステートで進行するためです。

（注） スタンバイにターゲット イメージがリロードされます。

（注） スイッチオーバーが発生します。

「新しい」アクティブ スーパーバイザ エンジンのコンソールを確認します。

（注） 「新しい」スタンバイにターゲット イメージがリロードされます。SSO terminal ステートに到達した段階で changeversion が完了します。

次に、at コマンド オプション付きの issu changeversion を使用して、指定した時刻に ISSU アップグレード手順が自動的に開始されるようにスケジュールする例を示します。この例では、ISSU アップグレードが 16:30（24 時間形式）に開始するように指定します。show issu state detail コマンドと show redundancy コマンドの出力が含まれており、issu changeversion コマンドの入力前後のスーパーバイザ ステートが確認できます。

ISSU プロセス中のソフトウェア アップグレードの中断

issu abortversion コマンドを入力して、どの段階においても手動で ISSU プロセスを中断できます（issu commitversion コマンドを入力する前）。自動 ISSU アップグレードが進行中に issu changeversion コマンドを入力すると、issu abortversion コマンドも発行されます。また、ソフトウェアによる障害の検知によっても、ISSU プロセスは自動的に中断します。

（注） スタンバイ スーパーバイザ エンジンが Standby Hot ステートに移行する前に、issu abortversion コマンドを発行すると、トラフィックが中断する可能性があります。

issu loadversion コマンドを発行したあとにプロセスを手動で中断した場合、スタンバイ スーパーバイザ エンジンがリセットされ、元のソフトウェアがリロードされます。

issu runversion または issu acceptversion コマンドのいずれかを入力したあとにプロセスが中断された場合は、元のソフトウェア バージョンを引き続き実行している新しいスタンバイ スーパーバイザ エンジンで 2 回めのスイッチオーバーが実行されます。新しいソフトウェアを実行していたスーパーバイザ エンジンがリセットされ、元のソフトウェア バージョンがリロードされます。

（注） アクティブ スーパーバイザ エンジン上で abortversion コマンドを発行する前に、スタンバイ スーパーバイザ エンジンが完全にブートしていることを確認します。

ここでは、 issu commitversion コマンドを使用して ISSU プロセスを完了する前に、ISSU プロセスを中断する方法について説明します。

アクティブ スーパーバイザ エンジンで次の作業を実行します。

次に、現在のアクティブ スーパーバイザ エンジン用のスロットであるスロット番号 6 で ISSU プロセスを中止する例を示します。この例では、issu abortversion コマンドが入力された時点で ISSU アップグレード プロセスが Runversion ステートに入ります。

アップグレード問題を回避するためのロールバック タイマーの設定

Cisco IOS XE ソフトウェアは、アップグレードによって、新しいアクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジン間の通信が途絶えるのを避けるために、ISSU ロールバック タイマーを維持します。

新しいソフトウェアがコミットされていない場合、または Run Version モード中にスイッチへの接続が失われた場合にユーザが待つ必要がないように、ロールバック タイマーを 45 分（デフォルト）以内に設定することもできます。新しい Cisco IOS XE ソフトウェア イメージをコミットする前に、その動作確認に十分な時間が必要な場合は、ロールバック タイマーを 45 分より長く設定することもできます。

（注） 有効なタイマー値の範囲は、0 ～ 7200 秒（2 時間）です。0 秒の値を設定すると、ロールバック タイマーはディセーブルになります。

アクティブ スーパーバイザ エンジン上で新しいイメージが正常に動作していることに満足し、この状態を維持したい場合は、 issu acceptversion コマンドを発行してロールバック タイマーを停止することによって、受け入れを示すことができます。

この段階で issu commitversion コマンドを実行することは、 issu acceptversion コマンドと issu commitversion コマンドの両方を入力することと同じです。現在の状態で一定期間実行しない予定で、新しいソフトウェア バージョンに満足している場合は、 issu commitversion コマンドを使用します。

（注） ロールバック タイマーは、ISSU の Init ステートでだけ設定できます。

ここでは、ロールバック タイマーを設定する方法について説明します。

次に、ロールバック タイマーを 3600 秒に設定する例を示します。

Switch> enable

Switch# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Switch(config)# issu set rollback-timer 3600

% Rollback timer value set to [ 3600 ] seconds

Switch(config)# exit

Switch# show issu rollback-timer

Rollback Process State = Not in progress

Configured Rollback Time = 60:00

次の例で示すように、ロールバック タイマーは loadversion または runversion ステートで設定できません。

ISSU 互換性マトリクス情報の表示

ISSU 互換性マトリクスには、他の IOS XE ソフトウェア リリースに関する情報と問題のあるバージョンが含まれています。この互換性マトリクスには、2 つのソフトウェア バージョン（1 つは、アクティブ スーパーバイザ エンジンで実行されるソフトウェア バージョンで、もう一方はスタンバイ スーパーバイザ エンジンで実行されるソフトウェア バージョン）の互換性が示され、これによって、システムは実現可能な最も高度な動作モードを判別できます。この情報は、ユーザが ISSU を使用するかどうかを判断する場合にも役立ちます。

ここでは、ISSU 互換性マトリクスに関する情報を表示する方法を示します。

次に、ネゴシエートされた互換性マトリクスに関する情報を表示する例を示します。

次に、保存された互換性マトリクスに関する情報を表示する例を示します。

Dynamic Image Version Compatibility（DIVC）機能が IOS XE リリースでサポートされています。DIVC を使用すれば、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンで ISSU 中に 2 種類の DIVC 対応 IOS XE ソフトウェア イメージが動作している場合に、Incomp(1)、Base(2)、または Comp(3) ではなく、Dynamic(0) を保存して、互換性をランタイム中に判断することができます。

Catalyst 4500 スイッチの場合は、通常、保存された互換性マトリクス内の Dynamic(0) の値が、2 つの IOS XE ソフトウェア イメージ間のランタイム ネゴシエーション時に Base(2) または Comp(3) になります。現時点で、保存された互換性マトリクス内に他の IOS XE 名が存在するかぎり、Incomp(1) が出現することはありません。

次に、ネゴシエートされた非 IOSd クライアントに関する情報を表示する例を示します。

ISSU（IOS In-Service Software Upgrade）

http://www.cisco.com/en/US/docs/ios/ha/configuration/guide/ha-inserv_updg.html

拡張高システム可用性

http://www.cisco.com/en/US/docs/ios/ha/configuration/guide/ha-stfl_swovr.html