ハイ アベイラビリティ（SSO）導入ガイド
目次
5500/7500/8500 WLC での冗長ポートを使用した HA 接続
WiSM-2 WLC での冗長 VLAN を使用したハイ アベイラビリティ接続
HA セットアップに含まれる WLC のアップグレードを開始する前の重要なガイドライン
HA セットアップでのファクトのダウンロードおよびアップロード
レガシーのプライマリ、セカンダリ、ターシャリ HA と合わせた SSO 導入
1 つの WLC に有効な AP カウント ライセンスがあり、もう 1 つの WLC に HA SKU UDI がある
1 つの WLC に評価ライセンスがあり、もう 1 つの WLC に HA SKU UDI または永久ライセンスがある
VSS ペアに接続された 5508、7500 または 8500
別のシャーシ内の WiSM2：L2 ネットワークによる冗長 VLAN
クライアント SSO（クライアント ステートフル スイッチオーバー）
はじめに
このドキュメントでは、アクセス ポイントおよびクライアントのステートフル スイッチオーバー（AP およびクライアント SSO）のサポートに関連する Cisco Unified Wireless LAN Controller（WLC）の操作と設定のセオリーについて説明します。
Cisco Unified Wireless Network ソフトウェア リリース バージョン 7.3 および 7.4 の新しいハイ アベイラビリティ（HA）機能セットである AP SSO を使用すると、アクセス ポイント（AP）でアクティブ WLC との CAPWAP トンネルを確立でき、AP データベースのミラー コピーをスタンバイ WLC と共有できます。アクティブ WLC が故障した場合、AP は Discovery 状態にならず、スタンバイ WLC がアクティブ WLC としてネットワークを引き継ぎます。任意の時点で、AP とアクティブ状態の WLC の間で維持される CAPWAP トンネルは 1 つだけです。Cisco Unified Wireless LAN に AP SSO サポートが追加されたのは、障害状態によって引き起こされるワイヤレス ネットワークの大規模なダウンタイムを削減することを全体的な目標としています。この障害状態は、ボックス フェールオーバーまたはネットワーク フェールオーバーが原因で発生する可能性があります。
サービスに影響を与えずにハイ アベイラビリティをサポートするには、アクティブ コントローラからスタンバイ コントローラへのクライアントおよび AP のシームレスな遷移をサポートすることが必要となります。リリース 7.5 では、クライアント ステートフル スイッチ オーバー（クライアント SSO）をワイヤレス LAN コントローラでサポートします。クライアント SSO がサポートされるのは、すでに認証および DHCP フェーズが完了し、トラフィックを通しはじめたクライアントです。SSO クライアントによって、WLC にクライアントが関連付けられたときまたはクライアントのパラメータが変更されたときに、クライアント情報はスタンバイ WLC へ同期します。完全に認証済みのクライアント（Run 状態のクライアントなど）はスタンバイへと同期され、スイッチオーバー時のクライアントの再関連付けは回避されます。これによりクライアントと AP のフェールオーバーはシームレスになり、クライアント サービスのダウンタイム ゼロと SSID の非停止が実現します。
前提条件
使用されるコンポーネント
このマニュアルの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
•
WLC 5500 シリーズ、7500/8500 シリーズ、および WiSM-2
• AP 700、1130、1240、1250、1040、1140、1260、1600、2600、3500、3600 シリーズ AP、および 1520 または 1550 シリーズ メッシュ AP（MAP）。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このマニュアルで使用されるデバイスはすべて、初期設定（デフォルト）の状態から作業が開始されています。ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
リリース 7.3 と 7.4 でのハイ アベイラビリティ
HA の新しいアーキテクチャは、ボックスツーボックス冗長性を目的としています。つまり、1 つの WLC がアクティブ状態になり、2 つ目の WLC が冗長ポートを介してアクティブ WLC の状態を継続的にモニタするホット スタンバイ状態になる 1 対 1 対応です。両方の WLC では、管理インターフェイスの IP アドレスなど、同じ設定のセットを共有します。設定全体が冗長ポートを介してアクティブ WLC からスタンバイ WLC に同期されるため（起動時のバルク設定および実行時の増分設定）、スタンバイ状態の WLC を個別に設定する必要はありません。AP の CAPWAP 状態（run 状態の AP のみ）も同期され、AP データベースのミラー コピーがスタンバイ WLC 上で維持されます。アクティブ WLC が故障した場合、AP は Discovery 状態にならず、スタンバイ WLC がネットワークのアクティブ WLC を引き継ぎます。
プリエンプション機能はありません。前のアクティブ WLC が復帰した場合、この WLC はアクティブ WLC の役割を引き継ぎませんが、現在のアクティブ WLC と状態をネゴシエートしてスタンバイ状態に遷移します。アクティブとスタンバイを決めるのは自動選択処理ではありません。アクティブとスタンバイの WLC は、リリース 7.3 以降では、HA SKU（製造時に注文される UDI）に基づいて決まります。HA SKU UDI を備えた WLC は、ブート時に、まずスタンバイ WLC になり、永久カウント ライセンスを実行している WLC とペアになります。永久カウント ライセンスのある既存の WLC の場合は、手動設定に基づいてアクティブとスタンバイが決定されます。
AP SSO は、5500/7500/8500 および WiSM-2 WLC でサポートされています。リリース 7.3 では、スイッチオーバー後に AP セッションが損なわれないことを保障する AP SSO のみをサポートしています。MAP は、RAP ではメッシュ クライアントとして扱われ、AP SSO で認証解除されません。
クライアント SSO は 5500/7500/8500 および WiSM2 WLC でサポートされます（リリース 7.5 以降）。詳細については、 リリース 7.5 のハイ アベイラビリティを参照してください。
5500/7500/8500 WLC での冗長ポートを使用した HA 接続
• 5500/7500/8500 WLC には、アクティブからスタンバイ WLC に設定を同期するためにバックツーバック接続する必要のある専用冗長ポートが装備されています。
• アクティブ WLC の状態を確認するために、冗長ポートを介してスタンバイからアクティブ WLC に 100 ミリ秒（デフォルト タイマー）ごとにキープアライブ パケットが送信されます。
• HA セットアップの両方の WLC がゲートウェイの到達可能性を追跡します。アクティブ WLC は、管理 IP アドレスを発信元に使用してインターネット制御メッセージ プロトコル（ICMP）の ping をゲートウェイに送信し、スタンバイ WLC は、冗長性管理 IP アドレスを使用して ICMP の ping をゲートウェイ送信します。両方の WLC が、1 秒間隔でゲートウェイに ICMP ping を送信します。
• 冗長ポート間のバックツーバック直接接続を設けることを強くお勧めします。
次に、HA セットアップでの 5500 WLC 間の冗長ポート接続を示します。
次に、HA セットアップでの Flex 7500 WLC 間の冗長ポート接続を示します。
（注） アクティブとスタンバイの冗長ポート間を物理的に直接接続することを強くお勧めします。接続間の距離は、イーサネット ケーブルの規格によって 100 メートルまで可能です。
WiSM-2 WLC での冗長 VLAN を使用したハイ アベイラビリティ接続
• WiSM-2 WLC は、アクティブ WLC からスタンバイ WLC への設定の同期に使用される専用冗長 VLAN を持ちます。
• 冗長 VLAN の 1 つは、HA ペアリング処理専用のレイヤ 2 VLAN である必要があります。ネットワークをまたがっていない必要があり、レイヤ 3 SVI インターフェイスを持たない必要があります。データ VLAN は冗長 VLAN として使用しないでください。
• アクティブ WLC の状態を確認するために、冗長 VLAN を介してスタンバイ WLC からアクティブ WLC に 100 ミリ秒（デフォルト タイマー）ごとにキープアライブ パケットが送信されます。
• HA セットアップの両方の WiSM がゲートウェイの到達可能性を追跡します。アクティブ WLC は、管理 IP アドレスを発信元に使用して ICMP の ping をゲートウェイに送信し、スタンバイ WLC は、冗長性管理 IP アドレスを使用して ICMP の ping をゲートウェイ送信します。両方の WLC が、1 秒間隔でゲートウェイに ICMP ping を送信します。
• HA を実現するためには、WiSM-2 WLC を単一のシャーシだけに配置するか、VSS を使用して複数 Catalyst 6500 シャーシ間に配置する必要があります。
次の図は、単一シャーシの HA 接続および複数シャーシ VSS セットアップでの拡張冗長 VLAN を示します。
警告 注意：冗長 VLAN は、ルーティング不能 VLAN である必要があります。つまり、この VLAN のレイヤ 3 インターフェイスを作成してはならず、VSS セットアップでの複数シャーシ間 HA セットアップを拡張する VSL リンクで使用できます。この VLAN は HA 処理専用にし、いずれのデータ VLAN にも使用しないことが重要です。使用した場合は、予期しない結果になります。
（注） 冗長 VLAN は、通常のデータ VLAN 同様に IOS スイッチに作成する必要があります。冗長 VLAN は、バックプレーンに接続された WiSM-2 ブレード上の冗長ポート用に設定されます。冗長 VLAN には、このドキュメントで後述する自動生成される IP が割り当てられるため、IP アドレスを設定する必要はありません。
（注） Cisco WiSM2 および Cisco Catalyst 6500 シリーズ Supervisor Engine 2T の場合、HA がイネーブルにされていると、スイッチオーバーで、AP は接続解除されて WiSM2 コントローラに関連付けられることがあります。この問題の発生を防ぐには、HA を設定する前に、ポート チャネルでアクティブとスタンバイ両方の Cisco WiSM2 コントローラの詳細を確認し、ポートが同じ順序に配置され、ポート チャネルのハッシュ分散に同じアルゴリズムを使用していることを確認するよう推奨します。これらが適切でない場合、ポート チャネルの分散を固定に変更し、Cisco Catalyst 6500 シリーズ Supervisor Engine 2T から Cisco WiSM2 をリセットする必要があります。コマンド show etherchannel port-channel を使用して、ポート チャネル メンバーの順序および負荷値を確認できます。コンフィギュレーション コマンド port-channel hash-distribution fixed を使用すると、分散を固定できます。
（注） 異なるデータセンターにあるアクティブおよびスタンバイの WLC をサポートするため、リリース 7.5 では、ピア間のバックツーバック冗長ポート接続は必須でなくなり、2 つのコントローラ間に L2 隣接関係がある場合のように、コントローラ間冗長ポートをスイッチ経由で接続できるようになりました。詳細については、「 7.5 の冗長ポート接続」を参照してください。
冗長性管理インターフェイス
このインターフェイスには、管理インターフェイスと同じサブネットの IP アドレスを設定する必要があります。アクティブ WLC が冗長ポートのキープアライブ メッセージに応答しない場合は、このインターフェイスにより、ネットワーク インフラストラクチャを介してアクティブ WLC の状態が確認されます。これは、ネットワークとアクティブ WLC の追加のヘルス チェックになり、スイッチオーバーを実行する必要があるのかどうかの確認になります。スタンバイ WLC では、ゲートウェイの到達可能性を確認する ICMP ping パケットを発信する際も、このインターフェイスを使用します。このインターフェイスは、ボックス障害または手動リセットの際に、アクティブ WLC からスタンバイ WLC に通知を送信するためにも使用されます。スタンバイ WLC では、Syslog や NTP サーバ、およびすべての設定アップロードで TFTP サーバと通信するために、このインターフェイスを使用します。
冗長ポート
このインターフェイスは、新しい HA アーキテクチャで非常に重要な役割を持ちます。起動時のバルク設定と増分設定は、冗長ポートを使用してアクティブ WLC からスタンバイ WLC に同期されます。HA セットアップの WLC では、このポートを使用して HA 役割のネゴシエーションを実行します。冗長ポートは、100 ミリ秒（デフォルト タイマー）ごとにスタンバイ WLC からアクティブ WLC に UDP キープアライブ メッセージを送信してピアの到達可能性を確認するためにも使用されます。ボックス障害の際には、冗長ポートを介して、アクティブ WLC からスタンバイ WLC に対する通知も送信されます。NTP サーバが設定されていない場合は、冗長ポートを介して、アクティブ WLC からスタンバイ WLC への手動時刻同期が実行されます。スタンドアロン コントローラの場合のこのポートおよび WISM-2 の場合の冗長 VLAN には、最後の 2 オクテットを冗長性管理インターフェイスの最後の 2 オクテットから取得する、自動生成される IP アドレスが割り当てられます（先頭の 2 オクテットは常に 169.254）。
CLI からの HA の設定
1. HA を設定する前に両方のコントローラの管理インターフェイスが同じサブネットに入っている必要があります。
2. HA はデフォルトでディセーブルになっています。HA をイネーブルにする前に、冗長性管理 IP アドレスおよびピア冗長性管理 IP アドレスを設定する必要があります。両方のインターフェイスは、管理インターフェイスと同じサブネットにある必要があります。この例では、WLC 1 の冗長性管理 IP アドレスは 10.0.61.21、WLC 2 の冗長性管理 IP アドレスは 10.0.61.23 です。10.0.61.23 が WLC 2 の冗長性管理 IP アドレス、10.0.61.21 が WLC 1 の冗長性管理 IP アドレスになるように設定する必要もあります。
冗長性およびピア冗長性管理 IP アドレスを設定するには次の CLI を使用します。
3. このステップの CLI を使用して、1 つの WLC をプライマリとして設定し（デフォルトでは、WLC HA ユニット ID がプライマリであり、有効な AP-BASE カウント ライセンスがインストールされている必要あり）、もう 1 つの WLC をセカンダリ（プライマリ WLC からの AP ベース カウントをこのユニットで継承）として設定します。この例では、WLC 1 がプライマリとして設定され、WLC 2 がセカンダリとして設定されています。
（注） リリース 7.3 以降でオーダーできるファクトリ オーダー HA SKU である場合は、ユニットをセカンダリとして設定する必要はありません。ファクトリ オーダー HA SKU は、デフォルトのセカンダリ ユニットであり、有効な AP カウント ライセンスを持つアクティブ WLC と初めてペアにされたときに、スタンバイ WLC の役割を引き受けます。
既存の任意の WLC をスタンバイ WLC として変換する場合は、CLI で config redundancy unit secondary コマンドを使用して変換します。この CLI コマンドは、スタンバイとして動作することが意図されている WLC に一定数の永久ライセンス カウントが備わっている場合に限り機能します。この条件は 5500 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。WiSM2、7500、および 8500 などの他の WLC に制約事項はありません。
4. WLC に冗長性管理とピア冗長性管理の IP アドレスを設定し終え、冗長ユニットを設定し終えたら、次に SSO をイネーブルにします。SSO をイネーブルにする前に、両方のコントローラ間の物理接続が存在しており（イーサネット ケーブルを使用し、冗長ポートを介して両方の WLC をバックツーバック接続）、アップリンクもインフラストラクチャ スイッチに接続されていて、両方の WLC からゲートウェイに到達可能であることを確認することが重要です。
SSO をイネーブルにすると、WLC がリブートされます。WLC では、ブート時に、設定に従い冗長ポートを介して HA 役割をネゴシエートします。WLC が冗長ポートを介するか冗長管理インターフェイスを介して相互に到達できない場合、セカンダリとして設定されている WLC はメンテナンス モードに遷移します。メンテナンス モードについては、このドキュメントで後述します。
5. このステップの CLI を使用して AP SSO をイネーブルにします。AP SSO をイネーブルにすると、WLC のリブートが開始されることに留意してください。
6. SSO をイネーブルにすると、実施した設定に従って HA 役割をネゴシエートするために WLC がリブートされます。役割が決定されると、冗長ポートを介してアクティブ WLC からスタンバイ WLC に設定が同期されます。最初に、セカンダリとして設定されている WLC が XML の不一致をレポートし、アクティブから設定をダウンロードして再度リブートします。セカンダリ WLC では、役割が決まった後の次回リブート時に設定を再度検証した上で XML の不一致をレポートせず、スタンバイ WLC として動作するように処理を続行します。
SSO をイネーブルにした後の最初の WLC 2 リブート：
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
アクティブから XML 設定をダウンロードした後の WLC 2 の 2 度目のリブート：
7. SSO をイネーブルにして WLC がリブートされ、XML 設定が同期されると、WLC 1 はアクティブ状態に遷移し、WLC 2 はスタンバイ ホット状態に遷移します。この時点以降は、すべての設定と管理をアクティブ WLC から実施する必要があるため、管理インターフェイス上の WLC 2 用の GUI、Telnet、SSH は機能しません。必要な場合、スタンバイ WLC（この例では WLC 2）は、コンソールまたはサービス ポートを介してのみ管理できます。
また、ピア WLC がスタンバイ ホット状態に遷移すると、-Standby キーワードがスタンバイ WLC のプロンプト名に自動的に追加されます。
a. WLC 1 の場合、[Monitor] > [Redundancy] > [Summary] と移動します。
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
GUI からの HA の設定
1. HA を設定する前に両方のコントローラの管理インターフェイスが同じサブネットに入っている必要があります。
2. HA はデフォルトでディセーブルになっています。HA をイネーブルにする前に、冗長性管理 IP アドレスおよびピア冗長性管理 IP アドレスを設定する必要があります。両方のインターフェイスは、管理インターフェイスと同じサブネットにある必要があります。この例では、WLC 1 の冗長性管理 IP アドレスは 10.0.61.21、WLC 2 の冗長性管理 IP アドレスは 10.0.61.23 です。WLC 2 で、10.0.61.23 が WLC 2 の冗長性管理 IP アドレス、10.0.61.21 が WLC 1 の冗長性管理 IP アドレスになるように設定する必要があります。
両方のインターフェイスの [IP Address] を入力し、[Apply] をクリックします。
3. [Redundant Unit] ドロップダウン リストから、1 つの WLC を [Primary] に、もう 1 つの WLC を [Secondary] に設定します。この例では、WLC 1 が [Primary] として設定され、WLC 2 が [Secondary] として設定されています。設定が終わったら、[Apply] をクリックします。
（注） リリース 7.3 以降でオーダーするファクトリ オーダー HA SKU である場合は、ユニットをセカンダリとして設定する必要はありません。ファクトリ オーダー HA SKU は、デフォルトのセカンダリ ユニットであり、有効な AP カウント ライセンスを持つアクティブ WLC と初めてペアにされたときに、スタンバイ WLC の役割を引き受けます。
既存の任意の WLC をスタンバイ WLC として変換する場合は、CLI で config redundancy unit secondary コマンドを使用して変換します。この CLI は、スタンバイとして動作することが意図されている WLC に一定数の永久ライセンス カウントが備わっている場合に限り機能します。この条件は 5500 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。WiSM2、7500、および 8500 などの他の WLC に制約事項はありません。
4. WLC に冗長性管理とピア冗長性管理の IP アドレスを設定し終え、冗長ユニットを設定し終えたら、次に SSO をイネーブルにします。SSO をイネーブルにする前に、両方のコントローラ間の物理接続が存在しており（イーサネット ケーブルを使用し、冗長ポートを介して両方の WLC をバックツーバック接続）、アップリンクもインフラストラクチャ スイッチに接続されていて、両方の WLC からゲートウェイに到達可能であることを確認することが重要です。
SSO をイネーブルにすると、WLC がリブートされます。WLC では、ブート時に、設定に従い冗長ポートを介して HA 役割をネゴシエートします。WLC が冗長ポートを介するか冗長管理インターフェイスを介して相互に到達できない場合、セカンダリとして設定されている WLC はメンテナンス モードに遷移します。メンテナンス モードについては、このドキュメントで後述します。
5. AP SSO をイネーブルにするには、両方の WLC のドロップダウン リストで [Enabled] を選択し、[Apply] をクリックします。AP SSO をイネーブルにすると、WLC がリブートし、ピア サービス ポート IP、ピア冗長ポート IP などのその他のフィールドにデフォルトの情報が入力されます。
6. SSO をイネーブルにすると、実施した設定に従って HA 役割をネゴシエートするために WLC がリブートされます。役割が決定されると、冗長ポートを介してアクティブ WLC からスタンバイ WLC に設定が同期されます。最初に、セカンダリとして設定されている WLC が XML の不一致をレポートし、アクティブから設定をダウンロードして、再度リブートします。セカンダリ WLC では、役割が決まった後の次回リブート時に設定を再度検証した上で XML の不一致をレポートせず、スタンバイ WLC として機能するように処理を続行します。
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
アクティブから XML 設定をダウンロードした後の WLC 2 の 2 度目のリブート：
7. SSO をイネーブルにして WLC がリブートされ、XML 設定が同期されると、WLC 1 の状態はアクティブに遷移し、WLC 2 の状態はスタンバイ ホットに遷移します。この時点以降は、すべての設定と管理をアクティブ WLC から実施する必要があるため、管理インターフェイス上の WLC 2 用の GUI、Telnet、SSH は機能しません。必要な場合、スタンバイ WLC（この場合は WLC 2）は、コンソールまたはサービス ポートを介してのみ管理できます。
また、ピア WLC がスタンバイ ホット状態に遷移すると、-Standby キーワードがスタンバイ WLC のプロンプト名に自動的に追加されます。
a. WLC 1 の場合、[Monitor] > [Redundancy] > [Summary] と移動します。
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
コンフィギュレーション ウィザードからの HA の設定
1. 2 つの WLC 間の HA もコンフィギュレーション ウィザードからイネーブルにできます。HA をイネーブルにする前に、両方の WLC の管理 IP アドレスを同じサブネットに設定する必要があります。
2. 管理 IP を設定すると、HA をイネーブルにするよう、ウィザードからメッセージが表示されます。HA をイネーブルにするには yes を入力します。その場合は、続いて、プライマリとセカンダリ ユニットおよび冗長性管理とピア管理の IP アドレスを設定します。
• この例では、WLC 1 をプライマリ WLC として設定し、これがアクティブ WLC の役割を引き受けます。WLC 2 はセカンダリとして設定され、スタンバイ WLC の役割を引き受けます。
• プライマリとセカンダリのユニットの入力後に、冗長性管理 IP アドレスおよびピア冗長性管理 IP アドレスを設定する必要があります。両方のインターフェイスは、管理インターフェイスと同じサブネットにある必要があります。この例では、WLC 1 の冗長性管理 IP アドレスは 10.0.61.21、WLC 2 の冗長性管理 IP アドレスは 10.0.61.23 です。WLC 2 で、10.0.61.23 が WLC 2 の冗長性管理 IP アドレス、10.0.61.21 が WLC 1 の冗長性管理 IP アドレスになるように設定する必要があります。
3. コンフィギュレーション ウィザードから HA をイネーブルにした後で、続けて、次のレガシー ウィザード パラメータを設定します。
4. WLC では、ブート時に、実施した設定に従って HA 役割をネゴシエートします。役割が決定されると、冗長ポートを介してアクティブ WLC からスタンバイ WLC に設定が同期されます。最初に、セカンダリとして設定されている WLC が XML の不一致をレポートし、アクティブから設定をダウンロードして、再度リブートします。セカンダリ WLC では、役割が決まった後の次回リブート時に設定を再度検証した上で XML の不一致をレポートせず、スタンバイ WLC として動作するように処理を続行します。
アクティブから XML 設定をダウンロードした後の WLC 2 の 2 度目のリブート：
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
5. HA をイネーブルにし、WLC がリブートして XML 設定が同期されると、WLC 1 はアクティブ状態に遷移し、WLC 2 はスタンバイ ホット状態に遷移します。この時点以降は、すべての設定と管理をアクティブ WLC から実施する必要があるため、管理インターフェイス上の WLC 2 用の GUI、Telnet、SSH は機能しません。必要な場合、スタンバイ WLC（この場合は WLC 2）は、コンソールまたはサービス ポートを介してのみ管理できます。
また、ピア WLC がスタンバイ ホット状態に遷移すると、-Standby キーワードがスタンバイ WLC のプロンプト名に自動的に追加されます。
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
Cisco Prime からの HA の設定
1. HA を設定する前に両方のコントローラの管理インターフェイスを同じサブネットに入れる必要があります。
2. Cisco Prime で個別の管理 IP アドレスを使用して両方のコントローラを追加します。追加した両方の WLC は、[Operate] > [Device Work Center] で表示できます。
3. HA はデフォルトでディセーブルになっています。HA をイネーブルにする前に、冗長性管理 IP アドレスおよびピア冗長性管理 IP アドレスを設定する必要があります。両方のインターフェイスは、管理インターフェイスと同じサブネットにある必要があります。この例では、WLC 1 の冗長性管理 IP アドレスは 10.0.61.21、WLC 2 の冗長性管理 IP アドレスは 10.0.61.23 です。WLC 2 で、10.0.61.23 が WLC 2 の冗長性管理 IP アドレス、10.0.61.21 が WLC 1 の冗長性管理 IP アドレスになるように設定する必要があります。
Cisco Prime から設定するには、[Operate] > [Device Work Center] に移動し、HA を設定するデバイスの前にあるチェックボックスをオンにしてコントローラを選択します。選択した状態で [Configuration] タブをクリックします。このタブには、WLC 1 を設定するために必要なすべてのオプションがあります。この手順を WLC 2 に対して繰り返します。
WLC 1 の HA パラメータを設定するために [Redundancy] > [Global Configuration] に移動し、冗長性とピア冗長性管理 IP アドレスを入力して [Save] をクリックします。
WLC 2 の HA パラメータを設定するために [Redundancy] > [Global Configuration] に移動し、冗長性とピア冗長性管理 IP アドレスを入力して [Save] をクリックします。
4. [Redundant Unit] ドロップダウン リストから、1 つの WLC を [Primary] に、もう 1 つの WLC を [Secondary] に設定します。この例では、WLC 1 が [Primary] として設定され、WLC 2 が [Secondary] として設定されています。設定が終わったら、[Save] をクリックします。
5. WLC に冗長性管理とピア冗長性管理の IP アドレスを設定し終え、冗長ユニットを設定し終えたら、次に SSO をイネーブルにします。SSO をイネーブルにすると、WLC がリブートされます。WLC では、ブート時に、設定に従い冗長ポートを介して HA 役割をネゴシエートします。WLC が冗長ポートを介するか冗長管理インターフェイスを介して相互に到達できない場合、セカンダリとして設定されている WLC はメンテナンス モードに遷移します。メンテナンス モードについては、このドキュメントで後述します。
6. 冗長性モードをイネーブルにするために [Enabled] チェックボックスをオンにし、[Save] をクリックします。冗長性モードをイネーブルにすると WLC がリブートします。
7. SSO をイネーブルにすると、実施した設定に従って HA 役割をネゴシエートするために WLC がリブートされます。役割が決定されると、冗長ポートを介してアクティブ WLC からスタンバイ WLC に設定が同期されます。最初に、セカンダリとして設定されている WLC が XML の不一致をレポートし、アクティブから設定をダウンロードして、再度リブートします。セカンダリ WLC では、役割が決まった後の次回リブート時に設定を再度検証した上で XML の不一致をレポートせず、スタンバイ WLC として機能するように処理を続行します。
SSO をイネーブルにした後の最初の WLC 2 リブート：
（注） SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。
アクティブから XML 設定をダウンロードした後の WLC 2 の 2 度目のリブート：
8. SSO をイネーブルにし、WLC がリブートして XML 設定が同期されると、WLC 1 はアクティブ状態に遷移し、WLC 2 はスタンバイ ホット状態に遷移します。この時点以降は、すべての設定と管理をアクティブ WLC から実施する必要があるため、管理インターフェイス上の WLC 2 用の GUI、Telnet、SSH は機能しません。必要な場合、スタンバイ WLC（この場合は WLC 2）は、コンソールまたはサービス ポートを介してのみ管理できます。
また、ピア WLC がスタンバイ ホット状態に遷移すると、-Standby キーワードがスタンバイ WLC のプロンプト名に自動的に追加されます。
9. HA ペアリングが形成されると、両方の WLC が同じ管理 IP アドレスを持つため、Cisco Prime では、WLC 2 のエントリをデータベースから除去および削除します。このネットワークの場合、これは、ネットワークでアクティブなボックスの 1 つです。
（注） 次の画像を見ると、Cisco Prime で、WLC 1（IP アドレス 10.0.61.2、プライマリ ユニットとして設定）のみがアクティブであることがはっきりわかります。IP アドレス 10.0.61.3 で当初 Cisco Prime に追加された WLC 2 は、HA ペアリングの形成後に Cisco Prime データベースから削除されています。
10. Cisco Prime からアクティブ WLC の冗長性状態を確認するために、[Device Details] > [Redundancy] > [Redundancy States] に移動します。
HA セットアップの WLC のアップグレード
スタンバイ WLC を TFTP サーバまたは FTP サーバから直接アップグレードすることはできません。すべてのスクリプトの実行を終えると、アクティブ WLC がスタンバイ WLC にイメージを転送します。スタンバイ WLC は、アクティブ WLC からイメージを受信すると、アップグレード スクリプトの実行を開始します。イメージ転送とスタンバイ WLC 上でのスクリプト実行のすべてのログは、アクティブ WLC で参照できます。
（注） FUS イメージは、コントローラがイネーブルにされた状態でアップグレードできます。セカンダリ コントローラは通常のコードをアップグレードするときと同様にアップグレードされます。ただし、プライマリ コントローラでリブートを開始した場合、FUS のアップグレードが HA ペアのアクティブとスタンバイの両方で完了するまで、両方のコントローラが到達不能になります。このプロセスは、非 HA FUS のアップグレードと同様に、完了までに約 30 ～ 40 分かかります。
HA セットアップでのアップグレード手順
1. HA セットアップに WLC を設定した後は、TFTP サーバや FTP サーバからスタンバイ WLC を直接アップグレードできません。
2. CLI または GUI から HA セットアップのアクティブ WLC のアップグレードを開始し、アップグレードが完了するまで待ちます。
3. すべてのアップグレード スクリプトを実行し終えたアクティブ WLC では、冗長ポートを介してイメージ全体をスタンバイ WLC に転送します。
4. スタンバイ WLC は、アクティブ WLC からイメージを受信すると、アップグレード スクリプトの実行を開始します。スタンバイへのイメージの転送およびスタンバイ WLC でのアップグレード スクリプトの実行は、アクティブ WLC のコンソール、Telnet、SSH、HTTP 接続で参照できます。
5. スタンバイ アップグレードの正常終了を示すメッセージがアクティブ WLC に表示されたら、新しいイメージがプライマリ イメージとして設定されていることを確認するために、アクティブ WLC で show boot コマンドを発行することが重要です。
6. 確認できたら、ネットワーク内のすべての AP に新しいイメージを転送するために、アクティブ WLC でプライマリ イメージのプレダウンロードを開始します。
7. すべての AP でプレイメージが完了したら、show ap image all コマンドを発行して、WLC 上のプライマリ イメージが AP でバックアップ イメージとして設定されていることを確認します。
8. AP でプライマリとしてバックアップ イメージを交換するために、swap オプションを開始します。この実装では、WLC および AP のプライマリ イメージが新しいイメージに設定されます。
9. 新しいイメージでブートできるように AP および WLC をリセットするために、計画された停止に従って「no swap オプション」を付けた schedule-reset コマンドを発行します。
10. スタンバイ WLC は、スケジュールされたリセット時刻のちょうど 1 分前にリセットされてブートし、新しいイメージを使用してネットワークを引き継ぐために最初に起動します。
11. すべての AP がリブートして新しいアクティブ WLC に接続し、前のアクティブ WLC はスタンバイ役割に遷移します。
12. show boot、show sysinfo、show ap image all、および show redundancy summary コマンドを発行して、WLC と AP の両方が新しいイメージを使用してブートされていることを確認します。
HA セットアップに含まれる WLC のアップグレードを開始する前の重要なガイドライン
• サービス アップグレードはこのリリースではサポートされていません。したがって、HA セットアップの WLC をアップグレードする前にネットワーク停止時間を計画する必要があります。
• HA セットアップでのアップグレードを開始する前に、ピアがホット スタンバイ状態になっている必要があります。
• ソフトウェア バージョンの不一致がないように、アップグレード後に両方の WLC をほとんど同時にリブートすることをお勧めします。
• [Schedule Reset] は、HA セットアップの両方の WLC に適用されます。ピア WLC は、アクティブ WLC でスケジュールされたタイマーの期限が切れる 1 分前にリブートします。
• スケジュールされたリセットが計画されていない場合、スタンバイ WLC は、reset peer-system コマンドを使用してアクティブ WLC からリブートできます。
• デバッグ転送は、アクティブ WLC でもスタンバイ WLC でもイネーブルにできます。
• アクティブ WLC がダウンロードする際に突然再起動し、両方 WLC を再起動すると、アップグレードを実行する際は、WLC を再起動する必要があります。
HA セットアップでのファクトのダウンロードおよびアップロード
• スタンバイ WLC から設定を直接ダウンロードまたはアップロードすることはできません。
• イメージ、設定、Web 認証バンドル、署名ファイルなどすべてのタイプのダウンロード ファイルがまずアクティブ WLC にダウンロードされ、自動的にスタンバイ WLC にプッシュされます。
• アクティブ WLC にダウンロードされたコンフィギュレーション ファイルは、スタンバイ WLC にプッシュされます。この結果は、まずスタンバイ WLC がリセットされ、続いてアクティブ WLC がリセットされます。
• ピア サービス ポートおよびスタティック ルート設定は異なる XML ファイルの一部であり、コンフィギュレーション ファイルの一部としてダウンロードされても適用されません。
• 証明書のダウンロードは、各ボックスで別々に実行する必要があり、ペアリングの前に実行する必要があります。
• 設定、イベント ログ、クラッシュ ファイルなどのさまざまなファイル タイプのアップロードは、スタンバイ WLC から別々に実行できます。一方、サーバ IP、ファイル タイプ、パスと名前などアップロード用のさまざまなパラメータを設定するための CLI は、アクティブ WLC で実行する必要があります。アクティブ WLC でアップロード パラメータを設定し終えたら、スタンバイ WLC からのアップロードを開始するために、アクティブ WLC で transfer upload peer-start コマンドを発行する必要があります。
• サービス ポートの状態は、アクティブ WLC からスタンバイ WLC に同期されます。つまり、アクティブ WLC サービス ポートで DHCP がイネーブルにされている場合は、スタンバイ WLC でも DHCP を使用してサービス ポートの IP アドレスを取得します。アクティブ WLC のサービス ポートがスタティック IP アドレスを使用して設定されている場合は、スタンバイ WLC も別のスタティック IP アドレスを使用して設定する必要があります。スタンバイ WLC サービス ポートの IP アドレスを設定する CLI は、 configure redundancy interface address peer-service-port <IP Address> です。このコマンドは、アクティブ WLC から実行する必要があります。また、スタンバイ WLC で、アウトオブバンド管理のためのルートをサービス ポートに設定するには、アクティブ WLC から configure redundancy peer-route add <Network IP Address > <IP Mask> <Gateway> コマンドを発行します。
HA セットアップでのフェールオーバー プロセス
HA セットアップでは、AP の CAPWAP 状態は、アクティブ WLC およびスタンバイ WLC で維持されます（Run 状態の AP に限る）。つまり、Up Time および Association Up Time は両方の WLC で維持され、スイッチオーバーが開始されるとスタンバイ WLC がネットワークを引き継ぎます。この例では、WLC 1 がアクティブ状態でネットワークを処理しており、WLC 2 がスタンバイ状態でアクティブ WLC をモニタしています。WLC 2 はスタンバイ状態ですが、まだ AP の CAPWAP 状態を維持します。
HA セットアップでの WLC フェールオーバーは、2 つの異なるセクションに分類できます。
ボックス フェールオーバー（アクティブ WLC のクラッシュ、システム ハング、手動リセット、強制スイッチオーバー）の場合は、冗長ポートを介してアクティブ WLC から直接コマンドが送信され、ネットワークを引き継ぐために冗長管理インターフェイスからスタンバイ WLC にも送信されます。この処理には、ネットワーク内の AP の数に応じて、5 ～ 100 ミリ秒かかります。アクティブ WLC の電源障害またはスイッチオーバーのための直接コマンドを送信できない何らかのクラッシュの場合は、ネットワーク内の AP の数に応じて 350 ～ 500 ミリ秒かかります。
アクティブ ボックスの電源障害の場合にフェールオーバーにかかる時間も WLC に設定されているキープアライブ タイマーに依存します（デフォルトでは 100 ミリ秒に設定）。フェールオーバーを決めるために使用されるアルゴリズムを次に示します。
• スタンバイ WLC はアクティブ WLC にキープアライブを送信し、デフォルト タイマーに従い 100 ミリ秒以内に確認応答があることを期待します。この時間は、100 ～ 400 ミリ秒の範囲で設定できます。
• 100 ミリ秒以内にキープアライブの確認応答がない場合、スタンバイ WLC では、ボックス フェールオーバーであるのか冗長ポート接続に関する何らかの問題であるのかを確認するために、冗長管理インターフェイスを介してアクティブ WLC に即座に ICMP メッセージを送信します。
• ICMP メッセージに対する応答がない場合、スタンバイ WLC は積極性を増してスタンバイ WLC に別のキープアライブ メッセージを即座に送信し、25 % 減らした時間（つまり、100 ミリ秒を 25 % 短くした 75 ミリ秒）以内の確認応答を期待します。
• 75 ミリ秒以内にキープアライブの確認応答がない場合、スタンバイ WLC は、冗長管理インターフェイスを介してアクティブ WLC に別の ICMP メッセージを即座に送信します。
• 同様に、2 つ目の ICMP メッセージに対する応答がない場合、スタンバイ WLC はさらに積極性を増し、別のキープアライブ メッセージを即座にスタンバイ WLC に送信して、最新のキープアライブ タイマーから実際のタイマーの 25 % をさらに削減した時間（つまり、最新のキープアライブ タイマー 75 ミリ秒から 100 ミリ秒の 25 % を短くした 50 ミリ秒）以内の確認応答を期待します。
• 50 ミリ秒以内に 3 つ目のキープアライブ パケットの確認応答がない場合、スタンバイ WLC は、冗長管理インターフェイスを介してアクティブ WLC に別の ICMP メッセージを即座に送信します。
• 最後に、3 つ目の ICMP パケットからの応答がない場合、スタンバイ WLC ではアクティブ WLC は停止していると宣言し、アクティブ WLC の役割を引き受けます。
ネットワーク フェールオーバー（つまり、何らかの理由によりアクティブ WLC がゲートウェイに到達不能）の場合は、ネットワーク内の AP の数に応じてスイッチオーバーの完了まで 3 ～ 4 秒かかることがあります。
ボックス フェールオーバーのシミュレート手順
1. 設定のセクションで説明されている手順を実行して 2 つの WLC 間に HA を設定し、強制スイッチオーバーが開始される前に、両方の WLC がアクティブ WLC とスタンバイ WLC としてペアになっていることを確認します。
2. AP を WLC に関連付け、両方の WLC で AP のステータスを確認します。HA セットアップでは、AP データベースのミラー コピーが両方の WLC で維持されます。つまり、AP の CAPWAP 状態がアクティブとスタンバイの WLC で維持され（Run 状態の AP に限る）、スイッチオーバーが開始されるとスタンバイ WLC がネットワークを引き継ぎます。この例では、WLC 1 がアクティブ WLC、WLC 2 がスタンバイ状態であり、AP データベースは両方の WLC で維持されています。
3. オープンな WLAN を作成し、クライアントを関連付けます。クライアント データベースはスタンバイ WLC で同期されないため、クライアント エントリはスタンバイ WLC には存在しません。WLAN をアクティブ WLC に作成すると、この WLAN も冗長ポートを介してスタンバイ WLC に同期されます。
4. アクティブ WLC で redundancy force-switchover コマンドを発行します。このコマンドを発行すると、アクティブ WLC がリブートしてスタンバイ WLC がネットワークを引き継ぐ手動スイッチオーバーがトリガーされます。この場合、アクティブ WLC 上のクライアントは認証解除され、新しいアクティブ WLC に接続し直します。
（注） この例では、プロンプトが 5508-Standby から 5508 に変わります。これは、この WLC がアクティブ WLC になったためであり、AP スイッチオーバーにかかった時間は 1 ミリ秒です。
当初スタンバイ WLC になっていて、スイッチオーバー後にアクティブ WLC になった WLC 2 の AP の CAPWAP 状態を確認してください。AP Up Time および Association Up Time が維持されており、AP は Discovery 状態になりませんでした。
次のマトリクスを参照すると、WLC スイッチオーバーのトリガー条件がはっきりとわかります。
HA ファクト
• HA ペアリングは、同じタイプのハードウェアとソフトウェア バージョンの間でだけ可能です。不一致があると、メンテナンス モードが開始されることがあります。SSO を設定する前に、両方の WLC で仮想 IP アドレスが同一である必要があります。
• 5500/7500/8500 シリーズの WLC の場合は、アクティブとスタンバイの冗長ポートの直接接続をお勧めします。
• WiSM-2 WLC は、同じ 6500 シャーシに設置する必要がありますが、パフォーマンスの信頼性を高めるために VSS セットアップに設置することもできます。
• HA 設定に先立って、冗長ポートとインフラストラクチャ ネットワークの間を物理的に接続する必要があります。
• 別の HA セットアップまたは独立したコントローラとのモビリティ ピアを形成するために、プライマリ ユニットの MAC を HA セットアップでモビリティ MAC として使用する必要があります。柔軟性があり、カスタム MAC アドレスを設定することもできます。このアドレスは、 configure redundancy mobilitymac <custom mac address> コマンドを使用してモビリティ MAC アドレスとして使用できます。設定した場合は、システム MAC アドレスの代わりにこの MAC アドレスを使用してモビリティ ピアを形成する必要があります。HA の設定後はこの MAC を変更できません。
• HA セットアップのサービス ポートには、DHCP アドレス割り当てを使用することをお勧めします。HA をイネーブルにした後でサービス ポートのスタティック IP を設定すると、WLC でサービス ポート IP が不明になり、再度設定する必要があります。
• SSO をイネーブルにした場合は、HA セットアップのいずれの WLC についても、サービス ポートでの SNMP と GUI のアクセスはありません。
• 仮想 IP アドレスの変更、セキュアな Web モードのイネーブル化、Web 認証プロキシの設定などの設定を実装するには、WLC のリブートが必要です。この場合は、アクティブ WLC のリブートによって、スタンバイ WLC の同時リブートもトリガーされます。
• アクティブ WLC で SSO をディセーブルにすると、これが、スタンバイ WLC にプッシュされます。リブート後は、すべてのポートがアクティブ WLC に表示され、スタンバイ WLC ではディセーブルになります。
• 優れたパフォーマンスを得るには、キープアライブと Peer Discovery のタイマーをデフォルト タイマー値のままにする必要があります。
• アクティブ WLC で設定をクリアすると、スタンバイ WLC での設定のクリアも開始されます。
• SSO をイネーブルにしてある場合、内部 DHCP はサポートされません。
• LSC AP の SSO はサポートされていません。L2 MGID は同期されますが、L3 MGID データベースは SSO ではクリアされます。
レガシーのプライマリ、セカンダリ、ターシャリ HA と合わせた SSO 導入
HA（つまり AP SSO）は、現状同様に、セカンダリおよびターシャリのコントローラと組み合わせて導入できます。HA セットアップで組み合わされているアクティブとスタンバイの両方の WLC をプライマリ WLC として設定する必要があります。AP は、HA セットアップのアクティブとスタンバイの両方の WLC が故障したときに限り、セカンダリ、さらにはターシャリの WLC にフォールバックします。
モビリティ セットアップでの SSO 導入
各 WLC は独自の一意の MAC アドレスを持ちます。このアドレスは、個々のコントローラ管理 IP アドレスと合わせてモビリティ設定で使用されます。HA（つまり AP SSO）セットアップでは、両方の WLC（プライマリおよびスタンバイ）が独自の一意の MAC アドレスを持ちます。プライマリ ボックスが故障し、スタンバイがネットワークを引き継ぐ場合に、プライマリ ボックスの MAC アドレスがモビリティ セットアップの別のコントローラで使用されていると、制御パスおよびデータ パスが切断され、ユーザは、モビリティ セットアップのすべてのコントローラでこの MAC をスタンバイ MAC アドレスに手動で変更する必要があります。手動による多数の介入を必要とするため、この処理は実に厄介です。
手動による介入なしにモビリティ ネットワークの安定性を保ち、故障またはスイッチオーバーに備えるために、交互（back-and-forth）モビリティ MAC 概念が導入されました。HA ペアを設定する場合、デフォルトでは、プライマリ WLC の MAC アドレスがモビリティ MAC アドレスとしてスタンバイ WLC で同期され、両方のコントローラで show redundancy summary コマンドによって参照できます。
スタンバイ コントローラでキャプチャされたこの出力ではモビリティ MAC アドレスを確認できます。これは、Unit ID として示されているスタンバイの MAC アドレスとは異なります。この MAC アドレスは、アクティブ WLC から同期されており、モビリティ設定で使用する必要があります。この実装では、アクティブ WLC が停止する場合、または交換する場合であっても、モビリティ MAC アドレスは引き続きスタンバイ WLC で使用可能で、アクティブです。前のアクティブ WLC を交換するために新しいコントローラをネットワークに導入する場合、このコントローラの状態はスタンバイに遷移し、同じモビリティ MAC アドレスが新しいスタンバイ WLC と再度同期されます。
この設定には柔軟性があり、アクティブ WLC の MAC アドレスをモビリティ MAC として使用するデフォルトの動作に代えて、カスタム MAC アドレスをモビリティ MAC として設定できます。これは、アクティブ WLC で configure redundancy mobilitymac <custom mac address> コマンドを使用して実施できます。設定後は、もう一方のコントローラでアクティブ WLC の MAC アドレスを使用する代わりにこの MAC アドレスを使用してモビリティ ピアを形成する必要があります。この MAC アドレスは、HA ペアを形成する前に設定する必要があります。HA ペアの形成後は、モビリティ MAC を変更、編集できません。
このトポロジでは、プライマリとスタンバイは、それぞれ独自の MAC アドレスを持ちます。HA ペアリングでは、アクティブ WLC の MAC アドレスがモビリティ MAC アドレスとして同期されます。これは、HA ペアリングの前にカスタム MAC が設定されていない場合のデフォルトの動作です。アクティブ WLC の MAC アドレスがモビリティ MAC アドレスとして同期された後は、モビリティ セットアップのすべてのコントローラの同じモビリティ設定で MAC を使用します。
HA ペアのライセンス
HA ペアは、次の組み合わせで稼働している 2 つの WLC 間に設定できます。
• 1 つの WLC に有効な AP カウント ライセンスがあり、もう 1 つの WLC に HA SKU UDI がある
• 両方の WLC に有効な AP カウント ライセンスがある
• 1 つの WLC に評価ライセンスがあり、もう 1 つの WLC に HA SKU UDI または永久ライセンスがある
1 つの WLC に有効な AP カウント ライセンスがあり、もう 1 つの WLC に HA SKU UDI がある
• HA SKU は AP カウント ライセンスがゼロの新しい SKU です。
• HA SKU を持つデバイスは、初めてペアになるときにスタンバイになります。
• AP カウント ライセンス情報は、アクティブからスタンバイにプッシュされます。
• アクティブが故障した場合、HA SKU では、取得した AP カウントを使用して AP が接続でき、90 日間のカウントダウンを開始します。このカウントダウンは、日単位です。
• 90 日間が経過すると、頻繁なメッセージの出力を開始します。接続されている AP を切断することはありません。
• 新しい WLC がアップすると、ペアリング時点の HA SKU が AP カウントを取得します。
– 新しい WLC の AP カウントが前の WLC よりも大きい場合、90 日のカウンタはリセットされます。
– 新しい WLC の AP カウントが前の WLC よりも小さい場合、90 日のカウンタはリセットされません。
– スイッチオーバー後に AP カウントを下げるために、WLC オフセット タイマーが続行され、時間の経過後に頻繁なメッセージを表示します。
両方の WLC に有効な AP カウント ライセンスがある
• 最小永久ライセンス カウント要件を満たしているのであれば、CLI を使用して、1 つの WLC をスタンバイ WLC として設定する必要があります（設定のセクションを参照）。この条件は 5500 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。WiSM2、7500、および 8500 などの他の WLC に制約事項はありません。
• AP カウント ライセンス情報は、アクティブからスタンバイにプッシュされます。
• スイッチオーバーの場合、新しいアクティブ WLC は前のアクティブ WLC のライセンス カウントを使用して動作し、90 日のカウントダウンを開始します。
• セカンダリとして設定されている WLC は、インストールされている独自のライセンスを使用せず、アクティブから継承したライセンスのみを利用します。
• 90 日間が経過すると、頻繁なメッセージの出力を開始します。接続されている AP を切断することはありません。
• 新しい WLC がアップすると、ペアリング時点の HA SKU が AP カウントを取得します。
– 新しい WLC の AP カウントが前の WLC よりも大きい場合、90 日のカウンタはリセットされます。
– 新しい WLC の AP カウントが前の WLC よりも小さい場合、90 日のカウンタはリセットされません。
– 小さい AP カウントへのスイッチオーバーの後も WLC オフセット タイマーは続行されて、時間の経過後に頻繁なメッセージを表示します。
1 つの WLC に評価ライセンスがあり、もう 1 つの WLC に HA SKU UDI または永久ライセンスがある
• HA SKU を持つデバイスは、評価ライセンスを実行している既存のアクティブ WLC と初めてペアになるときに、スタンバイ WLC になります。または、最小永久ライセンス カウント要件を満たしていれば、CLI 設定を使用して、永久ライセンス カウントを実行している任意の WLC をセカンダリ ユニットとして設定できます。この条件は 5500 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。WiSM2、7500、および 8500 などの他の WLC に制約事項はありません。
• AP カウント ライセンス情報は、アクティブからスタンバイにプッシュされます。
• スイッチオーバーの場合、新しいアクティブ WLC は前のアクティブ WLC のライセンス カウントを使用して動作し、90 日のカウントダウンを開始します。
• 90 日間が経過すると、頻繁なメッセージの出力を開始します。接続されている AP を切断することはありません。
• 新しい WLC がアップすると、ペアリング時点の HA SKU が AP カウントを取得します。
– 新しい WLC の AP カウントが前の WLC よりも大きい場合、90 日のカウンタはリセットされます。
– 新しい WLC の AP カウントが前の WLC よりも小さい場合、90 日のカウンタはリセットされません。
– 小さい AP カウントへのスイッチオーバーの後も WLC オフセット タイマーは続行されて、時間の経過後に頻繁なメッセージを表示します。
リリース 7.5 のハイ アベイラビリティ
サービスに影響を与えずにハイ アベイラビリティをサポートするには、アクティブ コントローラからスタンバイ コントローラへのクライアントおよび AP のシームレスな遷移をサポートすることが必要となります。リリース 7.5 では、クライアント ステートフル スイッチ オーバー（クライアント SSO）をワイヤレス LAN コントローラでサポートします。クライアント SSO がサポートされるのは、すでに認証および DHCP フェーズが完了し、トラフィックを通しはじめたクライアントです。SSO クライアントによって、WLC にクライアントが関連付けられたときまたはクライアントのパラメータが変更されたときに、クライアント情報はスタンバイ WLC へ同期します。完全に認証済みのクライアント（Run 状態のクライアントなど）はスタンバイへと同期され、スイッチオーバー時のクライアントの再関連付けは回避されます。これによりクライアントと AP のフェールオーバーはシームレスになり、クライアント サービスのダウンタイム ゼロと SSID の非停止が実現します。
7.5 の冗長ポート接続
• リリース 7.3 と 7.4 のコントローラでは、冗長ポートを介したバックツーバック接続が、異なる場所にあるアクティブ コントローラとスタンバイ コントローラを抑制していました。冗長性には、冗長ポートおよび冗長管理インターフェイスという 2 種類の必須インターフェイスがあります。冗長ポートは、専用物理ポート eth1 を使用します（サービス ポートと類似）。これは、すべての冗長性通信（AP、クライアント データ、設定同期、キープアライブ メッセージおよびロール ネゴシエーション メッセージ）に使用されます。ピアと管理ゲートウェイの到達可能性を確認するために冗長性管理インターフェイスが使用されます。
• 異なるデータセンターにあるアクティブおよびスタンバイの WLC をサポートするため、リリース 7.5 では、ピア間のバックツーバック冗長ポート接続は必須でなくなり、2 つのコントローラ間に L2 隣接関係がある場合のように、コントローラ間冗長ポートをスイッチ経由で接続できるようになりました。
• リリース 7.3/7.4 との下位互換性もサポートされます。この場合、バックツーバック冗長ポート接続は WLC 間の冗長通信に使用され、冗長性管理インターフェイスはピアおよび管理ゲートウェイの到達可能性の確認に使用されます。
サポートされる HA トポロジ
5500/7500/8500 シリーズ コントローラ
1. 2 つの WLC 間のバックツーバック冗長ポート（RP）接続、冗長性管理インターフェイス（RMI）接続でピアと管理ゲートウェイの到達可能性をチェック。
2. 2 つの WLC 間の L2 隣接の RP 接続、RMI 接続でピアと管理ゲートウェイの到達可能性をチェック。同じデータセンター内にある場合と、異なるデータセンターにある場合があります。
3. VSS ペアに接続された 2 台の 5508、7500 または 8500。プライマリ WLC が 1 台の 6500 に、スタンバイ WLC がもう 1 台の 6500 に接続。
バックツーバック RP 接続
• これは、コントローラのリリース 7.3 でサポートされたトポロジと同じです。
• 設定同期とキープアライブ メッセージは冗長ポートから送信されます。
• RMI インターフェイスは管理サブネットの一部として作成され、ピアと管理ゲートウェイの到達可能性を検査するために使用されます。
• RTT 遅延はデフォルトで 80 ミリ秒です。RTT は、100 ～ 400 ミリ秒の範囲で設定可能なキープアライブ タイマーの 80% にする必要があります。
• 障害検出時間は 3 * 100 = 300 + 60 = 360 + ジッター（12 ミリ秒）= ～ 400 ミリ秒。
configure interface address management 10.0.56.2 255.255.255.0 10.0.56.1
configure interface address redundancy-management 10.0.56.10 peer-redundancy-management 10.0.56.11
configure redundancy unit primary
configure interface address management 10.0.56.3 255.255.255.0 10.0.56.1
configure interface address redundancy-management 10.0.56.11 peer-redundancy-management 10.0.56.10
スイッチを介した RP 接続
• データセンターをまたぐ、スイッチを介した冗長ポート接続はこのトポロジでサポートされます。
• RMI インターフェイスは管理サブネットの一部として作成され、ピアと管理ゲートウェイの到達可能性を検査するために使用されます。
• RTT 遅延はデフォルトで 80 ミリ秒です。RTT は、100 ～ 400 ミリ秒の範囲で設定可能なキープアライブ タイマーの 80% にする必要があります。
• 障害検出時間は 3 * 100 = 300 + 60 = 360 + ジッター（12 ミリ秒）= ～ 400 ミリ秒
configure interface address management 10.0.56.2 255.255.255.0 10.0.56.1
configure interface address redundancy-management 10.0.56.10 peer-redundancy-management 10.0.56.11
configure redundancy unit primary
configure interface address management 10.0.56.3 255.255.255.0 10.0.56.1
configure interface address redundancy-management 10.0.56.11 peer-redundancy-management 10.0.56.10
別のシャーシ内の WiSM2：L2 ネットワークによる冗長 VLAN
図 5 L2 ネットワークによる冗長 VLAN を使用した WiSM2 接続
wism service-vlan 192（サービス ポート VLAN）
wism redundancy-vlan 169（冗長ポート VLAN）
推奨事項
• 冗長リンクのラウンドトリップ遅延は、80 ミリ秒以下にする必要があります。
• 冗長リンクの帯域幅は 60 Mbps 以上である必要があります。
• 2 台のコントローラ間に L2 隣接があるといった、冗長ポートがスイッチを介して接続されている場合、RP VLAN は管理ポートのスイッチに設定されたアクセス VLAN から除外する必要があります。
• L2 ネットワーク経由で接続される 2 種類のシャーシ間の WiSM2 接続の場合、「redundancy vlan」が管理ポートのスイッチに設定されたアクセス VLAN から除外される必要があります。
• アクティブ-アクティブ シナリオを回避するため、RP ポート接続と管理ポートのトラフィックに、異なるスイッチ セットを使用することを強く推奨します。
クライアント SSO（クライアント ステートフル スイッチオーバー）
サービスに影響を与えずにハイ アベイラビリティをサポートするには、アクティブ コントローラからスタンバイ コントローラへのクライアントおよび AP のシームレスな遷移のサポートが必要です。リリース 7.5 では、クライアント ステートフル スイッチ オーバー（クライアント SSO）をワイヤレス LAN コントローラでサポートします。クライアント SSO は、すでに認証および DHCP フェーズが完了し、トラフィックを通しはじめたクライアントにサポートされます。クライアント SSO では、クライアントまたはクライアントの関連パラメータが変更されたときに、クライアントの情報がスタンバイ WLC に同期されます。Run 状態のクライアントなどの完全に認証されたクライアントはスタンバイに同期され、こうしてスイッチオーバー時のクライアント再関連付けが回避され、クライアントに加え AP のフェールオーバーをシームレスにします。
• クライアント SSO は、ゲスト アンカー シナリオに加え、アンカー外部モビリティ セットアップでも機能します。
• L3 MGID はスタンバイ コントローラにシンクされます。
• フェールオーバー時間は、ボックス フェールオーバーのカテゴリによって異なり、2 ～ 996 ミリ秒です。
• 管理ゲートウェイのフェールオーバー時間は、ほぼ～ 15 秒で、これは管理ゲートウェイへの 12 回の ping の時間です。
• 2 つの WLC 間のデフォルト RTT 遅延は 80 ミリ秒です。RTT 遅延は、キープアライブ タイマーの 80% 以下である必要があります。キープアライブ タイマーは 100 ～ 400 ミリ秒の範囲で設定できます。
設定
1. HA を設定する前に両方のコントローラの管理インターフェイスを同じサブネットに入れる必要があります。
2. HA はデフォルトでディセーブルになっています。HA をイネーブルにする前に、冗長管理 IP アドレスおよびピア冗長管理 IP アドレスを設定する必要があります。両方のインターフェイスが、管理インターフェイスと同じサブネットにある必要があります。
冗長管理とピア冗長管理 IP アドレスを設定するには、[Controller tab] > [Redundancy] > [Global Configuration] をクリックし、両方のフィールドに IP アドレスを入力してから、[Apply] をクリックします。
3. [Redundant Unit] ドロップダウンで、1 台のコントローラを [Primary]、もう 1 台のコントローラを [Secondary] に設定します。下の例では、WLC 1 が [Primary Unit]、WLC 2 が [Secondary Unit]（HA SKU UDI として動作）に設定されています。ペアリングの間、プライマリとして設定されたコントローラは、その AP カウント ライセンスをスタンバイ WLC にプッシュします。1 台のコントローラをプライマリ ユニット、2 番めのコントローラをセカンダリ ユニットとして設定するには、[Controller tab] > [Redundancy] > [Global Configuration] とクリックし、[Redundant Unit] ドロップダウンから [Primary]/[Secondary] を選択して [Apply] をクリックします。
4. 冗長管理、ピア冗長管理 IP アドレス、冗長ユニットがコントローラに設定された後に、WLC など両方のコントローラが冗長ポートを介して接続されたイーサネットによる物理接続が有効になっていること、アップリンクもインフラストラクチャ スイッチに接続されていること、およびゲートウェイが両方の WLC から接続可能であることを確認するのは非常に重要です。両方のコントローラから管理インターフェイス ゲートウェイの IP アドレスに ping を発効して、管理ゲートウェイの到達可能性に問題がないことを確認します。
5. SSO をイネーブルにするには、[Controller] >[Redundancy] > [Global Configuration] と移動し、両方の [SSO] ドロップダウン リストから [Enable] オプションを選択して [Apply] をクリックします。この手順では、コントローラがリブートします。
6. SSO をイネーブルにすると、設定に対して HA ロールをネゴシエートするためにコントローラはリブートし、ロールが決定されると、設定がアクティブ WLC からスタンバイ WLC に冗長ポート経由で同期されます。当初セカンダリとして設定されたコントローラは、アクティブからの設定ダウンロードの後に XML の不一致をレポートし、再度リブートします。セカンダリ WLC は、ロール決定後の次回リブート時に設定を再度検証し、XML の不一致をレポートせず、スタンバイ WLC として機能するように処理を続行します。このように、プライマリとして設定されたコントローラは 1 回リブートし、セカンダリとして設定されたコントローラは 2 回リブートします。
SSO をイネーブルにした後の最初の WLC 2 リブート：
アクティブから XML 設定をダウンロードした後の WLC 2 の 2 度目のリブート：
WLC2 が起動している間、WLC1 の設定を変更することはできません。
7. SSO をイネーブルにし、コントローラがリブートして XML 設定が同期されると、WLC 1 はアクティブ状態に遷移し、WLC 2 はスタンバイ ホット状態に遷移します。この時点以降は、すべての設定をアクティブ コントローラから実施する必要があるため、管理インターフェイス上の WLC 2 用の GUI、Telnet、SSH は機能しません。スタンバイ コントローラ（この場合 WLC 2）は、必要な場合、コンソールまたはサービス ポート経由でのみ管理できます。
また、ピア WLC がスタンバイ ホット状態に遷移すると、-Standby キーワードがスタンバイ WLC のプロンプト名に自動的に追加されます。
WLC 1 -> [Monitor] > [Redundancy] > [Summary] とクリック：
WLC 1 -> show redundancy summary：
WLC 2 -> show redundancy summary：
AP とクライアントの状態の同期
1. この段階では、両方のコントローラが HA セットアップでペアになります。アクティブで実施した設定はすべて、冗長ポート経由でスタンバイ コントローラに同期されます。コンソール接続から、スタンバイ WLC の WLAN サマリーとインターフェイス サマリーを確認します。
2. ハイ アベイラビリティのセットアップでは、UP Time や Association UP time など、アクティブ コントローラおよびスタンバイ コントローラ（Run 状態の AP のみ）に維持されている AP の CAPWAP の状態が、アクティブ コントローラからスタンバイ コントローラに同期されます。以下の例では、WLC 1 がアクティブ状態でネットワークを処理しており、WLC 2 がスタンバイ状態でアクティブ コントローラをモニタしています。WLC 2 はスタンバイ状態ですが、まだ AP の CAPWAP 状態を維持します。
アクティブ WLC の AP UP Time および Association UP Time を監視します
スタンバイ WLC の AP Up Time および Association UP Time がアクティブ WLC と同期するのを監視します。
3. ボックス フェールオーバー（アクティブ コントローラのクラッシュ/システム ハング/手動リセット/強制スイッチオーバー）の場合、ネットワークの引き継ぎのため、ダイレクト コマンドが冗長管理インターフェイスからスタンバイ コントローラに送られ、冗長ポート経由でアクティブ コントローラからも送られます。フェールオーバーは、アクティブ コントローラの AP/クライアントの数によって 2 ～ 360 ミリ秒かかります。アクティブ WLC に電源障害またはスイッチオーバーのダイレクト コマンドをスタンバイ コントローラに送信できない何らかのクラッシュが発生した場合は、360 ～ 990 ミリ秒かかり、アクティブ コントローラの AP/クライアントの数および設定されたキープアライブ タイマーによって変わります。デフォルトのキープアライブ タイマーは 100 ミリ秒です。デフォルト RTT 遅延が 80 ミリ秒以下であることを確認します。
4. クライアント SSO の一部として、リリース 7.5 では、クライアント データベースもスタンバイ WLC に同期され、スタンバイ WLC には Run 状態のクライアント エントリが出現します。
5. PMK キャッシュも 2 台のコントローラ間で同期されます。
フェールオーバー プロセス
1. アクティブ コントローラで redundancy force-switchover コマンドを発行します。このコマンドを発行すると、アクティブ コントローラがリブートしてスタンバイ コントローラがネットワークを引き継ぐ手動スイッチオーバーがトリガーされます。この場合、アクティブ WLC の Run 状態のクライアントは、認証解除されません。コマンド save config が redundancy force-switchover コマンドの前に発行されます。
当初はスタンバイでスイッチオーバー後にアクティブになった WLC 2 で AP CAPWAP State を監視します。AP Up Time および Association Up Time は維持され、AP は Discovery 状態になりませんでした。
2. また、スイッチオーバーが開始されるときのクライアント接続にも注意します。クライアントは、認証解除されません。
スイッチオーバー中の無線クライアントからゲートウェイ IP アドレスと管理 IP アドレスへの ping は、最小の損失を示します。
WLC 1 -> コンソール接続でコマンド show redundancy summary を発行：
WLC 2 -> コンソール接続でコマンド show redundancy summary を発行：
WLC 2 -> [Monitor] > [Redundancy] > [Summary] とクリック：
4. 現在のアクティブ WLC への強制的な再スイッチオーバーを開始します。
プライマリ ユニットとして設定された WLC がアクティブになり、セカンダリ ユニットとして設定された WLC 2 はホット スタンバイ状態になる必要があります。
WLC 1 > スイッチオーバー後に WLC 1 のローカル状態がアクティブ、ユニットがプライマリになっていることを確認します。
スイッチオーバー履歴を監視します。WLC は、10 回のスイッチオーバー履歴を原因とともに保持します。
クライアント SSO の動作と制限
• サービスおよびサービスに関連付けられたサービス プロバイダーおよびドメイン名データベースからなる Bonjour ダイナミック データベースがスタンバイに同期されます。
• Run 状態にあるクライアントだけが、アクティブとスタンバイの WLC 間で同期されます。クライアント SSO は、コントローラの関連付け/join プロセス中にあるクライアントのシームレスな遷移をサポートしません。遷移段階のクライアントはスイッチオーバーの後に認証解除され、コントローラに再度 join する必要があります。
• クライアントが Run 状態にない場合、ポスチャおよび NAC OOB はサポートされません。
• WGB と WGB に関連付けられているクライアントは、ポスト スイッチオーバー後に再度関連付けられる必要があります。
• CCX ベース アプリケーションは、スイッチオーバー後に再度開始する必要があります。
• PMIPv6、NBAR、SIP スタティック CAC ツリーは同期されず、SSO 後に再学習する必要があります。
• パッシブ クライアントは SSO 後に再度関連付ける必要があります。
• デバイスとルート証明書はスタンバイ コントローラに自動同期されません。
• AP およびクライアントの不正情報はスタンバイ コントローラに同期されず、ホット スタンバイがアクティブ コントローラになったときに再学習が必要です。
• スリープ状態のクライアント情報は、スタンバイ コントローラに同期されません。
• NBAR 統計情報はセカンダリ コントローラに同期されません。
• ネイティブ プロファイリング データはセカンダリ コントローラに同期されないため、クライアントはスイッチオーバー後に再度プロファイリングされます。
フィードバック