スーパーバイザ エンジンの冗長構成について
ここでは、スーパーバイザ エンジンの冗長構成について説明します。
• 「概要」
• 「RPR の動作」
• 「SSO 動作」
概要
スーパーバイザ エンジンの冗長構成が有効になっていれば、アクティブ スーパーバイザ エンジンが故障した場合や手動スイッチオーバーが実行された場合に、スタンバイ スーパーバイザ エンジンが「新しい」アクティブスーパーバイザ エンジンとなります。スタンバイ スーパーバイザ エンジンはアクティブ スーパーバイザ エンジンのスタートアップ コンフィギュレーションで自動的に初期化されているため、スイッチオーバー時間が短縮されます(コンフィギュレーションによっては RPR モードで 30 秒以上。SSO モードでは 1 秒以下)。
スーパーバイザ エンジンの冗長性は、スイッチオーバー時間の削減以外にも次の内容をサポートしています。
• スーパーバイザ エンジンの活性挿抜(OIR)
スーパーバイザ エンジンの冗長構成により、メンテナンス時に冗長スーパーバイザ エンジンの OIR が可能になります。冗長スーパーバイザ エンジンが搭載されている場合、アクティブ スーパーバイザ エンジンがその存在を検出し、冗長スーパーバイザ エンジンは RPR モードでは部分的初期化ステート、および SSO モードでは完全初期化ステートで起動します。
• ソフトウェアのアップグレード。(「ソフトウェア アップグレードの実行」を参照)。
スーパーバイザ エンジンのソフトウェア変更中のダウン時間を最小限にするために、スタンバイ スーパーバイザ エンジンに新しいイメージをロードしてスイッチオーバーを実施します。
スイッチを最初に起動して、最初に起動するスーパーバイザ エンジンがアクティブ スーパーバイザ エンジンとなって、スイッチオーバーが発生するまでアクティブのままとなります。
次のイベントが 1 つまたは複数発生するとスイッチオーバーが発生します。
• アクティブ スーパーバイザ エンジンの障害(ハードウェアまたはソフトウェア機能による)、または取り外し。
• ユーザによる強制的なスイッチオーバー。
• ユーザによるアクティブ スーパーバイザ エンジンのリロード。
表 10-1 では、冗長用のシャーシおよびスーパーバイザ エンジンについて説明します。
表 10-1 シャーシおよびスーパーバイザのサポート
|
|
WS-C4507R-E、WS-C4510R-E、WS-C4507R+E、WS-C4510R+E |
Supervisor Engine 7-E(WS-X45-SUP7-E)および Supervisor Engine 7L-E(WS-X45-SUP7L-E) |
RPR の動作
RPR は、Cisco IOS-XE Release 3.1.0SG 以降のリリースでサポートされます。スタンバイ スーパーバイザ エンジンは、RPR モードで稼働する場合、部分的に初期化されたステートで起動し、アクティブ スーパーバイザ エンジンの固定コンフィギュレーションと同期化されます。
(注) 永続的なコンフィギュレーションには、startup-config、ブート変数、config-register、Virtual LAN(VLAN; 仮想 LAN)データベースが含まれます。
スタンバイ スーパーバイザ エンジンは基本的なシステム初期化のあとで起動シーケンスを中止します。アクティブ スーパーバイザ エンジンに障害が発生した場合、スタンバイ スーパーバイザ エンジンが新しいアクティブ スーパーバイザ エンジンになります。
スーパーバイザ エンジンのスイッチオーバーでは、モジュール タイプとステータスに関連するスーパーバイザ エンジンの間ではステートが維持されず、RPR モードの物理ポートすべてが再起動するので、トラフィックが中断します。スイッチオーバー時に、スタンバイ スーパーバイザ エンジンの初期化が完了すると、冗長スーパーバイザ エンジンはモジュールからハードウェア情報を直接読み込み、アクティブなスーパーバイザ エンジンになります。
SSO 動作
SSOCisco IOS-XE Release 3.1.0SG 以降のリリースでサポートされます。スタンバイ スーパーバイザ エンジンは、SSO モードで稼働する場合、完全に初期化されたステートで起動し、アクティブ スーパーバイザ エンジンの固定コンフィギュレーションおよび実行コンフィギュレーションと同期化します。そのあと、スタンバイ スーパーバイザ エンジンは、次のプロトコルのステートを維持し、ステートフル スイッチオーバーをサポートする機能に関するハードウェアおよびソフトウェア ステートの変更すべてを同期化して維持します。そのため、冗長スーパーバイザ エンジン構成内のレイヤ 2 セッションへの割り込みはありません。
スタンバイ スーパーバイザ エンジンは、すべてのリンクのハードウェア リンク ステータスを認識しているため、スイッチオーバー前にアクティブだったポートはアップリンク ポートを含め、アクティブのままになります。ただし、アップリンク ポートは物理的にスーパーバイザ エンジン上にあるので、スーパーバイザ エンジンが取り外されると切断されます。
アクティブ スーパーバイザ エンジンに障害が発生した場合、スタンバイ スーパーバイザ エンジンがアクティブになります。この新しいアクティブ スーパーバイザ エンジンは既存のレイヤ 2 スイッチング情報を使用して、トラフィック転送を続けます。ルーティング テーブルが新しいアクティブ スーパーバイザ エンジンに追加されるまで、レイヤ 3 の転送は延期されます。
SSO は、次のレイヤ 2 機能のステートフル スイッチオーバーをサポートします。
(注) SSO は、IOS-XE ソフトウェアが LAN Base モードで動作している場合は、サポートされません。
次の機能のステートは、アクティブおよびスタンバイ スーパーバイザ エンジンの間で保存されます。
• 802.3
• 802.3u
• 802.3x(フロー制御)
• 802.3ab(GE)
• 802.3z(CWDM を含めたギガビット イーサネット)
• 802.3ad(LACP)
• 802.1p(レイヤ 2 QoS)
• 802.1q
• 802.1X(認証)
• 802.1D(スパニングツリー プロトコル)
• 802.3af(インライン パワー)
• PAgP
• VTP
• ダイナミック ARP インスペクション
• DHCP スヌーピング
• IP ソース ガード
• IGMP スヌーピング(バージョン 1 および 2)
• DTP(802.1Q および ISL)
• MST
• PVST+
• ラピッド PVST
• PortFast/UplinkFast/BackboneFast
• BPDU ガードおよびフィルタリング
• 音声 VLAN
• ポート セキュリティ
• ユニキャスト MAC フィルタリング
• ACL(VACL、PACL、RACLS)
• QoS(DBL)
• マルチキャスト ストーム制御/ブロードキャストストーム制御
SSO は、次の機能と互換性があります。ただし、次の機能のプロトコル データベースはスタンバイ スーパーバイザ エンジンとアクティブ スーパーバイザ エンジンの間では同期化されません。
• レイヤ 2 プロトコル トンネリング(L2PT)を備えた 802.1Q トンネリング
• ベビー ジャイアント
• ジャンボ フレーム サポート
• CDP
• フラッディング ブロック
• UDLD
• SPAN/RSPAN
• NetFlow
SSO 機能がイネーブルの場合、次の機能がスタンバイ スーパーバイザ エンジンで学習されます。
• Catalyst 4500 シリーズ スイッチ上のレイヤ 3 プロトコルすべて(スイッチ仮想インターフェイス)
スーパーバイザ エンジンの冗長構成の同期化について
通常の動作中、永続的なコンフィギュレーション(RPR および SSO)と実行コンフィギュレーション(SSO だけ)は、2 台のスーパーバイザ エンジンの間のデフォルトで同期化されます。スイッチオーバー時には、新しいアクティブ スーパーバイザ エンジンが現在の設定を使用します。
(注) スタンバイ スーパーバイザ エンジン コンソールで Command-Line Interface(CLI; コマンドライン インターフェイス)コマンドを入力することはできません。
ここでは、スーパーバイザ エンジンの冗長構成の同期化について説明します。
• 「RPR スーパーバイザ エンジンの設定の同期化」
• 「SSO スーパーバイザ エンジンの設定の同期化」
RPR スーパーバイザ エンジンの設定の同期化
RPR モードでは、スタンバイ スーパーバイザ エンジンは部分的に初期化されるだけであるため、起動時に設定変更を受信する場合、および設定変更を保存する場合にかぎり、アクティブ スーパーバイザ エンジンと対話します。
スタンバイ スーパーバイザ エンジンが RPR モードで動作している場合は、次のイベントによってコンフィギュレーション情報の同期化がトリガーされます。
• スタンバイ スーパーバイザ エンジンが起動したとき、 auto-sync コマンドによって、固定コンフィギュレーションに同期化されます。このコマンドは、デフォルトでイネーブルにされています。詳細については、「スーパーバイザ エンジンの設定の同期化」を参照してください。
• アクティブ スーパーバイザ エンジンがスタンバイ スーパーバイザ エンジンを検出すると、コンフィギュレーション情報がアクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンに同期されます。この同期化により、スタンバイ スーパーバイザ エンジン上にある既存のスタートアップ コンフィギュレーション ファイルが上書きされます。
• 設定を変更する場合は、write コマンドを使用して、スタンバイ スーパーバイザ エンジンにスタートアップ コンフィギュレーションを保存および同期化する必要があります。
SSO スーパーバイザ エンジンの設定の同期化
スタンバイ スーパーバイザ エンジンが SSO モードで稼働している場合は、次のイベントがトリガーとなって設定情報の同期化が発生します。
• アクティブ スーパーバイザ エンジンがスタンバイ スーパーバイザ エンジンを検出すると、固定および実行コンフィギュレーションの同期化が発生し、これにより、スタンバイ スーパーバイザ エンジンが完全初期化ステートに移行できるようになります。
• リアルタイムで変更が発生すると、アクティブ スーパーバイザ エンジンは、必要に応じて、実行コンフィギュレーションおよび(または)固定コンフィギュレーションとスタンバイ スーパーバイザ エンジンを同期化します。
• 設定を変更する場合、write コマンドを使用して、アクティブ スーパーバイザ エンジンがスタンバイ スーパーバイザ エンジンにスタートアップ コンフィギュレーションを保存および同期化できるようにする必要があります。
スーパーバイザ エンジンの冗長構成に関する注意事項および制約事項
スーパーバイザ エンジンの冗長構成に関する注意事項および制約事項は、次のとおりです。
• コンフィギュレーション ファイルの互換性の問題が原因で、アクティブ スーパーバイザ エンジンとスタンバイ スーパーバイザ エンジン間で SSO モードを確立できない場合、Mismatched Command List(MCL)がアクティブ スーパーバイザ エンジンで生成され、スタンバイ スーパーバイザ エンジンに対して、RPR モードへのリロードが強制されます。問題のある設定を削除し、まったく同じイメージでスタンバイ スーパーバイザ エンジンを再起動した後に、SSO の確立を試行すると、ピア イメージに互換性がないことがリストに示されているため、C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL および ISSU-3-PEER_IMAGE_INCOMPATIBLE メッセージが表示されることがあります。設定の問題を修正できる場合は、ピアが STANDBY COLD(RPR)ステートのときに、redundancy config-sync ignore mismatched-commands EXEC コマンドで、互換性のないリストからピア イメージをクリアできます。このアクションによって、スタンバイ スーパーバイザ エンジンは、リロード時に、STANDBY HOT(SSO)ステートで起動できます。
次に、手順を示します。
ステップ 1 スタンバイ スーパーバイザ エンジンが STANDBY COLD(RPR)ステートである間に、(MCL を生成した)問題のある設定をクリアします。
ステップ 2 アクティブなスタンバイ スーパーバイザ エンジンで redundancy config-sync ignore mismatched-commands EXEC コマンドを入力します。
ステップ 3 write memory を実行します。
ステップ 4 redundancy reload peer コマンドで、スタンバイ スーパーバイザ エンジンをリロードします。
• RPR および SSO は、Cisco IOS-XE Release 3.1.0SG 以降のリリースを要求します。
• SSO は、IOS-XE ソフトウェアが LAN Base モードで動作している場合は、サポートされません。
• Supervisor Engine 7-E および Supervisor Engine 7L-E の冗長構成をサポートする Catalyst 4500 シリーズ スイッチは、WS-C4507R-E、WS-C4510R-E、WS-C4507R+E および WS-C4510R+E だけです。
• SSO では、シャーシ内の両方のスーパーバイザ エンジンが同じコンポーネント(モデルおよびメモリ)を持っており、同じ Cisco IOS XE ソフトウェア イメージを使用している必要があります。
• RPR または SSO モードで WS-X45-SUP7-E と WS-X45-SUP7L-E を使用する場合、各スーパーバイザ エンジン上の最初の 2 つのアップリンクだけを使用できます。2 番目の 2 つのアップリンクは使用できません。
• シャーシ内のアクティブおよびスタンバイ スーパーバイザ エンジンは、7 スロット シャーシではスロット 3 および 4、10 スロット シャーシではスロット 5 および 6 に設置されている必要があります。
• シャーシの各スーパーバイザ エンジンには、スイッチを独自に動作させるために、独自のフラッシュ デバイスとコンソール ポート接続が備えられている必要があります。
• 各スーパーバイザ エンジンには、個別のコンソール ポート接続を行う必要があります。コンソール ポートに Y 字ケーブルを接続しないでください。
• スーパーバイザ エンジンの冗長構成にはスーパーバイザ エンジンのロード バランシング機能がありません。
• スイッチオーバー時にシスコ エクスプレス フォワーディング(CEF)テーブルがクリアされます。その結果、ルーテッド トラフィックは、ルート テーブルが再コンバージェンスするまで中断されます。SSO 機能がスーパーバイザ エンジンの冗長スイッチオーバー時間を 30 秒以上から 1 秒以下に削減するので、この再コンバージェンス時間は最小となります。また、スイッチが SSO 用に設定された場合のレイヤ 3 のフェールオーバー時間も早くなります。
• スタティック IP ルートは、コンフィギュレーション ファイル内のエントリから設定されるため、スイッチオーバー中も維持されます。
• アクティブ スーパーバイザ エンジン上で維持されているレイヤ 3 ダイナミック ステート情報は、スタンバイ スーパーバイザ エンジンに同期されないため、スイッチオーバー時に失われます。
• SNMP 設定操作を通して冗長スイッチ上のコンフィギュレーションが変更された場合は、SSO モードであっても、その変更がスタンバイ スーパーバイザ エンジンに同期されません。予期しない動作が発生する可能性があります。
• SSO モードで SNMP によってスイッチを設定したあとで、アクティブ スーパーバイザ エンジン上の running-config ファイルを startup-config ファイルにコピーすると、スタンバイ スーパーバイザ エンジン上の startup-config ファイルの同期化が発生します。新しい設定がスタンバイ スーパーバイザ エンジンに適用されるようにスタンバイ スーパーバイザ エンジンをリロードします。
• スタートアップ(一括)同期中は、設定を変更できません。このプロセス中に設定を変更しようとすると、次のメッセージが生成されます。
Config mode locked out till standby initializes
• スーパーバイザ エンジンのスイッチオーバー時に設定を変更した場合、設定の変更内容は失われます。
• 冗長スイッチからラインカードを取り外し、SSO スイッチオーバーを開始してから、ラインカードを再度挿入すると、すべてのインターフェイスはシャットダウンされます。元のラインカードの他の設定は、保持されます。
この状況は、ラインカードを取り外す前に、スイッチが SSO に到達した場合にだけ発生します。
スーパーバイザ エンジンの冗長構成の設定
ここでは、スーパーバイザ エンジンの冗長構成を設定する手順について説明します。
• 「冗長性の設定」
• 「スタンバイ スーパーバイザ エンジンの仮想コンソール」
• 「スーパーバイザ エンジンの設定の同期化」
冗長性の設定
(注) IOS XE ソフトウェアは、スーパーバイザ エンジン上で使用可能なライセンスに基づく 3 つの異なるレベル(Enterprise Services、IP Base、および LAN Base)で起動することができます。LAN Base モードでイメージを起動している場合は、RPR 冗長モードのみが使用できます。
冗長性を設定するには、次の作業を実行します。
|
|
|
ステップ 1 |
Switch(config)#
redundancy
|
冗長コンフィギュレーション モードを開始します。 |
ステップ 2 |
Switch(config-red)#
mode {sso |
rpr}
|
SSO または RPR を設定します。このコマンドを入力すると、スタンバイ スーパーバイザ エンジンがリロードされ、SSO または RPR モードで動作を開始します。 |
ステップ 3 |
Switch#
show running-config
|
SSO または RPR が設定されていることを確認します。 |
ステップ 4 |
Switch#
show redundancy [clients |
counters |
history |
states]
|
アクティブおよびスタンバイ スーパーバイザ エンジン用に冗長構成情報(カウンタ、ステートなど)を表示します。 |
次に、SSO のシステムを設定し、冗長ファシリティ情報を表示する例を示します。
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# redundancy
Switch(config-red)# mode sso
Redundant System Information :
------------------------------
Available system uptime = 10 minutes Switchovers system experienced = 0
Last switchover reason = none
Configured Redundancy Mode = Stateful Switchover
Operating Redundancy Mode = Stateful Switchover
Maintenance Mode = Disabled
Current Processor Information :
------------------------------
Current Software state = ACTIVE
Uptime in current state = 9 minutes
Image Version = Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 15.0(100)XO(1.42), INTERIM SOFTWARE Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Sun 01-Aug-10 04:12 by gsbuprod
Configuration register = 0x920
Peer Processor Information :
------------------------------
Standby Location = slot 4
Current Software state = STANDBY HOT
Uptime in current state = 0 minute
Image Version = Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 15.0(100)XO(1.42), INTERIM SOFTWARE Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Sun 01-Aug-10 04:12 by gsbuprod
Configuration register = 0x920
次に、冗長ファシリティ ステート情報を表示する例を示します。
Switch# show redundancy states
peer state = 8 -STANDBY HOT
Redundancy Mode (Operational) = Stateful Switchover
Redundancy Mode (Configured) = Stateful Switchover
Redundancy State = Stateful Switchover
client_notification_TMR = 240000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive threshold = 18
次に、システム設定を RPR モードから SSO モードに変更する例を示します。
Switch(config)# redundancy
Switch(config-red)# mode sso
Changing to sso mode will reset the standby. Do you want to continue?[confirm]
*Aug 1 13:11:16: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost
*Aug 1 13:11:16: %C4K_REDUNDANCY-3-SIMPLEX_MODE: The peer Supervisor has been lost
次に、システム設定を SSO モードから RPR モードに変更する例を示します。
Switch(config)# redundancy
Switch(config-red)# mode rpr
Changing to rpr mode will reset the standby. Do you want to continue?[confirm]
*Aug 1 13:11:16: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost
*Aug 1 13:11:16: %C4K_REDUNDANCY-3-SIMPLEX_MODE: The peer Supervisor has been lost
スタンバイ スーパーバイザ エンジンの仮想コンソール
Catalyst 4500 シリーズ スイッチには、冗長性を持たせるため、2 つのスーパーバイザ エンジンを搭載できます。スイッチに電源が入ると、スーパーバイザ エンジンの 1 つがアクティブになり、スイッチオーバーが発生するまでアクティブのままになります。もう 1 つのスーパーバイザ エンジンはスタンバイ モードのままです。
スーパーバイザ エンジンのそれぞれには、自身のコンソール ポートがあります。スタンバイ スーパーバイザ エンジンのコンソール ポート経由でだけ、スタンバイ スーパーバイザ エンジンにアクセスできます。したがって、スタンバイ スーパーバイザに対するアクセス、モニタリング、またはデバッグを行うには、スタンバイ コンソールに接続する必要があります。
スタンバイ スーパーバイザ エンジンの仮想コンソールを使用すると、スタンバイ コンソールへの物理的な接続がなくてもアクティブ スーパーバイザ エンジンからスタンバイ コンソールにアクセスできます。EOBC で IPC を使用してスタンバイ スーパーバイザ エンジンと通信し、アクティブ スーパーバイザ エンジン上でスタンバイ コンソールをエミュレートします。一度にアクティブにできるスタンバイ コンソール セッションは 1 つだけです。
スタンバイ スーパーバイザ エンジンの仮想コンソールにより、アクティブ スーパーバイザ エンジンにログインしているユーザは、スタンバイ スーパーバイザ エンジン上で show コマンドをリモートで実行し、アクティブ スーパーバイザ エンジンでその結果を表示できます。仮想コンソールは、アクティブ スーパーバイザ エンジンからだけ利用できます。
アクティブ スーパーバイザ エンジンからアクティブ スーパーバイザ エンジンの attach module コマンド、session module コマンド、または remote login コマンドを使用してスタンバイ仮想コンソールにアクセスできます。これらのコマンドを実行してスタンバイ コンソールにアクセスするには、特権 EXEC モード(レベル 15)を開始している必要があります。
スタンバイ仮想コンソールにアクセスすると、端末プロンプトは自動的に hostname-standby-console に変わります。hostname はスイッチに設定した名前です。仮想コンソールを終了すると、このプロンプトは元の設定に戻ります。
exit コマンドまたは quit コマンドを入力すると、仮想コンソールは終了します。ログインしたアクティブ スーパーバイザ エンジンの端末の無活動時間が設定されたアイドル時間を超えると、アクティブ スーパーバイザ エンジンの端末から自動的にログアウトします。この場合、仮想コンソール セッションも終了します。また、スタンバイが再起動すると、仮想コンソール セッションも自動的に終了します。スタンバイが起動したあとは、別の仮想コンソール セッションを作成する必要があります。
仮想コンソールを使用してスタンバイ スーパーバイザ エンジンにログインするには、次の操作を実行します。
Connecting to standby virtual console
Type "exit" or "quit" to end this session
Switch-standby-console# exit
スタンバイ コンソールがイネーブルでない場合、次のメッセージが表示されます。
Standby console disabled.
Valid commands are: exit, logout
(注) スタンバイ仮想コンソールには、コマンド履歴、コマンド補完、コマンド ヘルプ、部分コマンド キーワードなど、スーパーバイザ コンソールから利用できる標準的な機能が備わっています。
次の制限事項がスタンバイ仮想コンソールに適用されます。
• 仮想コンソールで実行されたコマンドは、すべて最後まで実行されます。auto-more 機能はありません。したがって、terminal length 0 コマンドの実行時と同じように機能します。また、対話形式ではありません。したがって、アクティブ スーパーバイザ エンジン上でキー シーケンスを入力しても、コマンドの実行を中断できません。コマンドによって大量の出力が発生した場合、仮想コンソールはスーパーバイザ エンジンの画面に出力を表示します。
• 仮想コンソールは対話形式ではありません。仮想コンソールはコマンドのインタラクティブ性を検出しないため、ユーザとの対話を必要とするコマンドが入力されると、RPC タイマーがコマンドを中断するまで仮想コンソールは待機します。
仮想コンソール タイマーは 60 秒に設定されています。60 秒後に仮想コンソールはプロンプトに戻ります。この間、キーボードからコマンドを中断できません。操作を続ける前に、タイマーが期限切れになるのを待つ必要があります。
• 仮想コンソールを使用して、スタンバイ スーパーバイザ エンジン上で表示されているデバッグおよび Syslog メッセージを表示することはできません。仮想コンソールは、仮想コンソールから実行されたコマンドの出力だけを表示します。実際のスタンバイ コンソールで表示される別の情報は、仮想コンソールでは表示できません。
スーパーバイザ エンジンの設定の同期化
2 台のスーパーバイザ エンジンが使用する設定を手動で同期化するには、アクティブ スーパーバイザ エンジン上で次の作業を行います。
|
|
|
ステップ 1 |
Switch(config)#
redundancy
|
冗長コンフィギュレーション モードを開始します。 |
ステップ 2 |
Switch(config-red)#
main-cpu
|
main-cpu コンフィギュレーション サブモードを開始します。 |
ステップ 3 |
Switch(config-r-mc)# auto-sync {
startup-config |
config-register |
bootvar |
standard }
|
設定要素を同期化します。 |
ステップ 4 |
|
特権 EXEC モードに戻ります。 |
ステップ 5 |
Switch#
copy running-config startup-config
|
Dynamic Random-Access Memory(DRAM; ダイナミック ランダム メモリ)の実行コンフィギュレーション ファイルを NVRAM(不揮発性 RAM)のスタートアップ コンフィギュレーション ファイルに同期化します。 (注) DRAM 上の実行コンフィギュレーション ファイルを同期化する場合、このステップは不要です。 |
(注) SNMP によるアクティブ スーパーバイザ エンジンの設定変更は、冗長スーパーバイザ エンジンに同期化されません。この場合の詳細な取り扱いについては、「スーパーバイザ エンジンの冗長構成に関する注意事項および制約事項」を参照してください。
(注) auto-sync コマンドは、config-reg、bootvar、および startup/private コンフィギュレーション ファイルの同期化だけを制御します。カレンダーおよび VLAN データベース ファイルは、変更するたびに常に同期化されます。SSO モードでは、running-config は常に同期化されます。
次の例では、 auto-sync standard コマンドを使用してデフォルトの自動同期化機能をイネーブルに戻して、アクティブ スーパーバイザ エンジンの startup-config および config-register コンフィギュレーションをスタンバイ スーパーバイザ エンジンと同期化する方法を示します。ブート変数のアップデートは自動的に行われるため、ディセーブルにできません。
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# auto-sync standard
Switch# copy running-config startup-config
(注) 標準の自動同期対象の設定要素を個別に手動で同期化するには、デフォルトの自動同期化機能をディセーブルにします。
(注) auto-sync standard を設定すると、個別の同期化オプション(no auto-sync startup-config など)は無視されます。
次に、デフォルトの自動同期化をディセーブルにして、アクティブ スーパーバイザ エンジンの config-register だけをスタンバイ スーパーバイザ エンジンに自動的に同期化し、スタートアップ コンフィギュレーションの同期化を許可しない例を示します。
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# no auto-sync standard
Switch(config-r-mc)# auto-sync config-register
手動による切り替え
ここでは、テストのため手動による切り替え(アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへ)を行う方法を説明します。ご使用の稼働環境に SSO を展開する前に、手動で切り替えることを推奨します。
(注) これは、SSO が冗長モードとして設定されていることを前提としています。
手動で切り替えるには、アクティブ スーパーバイザ エンジンで次の作業を行います。
|
|
|
ステップ 1 |
|
ピア ステートが STANDBY HOT ステートであることを確認します。 P.6 ~ 10 の show redundancy states コマンドの例を参照してください。 |
ステップ 2 |
Switch#
redundancy force-switchover
|
アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンへのスイッチオーバーを開始します。 |
次の使用上の注意事項に留意してください。
• スイッチオーバーを強制します。冗長スーパーバイザ エンジンは、STANDBY HOT(SSO)ステートまたは STANDBY COLD(RPR)ステートにする必要があります。show redundancy コマンドを使用して、ステートを確認することができます。ステートが STANDBY HOT でも STANDBY COLD でもない場合は、redundancy force-switchover コマンドが実行されません。
• スイッチオーバーを開始するには、reload コマンドではなく、redundancy force-switchover コマンドを使用します。redundancy force-switchover コマンドが、冗長スーパーバイザ エンジンが正しいステートであるかどうかを最初に確認します。reload コマンドを発行し、ステータスが STANDBY HOT または STANDBY COLD ではない場合、reload コマンドは、現在のスーパーバイザ エンジンをリセットし、ピア スーパーバイザは、terminal ステート(STANDBY HOT または STANDBY COLD)でないため、引き継ぐことができない可能性があります。
通常のスイッチオーバー後に、シャーシ内のよりスロット番号の低いスーパーバイザ エンジンをアクティブ スーパーバイザ エンジンにすることができます。どのスロットにアクティブ スーパーバイザ エンジンが含まれているかを判断し、必要に応じて別のスイッチオーバーを強制的に実行するには、show module コマンドを使用します。
ソフトウェア アップグレードの実行
これは、IOS -XE ソフトウェアが LAN Base モードで動作している場合にのみ有効です。Enterprise Services モードまたは IP Base モードでは、ISSU を使用して RPR 冗長モードと SSO 冗長モードの両方のソフトウェアをアップグレードします。
スーパーバイザ エンジンの冗長構成がサポートするソフトウェアのアップグレード手順によって、冗長スーパーバイザ エンジン上の Cisco IOS ソフトウェア イメージをリロードし、そのあとでもう一度、アクティブ スーパーバイザ エンジンにリロードできます。
ソフトウェアのアップグレードを実行するには、次の作業を行います。
|
|
|
ステップ 1 |
Switch#
copy
source_device
:
source_filename
slot0:
target_filename
または:
Switch#
copy
source_device
:
source_filename
bootflash:
target_filename
|
スーパーバイザ エンジン上のブートフラッシュに、新しい Cisco IOS-XE ソフトウェア イメージをコピーします。 |
ステップ 2 |
Switch#
copy
source_device
:
source_filename
slaveslot0:
target_filename
または:
Switch#
copy
source_device
:
source_filename
slavebootflash:
target_filename
|
スタンバイ スーパーバイザ エンジンのデバイス(slavebootflash、slaveslot0 など)に、新しいイメージをコピーします。 |
ステップ 3 |
Switch(config)# config-register 0x2
Switch(config)# boot system flash
device :
file_name
|
新しいイメージを起動するように、スーパーバイザ エンジンを設定します。 システムが古いイメージを自動的に起動するよう設定されている場合、次のコマンド ストリングを発行して代わりに新しいイメージを起動します。 no boot system flash device : old_file_name |
ステップ 4 |
Switch(config)# redundancy
|
冗長コンフィギュレーション モードを開始します。 |
ステップ 5 |
Switch(config-red)# main-cpu
|
main-cpu コンフィギュレーション サブモードを開始します。 |
ステップ 6 |
Switch(config-r-mc)# auto-syn standard
|
設定要素を同期化します。 |
ステップ 7 |
|
特権 EXEC モードに戻ります。 |
ステップ 8 |
Switch# copy running-config start-config
|
設定を保存します。 |
ステップ 9 |
Switch# redundancy reload peer
|
スタンバイ スーパーバイザ エンジンをリロードして、オンラインに戻します(Cisco IOS-XE ソフトウェアの新しいリリースを使用します)。 |
ステップ 10 |
Switch# redundancy force-switchover
|
スタンバイ スーパーバイザ エンジンへの手動スイッチオーバーを実施します。スタンバイ スーパーバイザ エンジンが、新しい Cisco IOS-XE ソフトウェア イメージを使用する新しいアクティブ スーパーバイザ エンジンになります。 以前のアクティブ スーパーバイザ エンジンが新しいイメージで再起動し、スタンバイ スーパーバイザ エンジンになります。 |
次に、ソフトウェア アップグレードの実行例を示します。
Switch(config)# config-register 0x2
Switch(config)# boot system flash bootflash0:cat4500e-universalk9.SSA.03.01.00.150.1.XO.bin
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# auto-syn standard
Switch# copy running-config start-config
Switch# redundancy reload peer
Switch# redundancy force-switchover
次に、アクティブ スーパーバイザ エンジン上の実行コンフィギュレーションと冗長スーパーバイザ エンジンとの同期化が成功したことを確認する例を示します。
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# auto-sync standard
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The bootvar has been successfully synchronized to the standby supervisor
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The config-reg has been successfully synchronized to the standby supervisor
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized to the standby supervisor
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor
上記の例では、アクティブ スーパーバイザ エンジンからのブート変数、config-register、スタートアップ コンフィギュレーションが冗長スーパーバイザ エンジンに同期化したことを示します。
スタンバイ スーパーバイザ エンジン上でのブートフラッシュの操作
(注) スタンバイ スーパーバイザ エンジン上のコンソール ポートは使用できません。
スタンバイ スーパーバイザ エンジン ブートフラッシュを操作するには、次の 1 つまたは複数の作業を行います。
|
|
Switch#
dir slaveslot0:
target_filename
または Switch# dir slavebootflash: target_filename |
スタンバイ スーパーバイザ エンジンの slot0: デバイスの内容を表示します。 スタンバイ スーパーバイザ エンジンの bootflash: デバイスの内容を表示します。 |
Switch#
delete slaveslot0:
target_filename
or
Switch#
delete slavebootflash:
target_filename
|
スタンバイ スーパーバイザ エンジンの slot0: デバイスから特定のファイルを削除します。 スタンバイ スーパーバイザ エンジンの bootflash: デバイスから特定のファイルを削除します。 |
Switch#
squeeze slaveslot0:
target_filename
or
Switch#
squeeze slavebootflash:
target_filename
|
スタンバイ スーパーバイザ エンジンの slot0: デバイスをスクイーズします。 スタンバイ スーパーバイザ エンジンの bootflash: デバイスをスクイーズします。 |
Switch#
format slaveslot0:
target_filename
or
Switch#
format slavebootflash:
target_filename
|
スタンバイ スーパーバイザ エンジンの slot0: デバイスをフォーマットします。 スタンバイ スーパーバイザ エンジンの bootflash: デバイスをフォーマットします。 |
Switch#
copy
source_device
:
source_filename
slaveslot0:
target_filename
or
Switch#
copy
source_device
:
source_filename
slavebootflash:
target_filename
|
アクティブ スーパーバイザ エンジンからスタンバイ スーパーバイザ エンジンの slot0: デバイスにファイルをコピーします。 スタンバイ スーパーバイザ エンジンの bootflash: デバイスにファイルをコピーします。 (注) 送信元はアクティブ スーパーバイザ エンジン、または TFTP サーバです。 |