WLC およびリリース 8.7 でサポートされている AP

このマニュアルの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

■WLC 3500 シリーズ、8500 シリーズ、および 5520

■レガシーの Wave-1 AP：3700、2700、1700、702、702W、1530、1570

■Wave-2 AP：1800 シリーズ、2800 シリーズ、3800 シリーズ、1540、1560

■このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このマニュアルで使用されるデバイスはすべて、初期設定（デフォルト）の状態から作業が開始されています。ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

注：5508、7500、8510 および WiSM-2 は、リリース 8.5 までサポートされています。3504 シリーズはリリース 8.5 からサポートされています。詳細については、リリース ノートを参照してください。

表記法

ドキュメント表記の詳細は、『Cisco Technical Tips Conventions』を参照してください。

トポロジ

このドキュメントでは、次のネットワーク トポロジを使用しています。

 

3504/5520/8500 での冗長ポートを使用した HA 接続

3500/5520/8500 WLC には、アクティブからスタンバイ WLC に設定を同期するためにバックツーバック接続する必要のある専用冗長ポートが装備されています。

5520 および 8540 と同様に、3504 ワイヤレス コントローラにもユニットの前面に冗長ポートがあります。他の WLC と同様、WLC 3504 も AP SSO とクライアント SSO の両方をサポートしています。以下に示すのは、HA セットアップで RP ポートを使用して 2 つの WLC 3504 に接続する方法（バックツーバック）です。

アクティブ WLC の状態を確認するために、冗長ポートを介してスタンバイからアクティブ WLC に 100 ミリ秒（デフォルト タイマー）ごとにキープアライブ パケットが送信されます。

HA セットアップの両方の WLC がゲートウェイの到達可能性を追跡します。アクティブ WLC は、管理 IP アドレスを発信元に使用してインターネット制御メッセージ プロトコル（ICMP）の ping をゲートウェイに送信し、スタンバイ WLC は、冗長性管理 IP アドレスを使用して ICMP の ping をゲートウェイ送信します。両方の WLC が、1 秒間隔でゲートウェイに ICMP ping を送信します。冗長ポート間のバックツーバック直接接続を設けることを強くお勧めします。

注： アクティブとスタンバイの冗長ポート間を物理的に直接接続することを強くお勧めします。接続間の距離は、イーサネット ケーブルの規格によって 100 メートルまで可能です。

HA 連携のための新規インターフェイスの概要

冗長性管理インターフェイス

このインターフェイスには、管理インターフェイスと同じサブネットの 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 への手動時刻同期が実行されます。スタンドアロン コントローラの場合のこのポートは、最後の 2 オクテットを冗長性管理インターフェイスの最後の 2 オクテットから取得して自動生成される IP アドレスが割り当てられます（先頭の 2 オクテットは常に 169.254）。

注： 冗長性管理インターフェイスをタグなしのインターフェイスにすることはできません。

 

CLI からの HA の設定

次の手順を実行します。

1. HA を設定する前に両方のコントローラの管理インターフェイスが同じサブネットに入っている必要があります。

WLC 1：

 

WLC 2：

 

2. HA はデフォルトでディセーブルになっています。HA をイネーブルにする前に、冗長性管理 IP アドレスおよびピア冗長性管理 IP アドレスを設定する必要があります。両方のインターフェイスは、管理インターフェイスと同じサブネットにある必要があります。この例では、WLC 1 の冗長性管理 IP アドレスは 9.6.61.21、WLC 2 の冗長性管理 IP アドレスは 9.6.61.23 です。9.6.61.23 が WLC 2 の冗長性管理 IP アドレス、9.6.61.21 が WLC 1 の冗長性管理 IP アドレスになるように設定する必要もあります。

冗長性およびピア冗長性管理 IP アドレスを設定するには次の CLI を使用します。

WLC 1：

 

WLC 2：

 

3. このステップの CLI を使用して、1 つの WLC をプライマリとして設定し（デフォルトでは、WLC HA ユニット ID がプライマリであり、有効な AP-BASE カウント ライセンスがインストールされている必要あり）、もう 1 つの WLC をセカンダリ（プライマリ WLC からの AP ベース カウントをこのユニットで継承）として設定します。この例では、WLC 1 がプライマリとして設定され、WLC 2 がセカンダリとして設定されています。

WLC 1：

 

WLC 2：

 

注：リリース 7.3 以降でオーダーできるファクトリ オーダー HA SKU の場合は、ユニットをセカンダリとして設定する必要はありません。ファクトリ オーダー HA SKU は、デフォルトのセカンダリ ユニットであり、有効な AP カウント ライセンスを持つアクティブ WLC と初めてペアにされたときに、スタンバイ WLC の役割を引き受けます。

既存の任意の WLC をスタンバイ WLC として変換する場合は、CLI で config redundancy unit secondary コマンドを使用して変換します。この CLI コマンドは、スタンバイとして動作することが意図されている WLC に一定数の永久ライセンス カウントが備わっている場合に限り機能します。この条件は 5508 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。5520、WiSM2、7500、および 8500 などの他の WLC に制約事項はありません。

4. WLC に冗長性管理とピア冗長性管理の IP アドレスを設定し終え、冗長ユニットを設定し終えたら、次に SSO をイネーブルにします。SSO をイネーブルにする前に、両方のコントローラ間の物理接続が存在しており（イーサネット ケーブルを使用し、冗長ポートを介して両方の WLC をバックツーバック接続）、アップリンクもインフラストラクチャ スイッチに接続されていて、両方の WLC からゲートウェイに到達可能であることを確認することが重要です。

SSO をイネーブルにすると、WLC がリブートされます。WLC では、ブート時に、設定に従い冗長ポートを介して HA 役割をネゴシエートします。WLC が冗長ポートを介するか冗長管理インターフェイスを介して相互に到達できない場合、セカンダリとして設定されている WLC はメンテナンス モードに遷移します。メンテナンス モードについては、このドキュメントで後述します。

5. このステップの CLI を使用して AP SSO をイネーブルにします。AP SSO をイネーブルにすると、WLC のリブートが開始されることに留意してください。

WLC 1：

 

WLC 2：

 

6. SSO をイネーブルにすると、実施した設定に従って HA 役割をネゴシエートするために WLC がリブートされます。役割が決定されると、冗長ポートを介してアクティブ WLC からスタンバイ WLC に設定が同期されます。最初に、セカンダリとして設定されている WLC が XML の不一致をレポートし、アクティブから設定をダウンロードして再度リブートします。セカンダリ WLC では、役割が決まった後の次回リブート時に設定を再度検証した上で XML の不致をレポートせず、スタンバイ WLC として動作するように処理を続行します。

次に両方の WLC からの起動ログを示します。

WLC 1：

 

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 のプロンプト名に自動的に追加されます。

 

8. 次の手順を実行して、冗長性のステータスを確認します。

a. WLC 1 の場合、[Monitor] > [Redundancy] > [Summary] と移動します。

 

b. WLC 2 の場合、コンソール接続に移動します。

 

注：SSO をイネーブルにすると、コンソール接続またはサービス ポート上および冗長管理インターフェイス上の SSH からスタンバイ WLC にアクセスできます。

HA ペアでの SSO の無効化

1. プライマリ コントローラで、次のコマンドを使用して SSO を無効にします。

Config redundancy mode disable

アクティブとスタンバイ WLC は、このコマンドが実行されるとリブートします。

スタンバイ コントローラは、リブート後に復帰すると、インターフェイスの IP アドレスがプライマリ コントローラと同じになり、すべてのポートが無効になります。

2. スタンバイ コントローラで、管理インターフェイスとダイナミック インターフェイスに対応する正しい IP アドレスを再入力し、次のコマンドを実行します。

Config port adminmode all enable

3. 設定をコントローラに保存します。

4. SSO を再度有効にするには、プライマリ コントローラとセカンダリ コントローラで Config redundancy sso コマンドを実行します。

両方のコントローラが再起動し、SSO モードでペアになります。スタンバイは、プライマリから設定を同期し、ホットスタンバイ モードに戻ります。

リリース 8.7 の HA 冗長性のモニタリング

SNMP MIB を含む Management では、以下で説明する統計情報を取得するように MIB CISCO-LWAPP-HA-MIB.my が更新されています。

コントローラの [Monitor] タブに移動し、[Redundancy] を選択して 統計情報をモニタ できます。

同じタブで、[Summary] を選択すると、アクティブ コントローラの [Redundancy Summary] を表示できます。

8.7 リリースで強化された新しい機能に、[Peer Statistics] があります。これには、ピアのシリアル番号およびファンのステータスに関する追加情報が表示されます。

次の CLI コマンドでも同じ情報を表示できます。

show redundancy peer-system statistics

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. すべての AP はリブートし、新しいアクティブ WLC に接続します。

11. show boot、show sysinfo、show ap image all、および show redundancy summary コマンドを発行して、WLC と AP の両方が新しいイメージを使用してブートされていることを確認します。

HA セットアップに含まれる WLC のアップグレードを開始する前の重要なガイドライン

■サービス アップグレードはこのリリースではサポートされていません。したがって、HA セットアップの WLC をアップグレードする前にネットワーク停止時間を計画する必要があります。

■HA セットアップでのアップグレードを開始する前に、ピアがホット スタンバイ状態になっている必要があります。

■ソフトウェア バージョンの不一致がないように、アップグレード後に両方の WLC をほとんど同時にリブートすることをお勧めします。

■[Schedule Reset] は、HA セットアップの両方の WLC に適用されます。

■スケジュールされたリセットが計画されていない場合、スタンバイ 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> コマンドを発行します。

ボックス フェールオーバーのシミュレート手順

次の手順を実行します。

1. 設定のセクションで説明されている手順を実行して 2 つの WLC 間に HA を設定し、強制スイッチオーバーが開始される前に、両方の WLC がアクティブ WLC とスタンバイ WLC としてペアになっていることを確認します。

WLC 1 の場合：

 

WLC 2 の場合、コンソール接続に移動します。

 

2. AP を WLC に関連付け、両方の WLC で AP のステータスを確認します。HA セットアップでは、AP データベースのミラー コピーが両方の WLC で維持されます。つまり、AP の CAPWAP 状態がアクティブとスタンバイの WLC で維持され（Run 状態の AP に限る）、スイッチオーバーが開始されるとスタンバイ WLC がネットワークを引き継ぎます。この例では、WLC 1 がアクティブ WLC、WLC 2 がスタンバイ状態であり、AP データベースは両方の WLC で維持されています。

WLC 1：

 

WLC 2

 

3. オープンな WLAN を作成し、クライアントを関連付けます。クライアント データベースはスタンバイ WLC で同期されないため、クライアント エントリはスタンバイ WLC には存在しません。WLAN をアクティブ WLC に作成すると、この WLAN も冗長ポートを介してスタンバイ WLC に同期されます。

WLC 1：

 

WLC 2：

 

4. アクティブ WLC で redundancy force-switchover コマンドを発行します。このコマンドを発行すると、アクティブ WLC がリブートしてスタンバイ WLC がネットワークを引き継ぐ手動スイッチオーバーがトリガーされます。この場合、アクティブ WLC 上のクライアントは認証解除され、新しいアクティブ WLC に接続し直します。

WLC 1：

 

WLC 2：

 

注：この例では、プロンプトが 5508-Standby から 5508 に変わります。これは、この WLC がアクティブ WLC になったためであり、AP スイッチオーバーにかかった時間は 1 ミリ秒です。

WLC 2：

 

当初スタンバイ WLC になっていて、スイッチオーバー後にアクティブ WLC になった WLC 2 の AP の CAPWAP 状態を確認してください。AP Up Time および Association Up Time が維持されており、AP は Discovery 状態になりませんでした。

次のマトリクスを参照すると、WLC スイッチオーバーのトリガー条件がはっきりとわかります。

 

 

メンテナンス モード

スタンバイ WLC がメンテナンス モードに入り、ネットワークおよびピアと通信できない複数のシナリオがあります。

■冗長管理インターフェイスを介してゲートウェイに到達できない

■HA SKU を持つ WLC がピアを検出しない

■冗長ポートが停止している

■ソフトウェア バージョンの不一致（最初に起動する WLC がアクティブ モードになり、もう 1 つの WLC がメンテナンス モードになる）

 

注：メンテナンス モードを終了するには、WLC をリブートする必要があります。メンテナンス モードでは、コンソールおよびサービス ポートのみがアクティブです。

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 オフセット タイマーが続行され、時間の経過後に頻繁なメッセージを表示します。

• 経過時間および AP カウントは、リブート時に維持されます。
• ファクトリ デフォルトの HA-SKU コントローラでは、AP の接続を許可してはいけません。

両方の WLC に有効な AP カウント ライセンスがある

■最小永久ライセンス カウント要件を満たしているのであれば、CLI を使用して、1 つの WLC をスタンバイ WLC として設定する必要があります（設定のセクションを参照）。この条件は 5508 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。5520、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 をセカンダリ ユニットとして設定できます。この条件は 5508 WLC だけに有効で、スタンバイに変換する最低 50 の AP 永久ライセンスが必要になります。5520、WiSM2、7500、3504 および 8500 などの他の WLC に制約事項はありません。

■AP カウント ライセンス情報は、アクティブからスタンバイにプッシュされます。

■スイッチオーバーの場合、新しいアクティブ WLC は前のアクティブ WLC のライセンス カウントを使用して動作し、90 日のカウントダウンを開始します。

■90 日間が経過すると、頻繁なメッセージの出力を開始します。接続されている AP を切断することはありません。

■新しい WLC がアップすると、ペアリング時点の HA SKU が AP カウントを取得します。

–新しい WLC の AP カウントが前の WLC よりも大きい場合、90 日のカウンタはリセットされます。

–新しい WLC の AP カウントが前の WLC よりも小さい場合、90 日のカウンタはリセットされません。

–小さい AP カウントへのスイッチオーバーの後も WLC オフセット タイマーは続行されて、時間の経過後に頻繁なメッセージを表示します。

リリース 7.5 ～ 8.7 でサポートされる HA トポロジ

3500（リリース 8.5）/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 接続

図 1 バックツーバック RP 接続

 

■これは、コントローラのリリース 7.3 でサポートされたトポロジと同じです。

■設定同期とキープアライブ メッセージは冗長ポートから送信されます。

■RMI インターフェイスは管理サブネットの一部として作成され、ピアと管理ゲートウェイの到達可能性を検査するために使用されます。

■RTT 遅延はデフォルトで 80 ミリ秒です。RTT は、100 ～ 400 ミリ秒の範囲で設定可能なキープアライブ タイマーの 80% にする必要があります。

■障害検出時間は 3*100 + 60 + ジッター（12 ミリ秒）= ～ 400 ミリ秒

注：上記の等式で、3 はキープアライブ再試行回数、100 はキープアライブ タイマー、60 は
3*10 + 3*10（ピアへの 3 RMI ping + ゲートウェイへの 3 ping）です。

■帯域幅：60 Mbps 以上

■MTU: 1500

プライマリ WLC の設定：

configure interface address management 9.5.56.2 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.10 peer-redundancy-management 9.5.56.11

configure redundancy unit primary

configure redundancy mode sso

ホット スタンバイ WLC の設定：

configure interface address management 9.5.56.3 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.11 peer-redundancy-management 9.5.56.10

configure redundancy unit secondary

configure redundancy mode sso

スイッチを介した RP 接続

図 2 スイッチを介した RP 接続

 

■データセンターをまたぐ、スイッチを介した冗長ポート接続はこのトポロジでサポートされます。

■設定同期およびキープアライブは冗長ポート経由。

■RMI インターフェイスは管理サブネットの一部として作成され、ピアと管理ゲートウェイの到達可能性を検査するために使用されます。

■RTT 遅延はデフォルトで 80 ミリ秒です。RTT は、100 ～ 400 ミリ秒の範囲で設定可能なキープアライブ タイマーの 80% にする必要があります。

■障害検出時間は 3*100 + 60 + ジッター（12 ミリ秒）= ～ 400 ミリ秒

■帯域幅：60 Mbps 以上

■MTU: 1500

プライマリ WLC の設定

configure interface address management 9.5.56.2 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.10 peer-redundancy-management 9.5.56.11

configure redundancy unit primary

configure redundancy mode sso

ホット スタンバイ WLC の設定

configure interface address management 9.5.56.3 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.11 peer-redundancy-management 9.5.56.10

configure redundancy unit secondary

configure redundancy mode sso

VSS ペアに接続された 5508、7500 または 8500

図 3 VSS ペアに接続された WLC

 

サポートされた WiSM2 コントローラの HA トポロジ

同一シャーシ内の WiSM2

図 4 単一シャーシ内の WiSM2

 

別のシャーシ内の WiSM2：L2 ネットワークによる冗長 VLAN

図 5 L2 ネットワークによる冗長 VLAN を使用した WiSM2 接続

Cat6k での WiSM2 用設定

wism service-vlan 192（サービス ポート VLAN）

wism redundancy-vlan 169（冗長ポート VLAN）

wism module 6 controller 1 allowed-vlan 24-38（データ VLAN）

WiSM2 HA 設定は変更されません。

別のシャーシ内の WiSM2：VSS ペア

図 6 VSS ペアを使用した WiSM2 接続

 

図 7 VSL リンクを介して接続されたアクティブおよびスタンバイ VSS ペア

 

図 8 VSS ペアを使用した WiSM2 接続

 

VSS の設定

 

 

推奨事項

■冗長リンクのラウンドトリップ遅延は、80 ミリ秒以下にする必要があります。

■冗長リンクの推奨 MTU は 1500 以上です。

■冗長リンクの帯域幅は 60 Mbps 以上である必要があります。

■2 台のコントローラ間に L2 隣接があるといった、冗長ポートがスイッチを介して接続されている場合、RP VLAN は管理ポートのスイッチに設定されたアクセス VLAN から除外する必要があります。

■L2 ネットワーク経由で接続される 2 種類のシャーシ間の WiSM2 接続の場合、「redundancy vlan」が管理ポートのスイッチに設定されたアクセス VLAN から除外される必要があります。

■アクティブ-アクティブ シナリオを回避するため、RP ポート接続と管理ポートのトラフィックに、異なるスイッチ セットを使用することを強く推奨します。

■VSS セットアップの WiSM2 を配置する場合、ピア検出時間を 180 秒に設定することを推奨します。

AP とクライアントの状態の同期

1. この段階では、両方のコントローラが HA セットアップでペアになります。アクティブで実施した設定はすべて、冗長ポート経由でスタンバイ コントローラに同期されます。コンソール接続から、スタンバイ WLC の WLAN サマリーとインターフェイス サマリーを確認します。

2. ハイ アベイラビリティのセットアップでは、UP Time や Association UP time など、アクティブ コントローラおよびスタンバイ コントローラ（Run 状態の AP のみ）に維持されている AP の CAPWAP の状態が、アクティブ コントローラからスタンバイ コントローラに同期されます。以下の例では、WLC 1 がアクティブ状態でネットワークを処理しており、WLC 2 がスタンバイ状態でアクティブ コントローラをモニタしています。WLC 2 はスタンバイ状態ですが、まだ AP の CAPWAP 状態を維持します。

WLC 1-> コンソール接続：

 

アクティブ WLC の AP UP Time および Association UP Time を監視します

WLC 2-> コンソール接続：

 

スタンバイ 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 状態のクライアント エントリが出現します。

WLC 1-> コンソール/Telnet/SSH 接続：

 

 

クライアント エントリはアクティブ WLC に存在します。

WLC 2-> コンソール接続：

 

 

クライアント エントリはスタンバイ WLC に存在します。

5. PMK キャッシュも 2 台のコントローラ間で同期されます。

WLC 1：

 

WLC 2：

 

フェールオーバー プロセス

1. アクティブ コントローラで redundancy force-switchover コマンドを発行します。このコマンドを発行すると、アクティブ コントローラがリブートしてスタンバイ コントローラがネットワークを引き継ぐ手動スイッチオーバーがトリガーされます。この場合、アクティブ WLC の Run 状態のクライアントは、認証解除されません。コマンド save config が redundancy force-switchover コマンドの前に発行されます。

WLC 1-> コンソール接続：

 

WLC 2-> コンソール接続：

 

上の画面キャプチャのプロンプトで変化を監視します。

WLC 2-> コンソール接続：

 

当初はスタンバイでスイッチオーバー後にアクティブになった WLC 2 で AP CAPWAP State を監視します。AP Up Time および Association Up Time は維持され、AP は Discovery 状態になりませんでした。

2. また、スイッチオーバーが開始されるときのクライアント接続にも注意します。クライアントは、認証解除されません。

スイッチオーバー中の無線クライアントからゲートウェイ IP アドレスと管理 IP アドレスへの ping は、最小の損失を示します。

 

 

3. 冗長性ステータスのチェック方法

WLC 1 -> コンソール接続でコマンド show redundancy summary を発行：

 

WLC 2 -> コンソール接続でコマンド show redundancy summary を発行：

 

WLC 2 -> [Monitor] > [Redundancy] > [Summary] とクリック：

 

4. 現在のアクティブ WLC への強制的な再スイッチオーバーを開始します。

プライマリ ユニットとして設定された WLC がアクティブになり、セカンダリ ユニットとして設定された WLC 2 はホット スタンバイ状態になる必要があります。

WLC 2：

 

WLC 1：スイッチオーバー後に WLC 1 のローカル状態がアクティブ、ユニットがプライマリになっていることを確認します。

 

スイッチオーバー履歴を監視します。WLC は、10 回のスイッチオーバー履歴を原因とともに保持します。

 

 

クライアント SSO の動作と制限

■サービスおよびサービスに関連付けられたサービス プロバイダーおよびドメイン名データベースからなる Bonjour ダイナミック データベースがスタンバイに同期されます。

■Run 状態にあるクライアントだけが、アクティブとスタンバイの WLC 間で同期されます。クライアント SSO は、コントローラの関連付け/join プロセス中にあるクライアントのシームレスな遷移をサポートしません。遷移段階のクライアントはスイッチオーバーの後に認証解除され、コントローラに再度 join する必要があります。

■クライアントが Run 状態にない場合、ポスチャおよび NAC OOB はサポートされません。

■リリース 8.2.111.0 では、WGB および WGB に関連付けられているクライアントは、クライアント SSO によりステートフルでスイッチオーバーします。

■CCX ベース アプリケーションは、スイッチオーバー後に再度開始する必要があります。

■新しいモビリティはサポートされていません。

 

■クライアントの統計情報は同期されません。

■PMIPv6、NBAR、SIP スタティック CAC ツリーは同期されず、SSO 後に再学習する必要があります。

■OEAP（600）クライアントはサポートされません。

■パッシブ クライアントは SSO 後に再度関連付ける必要があります。

■デバイスとルート証明書はスタンバイ コントローラに自動同期されません。

■AP およびクライアントの不正情報はスタンバイ コントローラに同期されず、ホット スタンバイがアクティブ コントローラになったときに再学習が必要です。

■スリープ状態のクライアント情報は、スタンバイ コントローラに同期されません。

■NBAR 統計情報はセカンダリ コントローラに同期されません。

■ネイティブ プロファイリング データはセカンダリ コントローラに同期されないため、クライアントはスイッチオーバー後に再度プロファイリングされます。

■次の表は、MAP と RAP での w.r.t SSO の動作を示します。

 

機能強化と改善

Bulk Sync ステータス

現在コントローラは、Bulk Sync 設定が開始されても、その完了を示すものを何も提供しません。Bulk Sync を確認する手段は、ユーザによる監視とスタンバイ WLC に同期されたクライアントの数を手動でチェックする方法のみです。この機能の一部として、スタンバイ WLC の起動時に Bulk Sync のステータス（AP とクライアント同期の両方）を伝えるためのメカニズムが提供されています。

[Controller] > [Redundancy] > [Summary] の下に、[BulkSync Status] と呼ばれる新しいフィールドが GUI として追加されています。このフィールドは、スタンバイ WLC への一括同期のステータスを示し、ステータスは Pending/In-progress/Complete のいずれかになります。

図 9 BulkSync Status GUI

 

また、CLI コマンド show redundancy summary の出力にも、スタンバイ コントローラとのペアリング中は Bulk Sync ステータスが表示されます。ステータスは、以下に示すように Pending/In-progress/Complete のいずれかになります。

スタンバイ コントローラの起動中、BulkSync ステータスには [Pending] と表示されます。

図 10 BulkSync Status：Pending

 

スタンバイ コントローラがブートアップ プロセスを完了し、一括同期が開始されると、ステータスは [In-Progress] に変わります。

図 11 BulkSync Status：In-Progress

 

一括同期プロセスが完了すると、BulkSync ステータスは [Complete] に変わります。

図 12 BulkSync Status：Complete

 

debug/show コマンドの機能強化

HA はネットワークが停止しないようにする上で重要な役割を果たすため、SSO の時点で、またはそれ以降の時点で、ボックスの状態の変化をデバッグできるかどうかにも直接かかわります。

次の新しいカテゴリの統計情報が [Monitor] > [Redundancy] > [Statistics] の下に表示されるようになりました。

a. All

b. Infra

c. Transport

d. Keep-Alive

e. GW-Reachability

f. Config-Sync

図 13 Redundancy Statistics の GUI

 

Infra 統計情報には、図 14に示すように RF クライアントの詳細情報とサニティ カウンタが表示されます。

図 14 Redundancy Statistics：Infra

図 15 Redundancy Statistics：Transport

 

ハートビート デバッグには、ハートビートの受信イベント、ハートビートの損失イベント、およびそれらに関連した後続のアクションが含まれます。

図 16 Redundancy Statistics：Keep-Alive

 

HA システムは、ネットワークの停止を削減するために、管理ゲートウェイの到達可能性を監視します。

スタンバイ コントローラでは、アクティブ コントローラとスタンバイ コントローラのゲートウェイの到達可能性に関連する有用性のデバッグ、それぞれの稼働状態、およびこの情報に基づいて行われたアクションが報告されます。アクティブ コントローラでは、アクティブ WLC のゲートウェイへの到達可能性のみが報告されます。

図 17 Redundancy Statistics：GW-Reachability

 

図 18 Redundancy Statistics：Config-Sync

 

この機能のために、次の debug/show CLI コマンドが導入されています。

1. debug redundancy infra detail/errors/event

2. debug redundancy transport detail/errors/events/packet

3. debug redundancy keepalive detail/errors/events

4. debug redundancy gw-reachability detail/errors/events

5. debug redundancy config-sync errors/events/detail

6. debug redundancy ap-sync errors/events/detail

7. debug redundancy client-sync errors/events/detail

8. debug redundancy mobility events/errors/detail

9. show redundancy infra statistics

10. show redundancy transport statistics

11. show redundancy keepalive statistics

12. show redundancy gw-reachability statistics

13. show redundancy config-sync statistics

14. show redundancy ap-sync statistics

15. show redundancy client-sync statistics

設定可能なキープアライブとピア検索のパラメータ

顧客の導入状況ごとに異なるネットワークの遅延に対処するため、キープアライブ パラメータとピア検索パラメータが設定可能になりました。この機能強化により、アクティブ コントローラとスタンバイ コントローラ間のフェールオーバーをトリガーするキープアライブの最大数を設定できるようになりました。また、ピア検索タイマーとキープアライブ タイマーも広い範囲をサポートするように変更されています。

次の新しい CLI コマンドが追加されており、3 ～ 10 の範囲で冗長キープアライブ リトライの回数を設定できます。

図 19 redundancy retries CLI コマンド

 

キープアライブ タイマーの既存の CLI コマンド config redundancy timer keep-alive-timer が 100 ～ 1000 ミリ秒のキープアライブ タイマーをサポートするように変更されています。

ピア検索タイマーの既存の CLI コマンド config redundancy timer peer-search-timer が 60 ～ 300 秒のピア検索タイマーをサポートするように変更されています。

図 20 redundancy timer CLI コマンド

 

 

冗長キープアライブ リトライ値を表示するために、次の CLI が導入されています。

図 21 show redundancy retries CLI コマンド

ピア検索タイマーおよびキープアライブタイマー値を表示するには、 show redundancy timers コマンドを使用します。

図 22 Show redundancy timers CLI コマンド

 

キープアライブ値とピア検索タイムアウト値を表示するには、 show redundancy detail コマンドを使用します。

図 23 Show redundancy detail CLI コマンド

 

キープアライブ タイマー、キープアライブ リトライ、ピア検索タイマーも設定可能で、GUI の [Controller] > [Redundancy] > [Global Configuration] ページから表示できます。

図 24 冗長性のグローバル設定の GUI

 

Peer RMI ICMP ping を UDP メッセージに変更

リリース 8.0 までは、ピア WLC のハートビートの確認に、冗長性管理インターフェイスの ICMP ping が使用されます。リリース 8.0 では、この機能の一部として、ICMP ping が UDP メッセージに変更されています。

これには、次の要因により利点があります。

■ICMP ping パケットは負荷が重いと廃棄される可能性がある。

■同じ IP のデバイスが他にあると、ping にも応答する可能性がある。

不正なスイッチオーバーを避けるために、RMI および管理インターフェイスをタグ付けすることをお勧めします。RMI と管理インターフェイスのタギングは、リリース 8.0 では WLC を SSO モードでペアリングする場合に必須になりました。

スタンバイ WLC のオンザフライのメンテナンス モード（MTC）

リリース 8.0 までは、スタンバイ コントローラが「デフォルト ゲートウェイ」または「ピア RP」への到達可能性を失うと、コントローラは再起動して起動中にその状況を確認し、MTC モードを開始します。この機能では、このようなエラー シナリオが発生してもスタンバイ WLC は再起動せず、「オンザフライ（その場）」で MTC モードを開始します。ピア RP とデフォルト ゲートウェイの到達可能性が回復すると、リリース 7.6 で導入された MTC モード自動回復メカニズムが WLC を再起動し、アクティブ WLC とペアリングします。このメカニズムは、スタンバイ WLC でのみ実行されます。アクティブ コントローラの場合は変わらず、MTC モードを開始する前に再起動します。

デフォルト ゲートウェイの到達可能性のチェック機能の強化

この機能強化により、ゲートウェイ（GW）の到達可能性チェック メカニズムは誤検出を回避するように変更されています。また、コントローラの起動時にゲートウェイの到達可能性チェックを実行するタイミングも最適な時期に変更されています。

リリース 8.0 までは、役割のネゴシエーション中に「GW 到達可能性チェック」が実行されていました。リリース 8.0 およびそれ以降では、役割のネゴシエーション中には実行されず、HA ペア設定が完了してから開始されます。

また、特定のスイッチ/ルータ設定のレートで、ICMP ping パケットの制限や破棄が生じることが確認されています。誤検出をトリガーするこのような状況を回避するために、新しい設計では ICMP ping の損失だけでスイッチオーバーの実行を判断しないようになりました。ロジックの変更により、6 回連続して ping が破棄されると、ARP 要求が GW IP アドレスに送信されます。この要求への応答に成功すると、GW は到達可能と見なされます。

高速 HA ペア設定

現在は、HA のペアリング プロセス時にアクティブ/スタンバイの役割が決まると、アクティブ WLC からスタンバイ WLC に冗長ポートを介して設定が同期されます。設定が異なる場合、セカンダリ WLC は XML の不一致を報告し、アクティブ コントローラから設定をダウンロードしてもう一度リブートします。セカンダリ WLC は、役割が決まった後の次回リブート時に設定を再度検証した上で XML の不一致がないことを報告し、スタンバイ WLC として機能するように処理を続行します。

この機能強化により、XML は初期化時の XML の検証直前に、アクティブになるコントローラからスタンバイになるコントローラに送信されます。これにより、他のモジュールはまだ初期化されていないため、比較とリブートの余分なステップが避けられ、結果としてアクティブ WLC とスタンバイ WLC のペア設定が高速化されます。

以下のブート ログからわかるように、XML の比較もスタンバイ WLC のリブートも含まれていません。

図 25 スタンバイ WLC のブートアップ ログ

 

SSO での新しい機能のサポート

内部 DHCP サーバの SSO サポート

リリース 8.0 までは、HA が有効なコントローラに「内部 DHCP サーバ」を構成できません。これは、内部 DHCP サーバのデータがスタンバイ WLC に同期されないためです。リリース 8.0 およびそれ以降では、HA が有効なコントローラに「内部 DHCP サーバ」を構成してデータをスタンバイ WLC に同期できるため、スイッチオーバーの後すぐに、新しいアクティブなコントローラ上の「内部 DHCP サーバ」でクライアントへのサービスを開始できます。

GUI を使用して内部 DHCP サーバを設定するには、[Controller] > [Internal DHCP Server] に移動します。

図 26 内部 DHCP サーバの GUI

 

同じ内容がスタンバイ コントローラに同期されるので、CLI コマンド show dhcp summary を実行して確認します。

図 27 アクティブおよびスタンバイ WLC 上の show dhcp summary

 

AP 無線の CAC 統計情報の同期

この機能強化により、音声とビデオ、および通話の統計情報に関する静的な CAC 方式の帯域幅割り当てパラメータがスタンバイ WLC に同期されるため、それぞれの情報はスイッチオーバーの後すぐに、コール アドミッション制御に使用する新しいアクティブ コントローラ上で利用できます。

スリープ状態のクライアントの SSO サポート

リリース 7.5 では、スリープ状態のクライアントの SSO サポートが提供されていませんでした。スリープ状態のクライアント データベースがスタンバイ コントローラに同期されなかったため、スイッチオーバーの発生後はスリープ状態のクライアントを再認証する必要がありました。今回のリリースでは、スリープ状態のクライアント データベースがスタンバイ コントローラに同期されるため、スリープ状態のクライアントは、スリープ状態のクライアント タイムアウト間隔内にスリープ解除された場合、ウェブ再認証を回避できます。

CLI コマンド show custom-web sleep-client summary を使用して、アクティブ WLC とスタンバイ WLC 間でスリープ状態のクライアント データベースの同期を検証します。

図 28 プライマリ WLC のスリープ状態のクライアント データベース

 

図 29 スタンバイ WLC のスリープ状態のクライアント データベース

 

図 30 アクティブおよびスタンバイ WLC のスリープ状態のクライアントの詳細

 

OEAP 600 AP の SSO サポート

リリース 8.0 までは、HA ペアでスイッチオーバーが発生すると、OEAP 600 AP は CAPWAP トンネルを再起動して新しいアクティブ コントローラに接続し直すため、接続されているすべてのクライアントの認証は解除されます。この機能により OEAP 600 AP は CAPWAP トンネルをリセットしなくなります。また、クライアントは、新しいアクティブ コントローラとの接続をシームレスに継続します。

以下に示すように、アクティブおよびスタンバイ コントローラで show ap summary と show client summary コマンドを実行すると、出力に AP とクライアント データベースの同期が表示されます。

図 31 アクティブ WLC 上の OEAP 600 AP

 

図 32 スタンバイ WLC への OEAP 600 AP の同期

 

図 33 アクティブ WLC 上のクライアント

 

図 34 スタンバイ WLC へのクライアントの同期

 

HA スタンバイ モニタリング機能について

アクティブ コントローラとホット スタンバイ コントローラは、クライアントの観点では 1 つのエンティティと見なされますが、管理者の観点では 2 つの別々 のコントローラと見なして保守、およびモニタします。管理者は、アクティブおよびスタンバイ WLC のステータスと稼働状態を別々に取得し、コントローラのモニタと保守を管理インフラストラクチャとさまざまなユーザ インターフェイスを活用して継続的に行います。

このセクションでは、スタンバイ コントローラから稼働状態に関する情報とトラップを取得するためのインターフェイスについて説明するほか、これらユーザ インターフェイスを CLI、GUI、SNMP から使用する方法について述べます。

イベントと通知

WLC がホット スタンバイになったときのトラップ

トラップは HA ピアがホット スタンバイになったときのタイムスタンプ付きで報告され、次のようなトラップが報告されます。

新しいトラップ タイプが CISCO-LWAPP-HA-MIB.my に追加されています。

 

一括同期が完了したときのトラップ

HA ペアリングが実行され、一括同期が完了すると、次のトラップが報告されます。

新しいトラップ タイプが CISCO-LWAPP-HA-MIB.my に追加されています。

 

スタンバイ WLC がダウンしたときのトラップ

スタンバイ ピアが、次のイベントのいずれかによりダウンすると、トラップが報告されます。

■手動リセット

■クラッシュ時

■メモリ リーク/ハング

■メンテナンス モードへの移行

報告されるトラップは以下のとおりです。

新しいトラップ タイプが CISCO-RF-SUPPLEMENTAL-MIB.my に追加されています。

 

CLI で、コマンド show traplog を実行してトラップを表示できます。

 

スタンバイでの管理者ログイン時の syslog 通知

SSH を使用したスタンバイへの管理者ログイン

これにより msglog/syslog にイベントが作成されます。メッセージのスニペットは以下のとおりです。

このメッセージは、CLI の「 show msglog 」を実行して、スタンバイ WLC で表示できます。

コンソールを使用したスタンバイへの管理者ログイン

これにより msglog/syslog にイベントが作成されます。メッセージのスニペットは以下のとおりです。

このメッセージは、CLI の「 show msglog 」を実行して、スタンバイ WLC で表示できます。

CLI のピア プロセス統計情報

この機能により、スタンバイ WLC のすべてのスレッドの CPU とメモリの統計情報がアクティブ コントローラに 10 秒ごとに同期されます。この情報は、ユーザがアクティブ WLC 上のピア統計情報を照会したときに表示されます。

アクティブ WLC でピア プロセスのシステム、CPU、メモリの統計情報を表示するための新しいコマンドは次のとおりです。

■ show redundancy peer-system statistics

■ show redundancy peer-process cpu

■ show redundancy peer-process memory

これらの統計情報を取得するために MIB CISCO-LWAPP-HA-MIB.my が更新されています。

 

 

GUI のピア プロセス統計情報

GUI のピア統計情報は、[Monitor] > [Redundancy] > [Peer Statistics] で表示できます。

図 35 ピア プロセスのシステム統計情報

 

 

 

これらの統計情報を取得するために MIB CISCO-LWAPP-HA-MIB.my が更新されています。

図 36 ピア プロセスの CPU 統計情報

 

 

図 37 ピア プロセスのメモリ統計情報

関連情報

■ テクニカルサポートとドキュメント - Cisco Systems

■ N+1 導入ガイド