この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、AppNav-XE の詳細設定について説明します。内容は次のとおりです。
AppNav コントローラを設定するには、次の手順を実行します。
AppNav コントローラ グループで、AppNav コントローラを設定します。AppNav コントローラ グループを設定するには、AppNav コントローラで使用する IP アドレスを入力します。
• AppNav コントローラ グループには常に、正確に 1 つのローカル IP アドレスが含まれる必要があります。これはローカルの AppNav コントローラ(ローカル ルータ)の IP アドレスです。このローカル IP アドレスはインターフェイスに属している必要があり、AppNav コントローラ グループ内の他のすべての AppNav コントローラ、およびすべてのサービス ノードは、このインターフェイスから到達可能である必要があることに注意してください。
• AppNav コントローラ グループには、AppNav コントローラを 4 つまで含めることができます。この場合、正確に 1 つのローカル IP アドレスと、任意に最大 3 つの非ローカル IP アドレスを含める必要があります。
• GigE、VLAN インターフェイス、ループバック インターフェイスなどから IP アドレスを使用できますが、インターフェイスに VRF が設定されていないことが必要です。
(注) デュアル RP Cisco ASR 1000 プラットフォーム上では、サブインターフェイスで service-insertion コマンドを使用しないでください。
• システムでは、1 つの AppNav コントローラ グループの設定だけがサポートされます。
(この機能は Cisco IOS XE Release 3.10.2 で使用できます)。
AppNav コントローラ グループ(ACG)内では、ルータがリブートした直後の場合、ルータを実行中およびハンド オーバー トラフィックとして指定する前に、短い遅延を指定する必要があります。遅延が起こることにより、再起動したルータは、現在トラフィックを処理しているルータと同期できるようになります。同期により、意図しない接続のリセットを回避できます。
• ACG の別の AppNav コントローラがトラフィックを処理します。
• 影響を受けるデバイスで、AppNav は Border Gateway Protocol(BGP)パケットを含む、すべての TCP パケットをドロップするモードになります。
• 影響を受けるデバイスで、AppNav は EIGRP および OSPF をドロップします。
デフォルト遅延は 120 秒です。通常、これはフローを同期するための十分な時間です。
コマンドの no 形式は、次のリロードで遅延がキャンセルされます。コマンドの no 形式を実行しても、すでに適用されている場合は現在の遅延がキャンセルされません。
(注) このコマンドを startup-config バッチ ファイルに追加すると、再起動プロセス中に遅延が確実に設定されます。
• 複数のコントローラで設定された AppNav コントローラ グループ(「「AppNav コントローラ グループの設定」」を参照)
サービス ノード グループでは、サービス ノードを設定する必要があります。AppNav-XE コンポーネントは、サービス ノード グループ内のサービス ノードにフローをインテリジェントに配信します。
Cisco IOS XE リリース 3.13 以降では、1 つのクラスタに合計 64 個のサービス ノードを含めることができます (以前のリリースでの許容数は 32 個でした)。
AppNav コントローラまたはサービス ノード IP アドレスには、VRF を使用できません。IP アドレスは、VRF なしで明示的にアクセスできる必要があります。たとえば、管理インターフェイスの IP アドレス(vrf Mgmt-intf あり)は、AppNav コントローラの IP アドレスとして使用できません。
AppNav-XE コンポーネントによって処理されるトラフィックを決定するには、AppNav クラスを使用します。appnav タイプのクラスマップを使用して、次のパラメータ セットに基づき、トラフィックを分類します。
表 3-1 に、ASR と CSR の各プラットフォームでの ACL および ACE プラットフォームの制限値を示します。
|
|
|
|
|
|
---|---|---|---|---|---|
指定したクラスへの接続の照合に使用するクラス マップを作成または変更するには、グローバル コンフィギュレーション モードで class-map コマンドを使用します。既存のクラス マップを削除するには、このコマンドの no 形式を使用します。 class-map コマンドにより、クラスマップ コンフィギュレーション モードになります。このモードで、オプションの description コマンドと、このクラスの一致条件を設定するための、1 つ以上の match コマンドを入力できます。
一致を指定しない場合、デフォルトは match-all です。
match access-group コマンドでは、番号付きアクセス リストまたは名前付きアクセス リストを指定します。このリストの内容は、このクラスに属するかどうかを判断するためにパケットに対する一致条件として使用されます。アクセス リスト(ACL)番号は 1 ~ 2699 の範囲で指定できます。
match peer コマンドは接続のクライアント側で最適化を実行する可能性のあるピア サービス ノードを識別します。ピア サービス ノードは 01:23:45:67:89:ab 形式で指定する必要があります。match peer 句はピアの AppNav-XE コンポーネントがコアとして動作している場合、つまり、ピア WAAS デバイスを介してすでに接続を受信している場合にのみ役立ちます。
match protocol コマンドは、次のプロトコルのいずれかを取得します。
プロトコルは、特定のアプリケーションとパケットを関連付けるため、サービス ノードによって提供される追加情報とともにのみ使用されます。match protocol フィルタを、次に示す AppNav ポリシーの monitor-load キーワードと混同しないでください。
AppNav クラス マップを設定したら、AppNav ポリシー マップを使用してアクションを割り当てることができます。
クラスごとの AppNav ポリシー マップ、クラス マップ、一致フィルタの制約事項
表 3-2 に クラスごとの AppNav ポリシー マップ、クラス マップ、一致フィルタの制約事項を示します。
|
|
|
---|---|---|
4096(RP2、ESP40、ESP100、ESP200 モデルの場合のみ Cisco IOS XE リリース 3.10 以降は 16000) |
||
候補最適化トラフィックのサービス ポリシーを定義するポリシー マップを作成または変更するには、グローバル コンフィギュレーション モードで policy-map コマンドを使用します。
上記の class コマンドは、ポリシーマップクラス コンフィギュレーション サブモードを開始します。
distribute コマンドは、このクラスの最も一般的なアクションです。システムは指定の SNG_name パラメータで識別したサービス ノード グループに、クラス マップに一致するトラフィックを送信します。サービス ノード グループが使用できない場合、または、distribute が指定されていない場合、デフォルトのアクションはトラフィックのパススルーです。
プライマリおよびバックアップのサービス ノード グループを設定するには、2 つの distribute コマンド ステートメントを使用します。
プライマリ サービス ノード グループのサービス ノードが使用できない場合、システムはバックアップ サービス ノード グループを使用します。
monitor-load コマンドは、監視する必要がある負荷値を決定します。アプリケーション アクセラレータをモニタする場合は、AppNav コントローラがそのアプリケーション アクセラレータの過負荷をチェックし、過負荷がかかっているサービス ノードに新しいフローを送信しないようにします。フローはサービス ノード グループの別のサービス ノードに送信されます。
このコマンドは任意です。これを使用すると、システムは application_accelerator_name パラメータで示されるアプリケーション アクセラレータをモニタします。このコマンドを使用しない場合、システムは TFO アクセラレータのステータスをモニタします。アプリケーション アクセラレータを指定すると、既存の monitor-load(存在する場合)が置き換えられます。
• MS-port-mapper(Microsoft Endpoint Port Mapper の負荷のモニタリング)
• cifs(SMB または CIFS アクセラレータの負荷のモニタリング)
• http(HTTP アクセラレータの負荷のモニタリング)
• mapi(MAPI アクセラレータの負荷のモニタリング)
• video(video アクセラレータの負荷のモニタリング)
pass-through コマンドは、リダイレクトが発生しないことを明示的に示すために使用します。 pass-through コマンドは、 distribute または monitor-load コマンドとともに使用することはできません。 pass-through コマンドを使用すると、システムは distribute または monitor-load コマンドのアクションをブロックし、エラー メッセージを表示します。 distribute または monitor-load コマンドのいずれかを使用する場合、システムは pass-through コマンドのアクションをブロックします。
サービス コンテキストは、AppNav コントローラ グループ、サービス ノード グループ、および AppNav ポリシー マップをまとめて関連付けるために使用されます。
(注) AppNav-XE が WCM によって管理されている場合、コマンド ライン インターフェイス(CLI)を使用してサービス コンテキスト設定の認証キーを変更することはできません。
サービス コンテキストを作成するには、次のコマンドを使用します。
interface_ID は、すべてのサービス コンテキストで一意の番号です。これは、AppNav-Compress interface_ID および AppNav-UnCompress interface_ID と呼ばれる自動作成される仮想インターフェイスの名前を決定します。
ACG_name は、このサービス コンテキストが属する AppNav コントローラ グループの名前です。各サービス コンテキストに対して 1 つの AppNav コントローラ グループだけを設定できます。
authentication-key は、AppNav コントローラからサービス ノードへの登録時に使用される共有認証キーです。同じサービス コンテキスト内のサービス ノードには、同一のキーを設定する必要があります。現在、AppNav コントローラ グループは、1 つの認証キーだけをサポートしています。すべてのサービス コンテキストが認証を使用する必要があります。そうでない場合、サービス コンテキストは認証を使用できません。
SNG_name は、サービス コンテキストの一部である 1 つまたは複数のサービス ノード グループの名前です。AppNav ポリシーで使用されているものをクロス チェックするために、リストが使用されます。2 つのサービス コンテキスト間で同じサービス ノード グループを共有できないことに注意してください。
appnav_policy_name は、サービス コンテキストの AppNav ポリシーの名前です。
VRF_name は、AppNav-XE コンポーネントによって認識されるトラフィックのための LAN インターフェイス上の VRF の名前です。複数の VRF 名を入力できます。最大 64 の VRF 名を定義できますが、サポートされる VRF の数に制限はありません。VRF グローバルは、VRF なしのトラフィックを識別することを除けば、他の VRF 定義と同じです。VRF 名は、次のような順番に一覧表示されます。
サービス コンテキストに VRF を設定しなかった場合、システムは自動的に vrf default のデフォルト設定を適用します。vrf default の目的は、設定された VRF 名または vrf global に一致しないトラフィックを一致させることです。
パケットに対する適切なサービス コンテキストの選択には、次のロジックが使用されます。システムは、サービス コンテキストに設定されている VRF 名(または vrf global)と、パケットが通過する LAN インターフェイス上の VRF を比較します。一致が検出されると、システムは対応するサービス コンテキストを選択します。一致が存在しない場合、システムは vrf default のサービス コンテキスト(使用可能な場合)を選択します。このようなサービス コンテキストがない場合、システムはパケットをパススルーします。
現在、AppNav-XE コンポーネントによってサポートされているサービスは WAAS のみです。
AppNav-XE コンポーネントをイネーブルにするには、WAN インターフェイスを識別し、 service-insertion コマンドを使用します。
(注) デュアル RP Cisco ASR 1000 プラットフォーム上では、サブインターフェイスで service-insertion コマンドを使用しないでください。
(注) インターフェイスの、着信と発信の両方の TCP トラフィックは、その VRF と、VRF で識別されるサービス コンテキストに関連付けられたサービス ポリシーに基づき、AppNav 処理に従います。
• 「AppNav サービス ノード自動検出機能のイネーブル化(Cisco CSR 1000V シリーズのみ)」
• 「AppNav サービス ノード自動検出機能のディセーブル化(Cisco CSR 1000V シリーズのみ)」
AppNav サービス ノード自動検出機能を設定するには、次の手順を実行します。
ステップ 1 Cisco IOS-XE では、次のコマンドを入力します。 SNG_name パラメータには、AppNav サービス ノード自動検出機能をイネーブルにするサービス ノード グループの名前を入力します。WAAS デバイスが AppNav-XE コンポーネントと同じサブネット内にあることを確認します。
ステップ 2 次のコマンドを入力して、機能をイネーブルにします。
ステップ 3 WAAS デバイス上では、次のコマンドを入力します。
ステップ 4 使用するインターフェイスを選択し、それが AppNav-XE サービスの要求元と同じサブネット内にあることを確認します。インターフェイスが指定されていない場合、デフォルトは GigabitEthernet0/0 です。
ステップ 5 次のコマンドを入力して、AppNav サービス ノード自動検出機能を設定およびイネーブル化します。
次のいずれかを実行して、AppNav サービス ノード自動検出機能をディセーブルにします。
• Cisco IOS-XE に移動し、次のコマンドを入力して、システム全体のサービス ノード自動検出機能をディセーブルにします。
• 次のように、WAAS ノードのサービス応答機能をディセーブルにします。
AppNav-XE 設定を削除するには、次の手順を実行します。
ステップ 1 コンフィギュレーション モードで、WAN インターフェイスから代行受信を削除します。次の CLI コマンドを使用します。
ステップ 2 AppNav サービス コンテキストをディセーブルにします。次の CLI コマンドを使用します。
ステップ 3 AppNav サービス コンテキスト、サービス ノード グループ、および AppNav コントローラ グループを削除します。次の CLI コマンドを使用します。
ステップ 4 AppNav ポリシー マップ、クラス マップ、およびアクセス リストを削除します。次の CLI コマンドを使用します。
パケットが別のポート チャネルに分散されるようにするため、パケットの IP アドレスをスワップするようデータプレーンに指定して、AppNav-XE のポート チャネルのサポートを設定できます。
このコマンドにより、AppNav-XE は IP アドレスがスワップされるサービス ノードからのパケットも処理できるようになります。