Catalyst 4500 シリーズ スイッチ Cisco IOS ソフトウェア コンフィギュレーション ガイド リリース IOS XE 3.3.0SG および IOS 15.1(1)SG

Stateful Switchover の概要

SSO 機能の展開は、Cisco IOS スイッチで構築されたネットワークのアベイラビリティを向上させる全体的なプログラムの 1 ステップです。

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

アクティブ スーパーバイザ エンジンが故障した場合、またはネットワーキング デバイスから取り外された場合に、アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへのスイッチオーバーが行われます。

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

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

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

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

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

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

NSF の概要

Cisco NSF は、Cisco IOS ソフトウェアの 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 ソフトウェアのアップグレードまたはダウングレードを実行できます。（ISSU プロセスの間に使用されるコマンドのインストレーションについては、図 5-8 を参照してください）。Cisco IOS ISSU は Cisco IOS ハイ アベイラビリティ インフラストラクチャ（Cisco NSF/SSO およびハードウェアの冗長構成）を利用し、システムの稼働中に変更を行えるようにすることによって、ソフトウェア アップグレードまたはバージョン変更に伴うダウンタイムをなくします（ を参照）。

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

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

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

（注） 次の図では、Cisco IOS 12.x(y)S は、Cisco IOS の現行バージョンを表しています。

図 5-4 両方のスーパーバイザ エンジンへの新しい Cisco IOS ソフトウェア バージョンのインストールまたはコピー

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

（注） ISSU 機能がないと、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンが 2 つの異なる Cisco IOS イメージ バージョンを実行している場合に、両者間で SSO または NSF 機能は動作しません。

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

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

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

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

図 5-7 新しくスタンバイになったスーパーバイザ エンジンへの新しい Cisco IOS ソフトウェアのロード

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

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

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 を実行します。

（注） issu changeversion コマンドを使用するには、古い IOS バージョンと新しい IOS バージョンの両方が issu changeversion 機能をサポートする必要があります。

changeversion プロセス

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

加えて、issu changeversion では、将来のアップグレード プロセスをスケジュールすることができます。これにより、いくつものシステムのステージングによって、潜在的な中断が最小の損害となる場合にアップグレードを順次実行することができます。

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

通常の ISSU アップグレード手順と同様に、 issu changeversion コマンドによって開始された進行中のアップグレード手順は、issu abortversion コマンドで中断できます。システムが何らかの問題を検出するか、またはアップグレード中に健全でないシステムを検出すると、アップグレードは自動的に中断される場合があります。

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

Changeversion：quick オプション

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 ソフトウェア イメージを認定し、広くそれを展開する場合は、ネットワークの効率的なアップグレードを実行するために単一コマンドのプロセスを使用できます。

進行中の Changeversion 手順の中断

issu changeversion コマンドの機能は、ユーザの介入なしで ISSU ソフトウェア アップグレードを実行するように設計されています。ただし、さまざまな状態をアップグレードが遷移する際に、コンソールにステータス メッセージが表示されます。何らかの異常が、ネットワークのピアまたは他の部分などでの自動アップグレード中に認められた場合は、issu abortversion コマンドを使用して、commitversion 操作の前にプロセスの任意の時点で手動によりアップグレードを中止できます。

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

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

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

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

（注） これらをイネーブルにすると、コマンドは新しいバージョンだけでサポートされるため、システムは RPR モードを開始します。

• ダウングレードを行う場合、Cisco IOS ソフトウェア ハンドルのダウングレード リビジョンにない機能があったときは、ISSU プロセスを開始する前にその機能をディセーブルにしてください。

ISSU をサポートする Cisco IOS ソフトウェアのバージョニング機能

ISSU が導入される以前は、SSO モードを実行するには、各スーパーバイザ エンジンで同じ Cisco IOS ソフトウェア バージョンを実行する必要がありました。

（注） 冗長 HA 構成のシステムの動作モードは、スタンバイ スーパーバイザ エンジンがアクティブ スーパーバイザ エンジンに登録するときにバージョン ストリングを交換することによって決まります。

システムが SSO モードを開始するのは、両方のスーパーバイザ エンジンで実行されているバージョンが同じである場合だけです。同じでないと、冗長モードが RPR に変更されます。ISSU 機能を使用した場合、この実装では Cisco IOS イメージの 2 つの異なる、しかし互換性のあるリリース レベルを SSO モードで相互動作することで、ソフトウェア アップグレードを実行しながら、パケット転送を継続することができます。ISSU 機能が導入される前に行われていたバージョン チェックでは、システムが動作モードを決定できなくなりました。

ISSU では、ソフトウェア バージョン間の互換性を判別するための追加情報が必要になります。当該イメージと比べた他のイメージに関する情報を含む互換性マトリクスが定義されます。この互換性マトリクスは、2 つのソフトウェア バージョン（1 つは、アクティブ スーパーバイザ エンジンで実行されるソフトウェア バージョンで、もう一方はスタンバイ スーパーバイザ エンジンで実行されるソフトウェア バージョン）の互換性を表し、これによって、システムは実現可能な最も高度な動作モードを判別できます。バージョンに互換性がないと、SSO 動作モードに進むことができません。

互換性マトリクス

アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方の Cisco IOS ソフトウェアが ISSU に対応しており、古いイメージと新しいイメージに互換性がある場合に、ISSU プロセスを実行できます。互換性マトリクス情報では、次のようにリリース間の互換性が示されます。

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

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

ただし、マトリクス エントリが B の場合でも、機能を失うことなく、ISSU アップグレードを実行できる必要があります。ダウングレードでは新しいイメージに追加機能があると、一部の機能が失われることがあります。

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

ISSU をサポートしないピアで ISSU を実行しようとすると、システムは代わりに RPR を自動的に使用します。

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

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

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

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

ISSU に対する SNMP サポート

SSO に対する SNMP は、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンが同じ Cisco IOS ソフトウェア バージョンを実行していることを前提として、SNMP 設定と MIB を同期化するメカニズムを提供し、アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへの SSO をサポートしています。この前提は、ISSU には当てはまりません。

ISSU を使用した場合、SNMP クライアントは必要に応じて、2 つの異なる Cisco IOS バージョン間で MIB の変換を行うことができます。SNMP クライアントはすべての MIB の変換を行い、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジン間の送受信機能を処理します。SNMP の実行時に、両方の Cisco IOS リリースの MIB バージョンが同じである場合にだけ、MIB がアクティブ スーパーバーザ エンジンからスタンバイ スーパーバイザ エンジンに完全に同期化されます。

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

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

• ISSU 対応イメージを選択する

• 対象のイメージと互換性を持つイメージを特定する

• 2 つのイメージを比較し、それらのイメージの互換性レベル（互換性がある、ベースレベルで互換性がある、互換性がない）を把握する

• 2 つのイメージを比較し、各 ISSU クライアントのクライアント互換性を確認する

• イメージのリリース ノートに対するリンクを提供する

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

ISSU プロセスには、5 つのステート（Disabled、Init、Load Version、Run Version、および System Reset）があります。show issu state コマンドを使用すると、現在の ISSU ステートを取得できます。

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

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

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

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

• System Reset（SR）ステート：Init ステートに達する前に issu abortversion コマンドを入力した場合、または issu acceptversion コマンドを実行する前にロールバック タイマーの期限が切れた場合のステート。

ISSU ソフトウェア インストレーションを確認するには、次のように show コマンドを入力します。

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

Switch> enable

Switch# show issu state

Switch# show redundancy

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

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

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

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

アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンがアップおよび ISSU Init ステートで、ブート変数が設定されており、有効なファイルが指定されていることを確認します。

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

新しい Cisco IOS ソフトウェア バージョンが両方のスーパーバイザ エンジンに存在する必要があります。次に、新しいバージョンが存在することを確認するために、それぞれのスーパーバイザ エンジンのディレクトリ情報を表示する例を示します。

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

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

前提条件

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

（注） ISSU が正常に実行されるためには auto-boot をイネーブルにする必要があります。

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

• システム（アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方）が SSO 冗長モードになっていることを確認します。システムが SSO モードではなく、RPR モードである場合、ISSU CLI コマンドを使用してシステムをアップグレードすることはできますが、アップグレード中にシステムが大量のパケットを損失します。

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

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

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

次に、ISSU プロセスを開始し、スタンバイ スーパーバイザ エンジンを Standby Hot ステートで起動し、スタンバイ スーパーバイザ エンジン（スロット 2）に新しいイメージをロードする例を示します。

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

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

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

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

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

次に、スタンバイだったスーパーバイザ エンジン（スロット 2）へのスイッチオーバーを発生させ、アクティブだったスーパーバイザ エンジンをリセットしたうえで古いイメージをリロードしてスタンバイ スーパーバイザ エンジンにする例を示します。

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

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

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

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

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

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

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

• スイッチを長時間この状態で維持する場合は、ロールバック タイマーを停止する必要があります（その後、確認して、直接 acceptversion コマンドを実行します）。

• 45 分間のロールバック タイマー時間内に次のステップ（「commitversion」を実行）に進む場合は、ロールバック タイマーを停止する必要はありません。

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

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

新しくスタンバイになったスーパーバイザ エンジンへの新しい Cisco IOS ソフトウェアのロード

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

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

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

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

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

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

前提条件

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

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

• システム（アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンの両方）が SSO 冗長モードになっていることを確認します。システムが RPR モードである場合、ISSU CLI コマンドを使用してシステムをアップグレードすることはできますが、アップグレード中にシステムが大量のパケットを損失します。

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

• 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 プロセスは自動的に中断します。

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

issu loadversion コマンドを入力した後にプロセスを打ち切ると、スタンバイ スーパーバイザ エンジンがリセットされ、元のソフトウェアがリロードされます。

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

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

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

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

次に、スロット番号 2（現在アクティブなスーパーバイザ エンジンのスロット）の ISSU プロセスを中断する例を示します。

Switch> enable

Switch# issu abortversion 2

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

Cisco IOS ソフトウェアは、新しくアクティブになったスーパーバイザ エンジンとスタンバイ スーパーバイザ エンジンとの通信がアップグレードによって、切断された状態になるのを回避するために、ISSU ロールバック タイマーを維持します。

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

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

ISSU プロセスが正常に行われていることに満足し、現在の状態を保つ場合は、 issu acceptversion コマンドを入力することにより、承諾したことを示す必要があります。これにより、ロールバック タイマーが停止します。 issu acceptversion コマンドを入力することは、ISSU プロセスを進めるうえで非常に重要です。

この段階で 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

次の例で示すように、ロールバック タイマーを LV ステートで設定することはできません。

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

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

ISSU 互換性マトリクスに関する情報を表示するには、次の作業を行います。

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

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

Dynamic(0) が Dynamic Image Version Compatibility（DIVC）機能付きの Cisco IOS Release 12.2(50) SG で導入されました。DIVC では、Incomp(1)、Base(2)、または Comp(3) ではなく Dynamic(0) が保存されます。互換性は、2 の異なる DIVC 対応イメージが ISSU 時にアクティブ スーパーバイザ エンジンおよびスタンバイ スーパーバイザ エンジン上で実行されているときのランタイム時に決定されます。

Catalyst 4500 スイッチでは、保存された互換性マトリクスの値 Dynamic(0) は通常、2 つのイメージ間のロール バック ネゴシエーション時に、Base(2) または Comp(3) になります。保存された互換性マトリクスに他のイメージ名があるかぎり、Incomp(1) は確認できません。

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

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

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

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

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

Dynamic Image Version Compatibility（DIVC）では、Incomp(1)、Base(2)、または Comp(3) ではなく Dynamic(0) が保存されます。互換性は、2 の異なる DIVC 対応イメージが ISSU 時にアクティブ スーパーバイザ エンジンおよびスタンバイ スーパーバイザ エンジン上で実行されているときのランタイム時に決定されます。

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

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