高 CPU 使用率における Catalyst 6500 プラットフォームでの WCCP コンフィギュレーション ガイド

概要

このドキュメントでは、Cisco Catalyst 6500 シリーズ プラットフォームで Web Cache Communication Protocol（WCCP）を使用する方法について説明します。

WCCP は、本来、Web トラフィック（HTTP）を代行受信し、ローカル キャッシュのデバイスに転送する方式として設計されています。転送先のデバイスで、ローカル ロケーションからクライアントに提供され、貴重な WAN 帯域幅を節約できます。

ネットワーク ユーザの視点からすると、WCCP はトランスペアレントです。これは、レイヤ 3（L3）デバイスを通過してローカル キャッシュのデバイスに配信される Web トラフィックを識別し、リダイレクトするために、ユーザによる特別な設定なしで、ネットワーク レベルで使用されるためです。WCCP は、本来、Web トラフィック用に設計されていますが、トランスペアレントなリダイレクション方式であるため、少容量リンク上を介した大容量コンテンツの転送に関連する他の問題に対処するための非常に有用なメカニズムになりました。このため、追加のプロトコルのサポートが新しい WCCP バージョンに追加されました。この追加された技術としては、HTTP、HTTPS、FTP、ビデオ ストリーミングなどのプロトコルや、Common Internet File System（CIFS）などのファイル キャッシュ技術があります。 これらの技術では、Wide Area File Services（WAFS）、Wide Area Application Services（WAAS）、Application Oriented Networking（AON）などの新しい Cisco ソリューションとプラットフォームや、Application and Content Networking Software（ACNS）の拡張機能をサポートしています。

ビデオベースの通信とトレーニングなどの最新の生産性のツールや、ライブ ビデオおよびオンデマンド ビデオを実装する企業の増加に伴って WCCP の採用が増えています。データセンターの統合などのコストを抑制する取り組みによって、WCCP で追加の非常に高い帯域幅サービスをサポートする必要性が生じています。

今日のコンテンツの豊富なネットワークでは WCCP が重要であるため、Catalyst 6500 など一部のプラットフォームでは、このプロトコルに必要な CPU の負荷を軽減するように、ハードウェアによる WCCP のパフォーマンスの向上を実装しました。このドキュメントでは、Catalyst 6500 に WCCP を導入して、ハードウェアの使用率を最大化し、CPU の負荷を軽減する方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• WCCP
• Cisco Catalyst 6500 シリーズ スイッチ
• Cisco IOS(R) ソフトウェア

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Cisco Catalyst 6500 シリーズ スイッチ
• スーパーバイザ エンジン 2T（ポリシー フィーチャ カード 4）を導入した Cisco IOS ソフトウェア リリース 12.1(50) SY 以降
• スーパーバイザ エンジン 720（ポリシー フィーチャ カード 3）を導入した Cisco IOS ソフトウェア リリース 12.2(18)SXD1 以降

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

WCCP 機能の概要

WCCP と総称している機能には、実際は 3 個のコンポーネントを含みます。

1. ルータまたはスイッチでのみ実装される機能
2. Web キャッシュなど、トラフィック処理エンティティでのみ実装される機能
3. 両側に実装された WCCP

このドキュメントでは、WCCP の運用に関する次の 3 つの特性を確認します。

1. 割り当て方法は、どのWCCPトラフィックと、どのWCCPデバイスがトラフィックの宛先に選択されるかを決定します。WCCPプロトコルは、クラスタ化された複数のデバイスをサポートします。
2. リダイレクション方式によって、トラフィックが通過していた通常のネットワーク パスから変更する必要がある場合に、WCCP アプライアンスに対するトラフィック フローが転送されます。
3. リターン方式によって、トラフィックを処理できない場合に、WCCP アプライアンスからルータにトラフィックを返送する方法が決まります。WCCP アプライアンスで要求を処理する場合、パケットは要求側に直接返されます。

WCCP および Catalyst 6500

Catalyst 6500 スーパーバイザ エンジン 2、スーパーバイザ エンジン 32、スーパーバイザ エンジン 720 では、次の WCCP の機能や方式をサポートしています。

• WCCP バージョン 2（WCCPv2）
• ハッシュ ベースの割り当て方式
• マスク ベースの割り当て方式（ハードウェア アクセラレーション）
• L3 総称ルーティング カプセル化（GRE）のリダイレクション方式（スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 でのハードウェア アクセラレーション）
• レイヤ 2（L2）リダイレクション方式（スーパーバイザ エンジン 2、スーパーバイザ エンジン 32、およびスーパーバイザ エンジン 720 でのハードウェア アクセラレーション）
• GRE リターン方式
• Cisco IOS ソフトウェア リリース 12.2SXH による L2 リターン方式（スーパーバイザ エンジン 2、スーパーバイザ エンジン 32、およびスーパーバイザ エンジン 720 でのハードウェア アクセラレーション）

機能の詳細については、『WCCP の設定』（Cisco 6500 シリーズ Cisco IOS ソフトウェア コンフィギュレーション ガイド、12.2SX）を参照してください。

WCCP 割り当て方式

WCCP 割り当てによって、WCCP プロトコルでリダイレクトするトラフィックおよびリダイレクトされたトラフィックを受信する WCCP エンティティが決まります。

WCCP がルータのインターフェイスと WCCP エンティティに設定されている場合、リダイレクションを行うデバイス（Catalyst 6500）では、どのトラフィックをリダイレクトするのかおよびこのトラフィックの送信先を知る必要があります。サービス グループ クラスタ内の WCCP エンティティは、すべて WCCP プロトコルを介して Catalyst 6500 と通信します。ただし、クラスタの動作を制御するためにクラスタを代表する 1 台の WCCP アプライアンスが選択されます（割り当て方式、リダイレクション方式などによる）。 WCCP アプライアンスおよびルータでは、サービス グループ内の Web キャッシュ間でパケットを配信する方式をネゴシエートできます。サービス グループは最大 32 台のルータと 32 台の WCCP エンティティ間の多対多関係として定義されます。ネゴシエーションはサービス グループごとです。したがって、複数のサービス グループに関与する Web キャッシュは、サービス グループごとに異なる割り当て方式をネゴシエートする可能性があります。現在使用可能な WCCP サービスは次のとおりです。

*ユーザ設定可能なサービスは、着信方向または発信方向に対して適用されたインターフェイス レベルのコマンドを使用して Catalyst 6500 で実装されます。着信または発信の選択の影響については後述しますが、リダイレクトのリストを WCCP と組み合わせて最大限のハードウェア パフォーマンスを得られるため着信が推奨される方法です。

WCCP 用に設定されると、ルータでは WCCP の通信メッセージに含めて、サービス グループでサポートされている割り当て方式をアドバタイズします。このようなメッセージが存在しない場合は、Catalyst 6500 はデフォルトのハッシュ ベースの割り当て方式だけをサポートしていることを意味します。

Catalyst 6500 と WCCP アプライアンスの間でネゴシエーションが完了すると、WCCP によって指定された WCCP エンティティが、リダイレクトするトラフィックとこのトラフィックを割り当てる WCCP エンティティを Catalyst 6500 に通知します。たとえば、WCCP エンティティでは、使用できる WCCP デバイスが 5 台以上存在する場合に、特定のサブネットからのすべての Web トラフィックを、サービス グループのキャッシュ エンジン 1 ～ 4 にリダイレクトするように Catalyst 6500 に通知することがあります。

WCCP で使用できる割り当て方式は 2 種類あります。

1. ハッシュ ベースの割り当て（デフォルト）では、WCCP 指定されたアプライアンスからディレクティブとともに、ソフトウェア ベースのハッシュ アルゴリズムを使用して、トラフィックを受信する WCCP アプライアンスを判別します。スーパーバイザ エンジン 32 またはスーパーバイザ エンジン 720 プラットフォームでは、NetFlow ハードウェア リソースを使用して、一定レベルのハードウェア アシストを適用します。
2. マスク ベースの割り当てでは、Catalyst 6500 のハードウェア機能、具体的にはアクセス コントロール リスト（ACL）の Ternary Content Addressable Memory（TCAM）を使用して、WCCP エンティティにトラフィックを割り当てます。この方式が推奨されます。

WCCP サービス グループ内のすべてのデバイスは、同じ割り当て方式を使用する必要があります。割り当て方式は、WCCP エンティティで設定し、Catalyst 6500 によって学習されます。詳細については、『WCCP の設計上の推奨事項』を参照してください。

ハッシュ ベースの割り当て方式の詳細

ハッシュ ベースの割り当てメカニズムはソフトウェア内で実行されるアルゴリズムを使用します。ハッシュ アルゴリズムを利用するために、特定のフローに含まれる最初のパケットが、ハードウェア パスからソフトウェア パスに送信されて、ここでハッシュが実行されます。

ソフトウェアはフローのさまざまなコンポーネントの XOR ハッシュを実行し、さまざまな WCCP エンティティへのトラフィックを分割するハッシュを見つけます。ハッシュ メカニズムによって、使用できる WCCP エンティティ間でのトラフィックの分配方法が決定されます。

ハッシュ結果は、そのフローの後続のパケットが転送されるハードウェア NetFlow テーブルにプログラムされます。WCCP によってハッシュに使用できるフィールドに関係なく、5 タプルすべてが使用されます。これは WCCP をイネーブルにすると、NetFlow が interface full-flow モードになることを意味します。このことは、NetFlow リソースを必要とする可能性がある他の機能に影響します。詳細については「WCCP の問題」を参照してください。

Catalyst 6500 での WCCP に関する一般的な質問として「WCCP をイネーブルにすると、CPU 使用率の上がるのはなぜですか」があります。 ハッシュ ベースの割り当てが使用されている場合は、各フローに含まれる最初のパケットに対するソフトウェア ベースの処理によって CPU に負荷がかかるため、使用率が上がる原因の大半になります。現在使用可能なポリシー フィーチャ カード 3（PFC3）転送ハードウェアでは、発信機能として WCCP が設定されているか、ハッシュ ベースの割り当てが使用中（イングレスまたはイーグレス）の場合は、一定レベルのソフトウェア処理が常に必要です。

ハッシュ ベース割り当て方式を使用すると、次の機能に影響します。

• NetFlow テーブル：PFC でサポートされるエントリの数が制限され、NetFlow テーブル全体に対してフロー マスクが interface full-flow に変わります。
• CPU 使用率：各フローの最初のパケットがソフトウェア スイッチングされるため CPU 使用率が上がります。
• パフォーマンス：CPU を保護するために、ルックアップのためにトラフィックが CPU に送信されるレートが制限されます。
• NetFlow 機能：NetFlow リソースが WCCP によって使用される場合は、NetFlow リソースを使用する他の機能に影響が及ぶ可能性があります。

ソフトウェア処理のハッシュ ベースの割り当て要件による制限は、イングレスとイーグレスの両方のトラフィックにも適用されます。CPU への影響は、サービス拒否（DoS）攻撃など非定型のトラフィック パターンがネットワークで発生していると悪化することがあります。一般的な攻撃やワームの大量発生では、ホストから送信されたすべてのパケットは新しい宛先またはポートに向かいます。この結果、パケットがソフトウェアで処理されます。WCCP でリダイレクトされたトラフィックは、最初のパケット処理のために CPU に送信されているため、保護方式は限られています。インターフェイスで「拒否」ACL エントリを使用すると、CPU に送信される内容が制限されることがあります。ただし、このようなタイプの攻撃に対する、レート リミッタなどの保護機構はありません。

マスク ベースの割り当て方式の詳細

マスク ベースの割り当ては、入力と出力のいずれに設定されているのかによって異なる方法で処理されます。

入力のマスク ベースの割り当てでは、パケット転送の前のマスクが ACL TCAM にプログラムされているため、NetFlow テーブルおよびソフトウェア処理は必要ではありません。WCCP エンティティでは多数のハッシュ バケットを選択し、アドレス マスクおよび WCCP アプライアンスを各バケットに割り当てます。割り当てが完了すると、スーパーバイザでは、バケットごとに 1 つの TCAM エントリと 1 つのハードウェア隣接関係をプログラムし、L2 リライトによって、アドレス マスクに一致するパケットを関連付けられた WCCP アプライアンスにリダイレクトします。

WCCP が入力機能として設定されている場合は、ハードウェア ACL テーブルの ACL リダイレクト隣接関係エントリを使用できます。WCCP がエントリと一致すると、L2 リライトまたは GRE カプセル化を行うために、適切な隣接関係が使用されます。したがって、マスク割り当てが入力で使用されている場合は、L2 リライト（スーパーバイザ エンジン 2、スーパーバイザ エンジン 32、スーパーバイザ エンジン 720）と GRE カプセル化（スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 のみ）の両方がハードウェアで実行されます。

WCCP が出力機能として設定されている場合、フロー内のパケットはシステムによってすでにルーティングされているため、ACL リダイレクト隣接関係はハードウェアでサポートされません。フローの最初のパケットがソフトウェアに送信されて処理されます。適切なリダイレクト隣接関係が決まると、NetFlow ハードウェア（ACL TCAM ではない）にプログラムされます。ここでエントリは、L2 リライトまたは GRE カプセル化を実行する隣接関係をポイントしています。フロー内の後続のパケットは、NetFlow ハードウェアによってハードウェア内でリダイレクトされます。

注：WCCP が出力機能として設定されている場合、マスク割り当てではソフトウェア処理を必要とします。これにより、マスク ベースの割り当て方式によるすべての利点が打ち消されます。

2 つのマスク ベース オプションのうちで、入力マスク ベース割り当てだけで、最初と後続のパケットに対する完全なハードウェア ベース転送が可能です。ハッシュ ベースの割り当ての使用や出力処理の使用など他のオプションでは、最初のパケットのソフトウェア スイッチングと後続パケットのハードウェア NetFlow スイッチング転送が発生します。

WCCP リダイレクション方式

Catalyst 6500 ではなく WCCP エンティティが、Catalyst 6500 へのハッシュ テーブルとマスク/値のセットを決定するため、リダイレクト方式は Catalyst 6500 スイッチではなくそのアプライアンスで設定します。Catalyst 6500 では、WCCP エンティティやグループとの WCCP 通信に基づいて、使用できる最善のリダイレクション方式を決定します。このネゴシエーションによって、リダイレクトされたトラフィックをアプライアンス転送する方法が決まります。2 つのリダイレクション オプションがあります。L3（GRE）および L2（MAC アドレスの書き換え）。

WCCPv1 を使用する場合、唯一のオプションは GRE カプセル化とも呼ばれる L3 リダイレクションです。L3 リダイレクションでは、WCCP でダイレクトされた各パケットは、GRE ヘッダー内にカプセル化されてプロトコル タイプ 0x883E でマークされ、4 オクテット WCCP のリダイレクト ヘッダーが続きます。パケットは続いて WCCP アプライアンス（キャッシュ エンジンなど）に送信されます。

WCCPv2 の導入に伴って、Catalyst 6500 などのハードウェア スイッチング プラットフォームを活用するために、L2 リダイレクション（高速化された WCCP リダイレクション）が追加されました。WCCP で L2 リダイレクションを使用する場合は、WCCP アプライアンスと Catalyst 6500 が隣接している（同じ L2 VLAN 内にある）必要があります。 リダイレクトされた L2 トラフィックでは、GRE カプセル化を使用しません。代わりに、Catalyst 6500 によって、L2 接続された WCCP エンティティの MAC アドレスで MAC 宛先アドレスが書き換えられ、通常のハードウェア スイッチングによって転送されます。

注：WCCP デバイスへの転送方式は、WCCP デバイスでトラフィックを Catalyst 6500 に戻すために使用する方式と同じではない場合があります。WCCP は両方のデバイスがサポートする転送および返信方式をネゴシエートするために使用されます。WCCP リターン方式を参照してください。

L3（GRE）転送方式

WCCP L3 オペレーションでは、カプセル化方式として GRE を使用します。リダイレクトされたパケットは、プロトコル タイプ 0x883e で GRE ヘッダーにカプセル化され、一致するサービス ID とハッシュ バケットを含む 4 バイト WCCP リダイレクション ヘッダーが付随します（WCCPv2 のみ）。 GRE を使用すると、複数の L3（ルート指定）ホップによって WCCP クライアントを Catalyst 6500 から分離できます。

このシナリオでは、WCCP リダイレクションに使用できるオプションは次のとおりです。

1. 入力：L3（GRE）リダイレクション + ハッシュ割り当て。これにはソフトウェア処理が必要です。
2. 入力：L3（GRE）リダイレクション + マスク割り当て。これには、フルハードウェア処理が必要であり、スーパーバイザ エンジン 32 またはスーパーバイザ エンジン 720 でのみ使用できます。
3. 出力：L3（GRE）リダイレクション + ハッシュ割り当て。これにはソフトウェア処理が必要です。
4. 出力：L3（GRE）リダイレクション + マスク割り当て。これにはソフトウェア処理が必要です。

入力：L3（GRE）リダイレクション + ハッシュ割り当て

スーパーバイザ エンジン 2 では、各 GRE パケットは、マルチレイヤ スイッチ フィーチャ カード（MSFC）に送信されて処理されます。GRE カプセル化はハードウェアでサポートされていないため、MSFC は GRE および WCCP の両方のヘッダーに適用する必要があります。この結果、すべてのトラフィックでソフトウェア スイッチングが強制されます。

ハッシュ ベースの割り当て方式では、NetFlow テーブルのエントリを確立するように、スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 によってソフトウェアの全フローで最初のパケットが転送されます。次に、パケットは GRE にカプセル化され（初期パケットのカプセル化および転送はソフトウェアで実施）、WCCP アプライアンスに転送されます。

NetFlowエントリの確立はCPU使用率に影響しますが、その後のパケット転送はSupervisor Engine 720およびSupervisor Engine 32のハードウェアで行われます。トラフィックパターン、特に一意のフローの数は、CPU使用率を決定します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。

スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。

入力：L3（GRE）リダイレクション + マスク割り当て

スーパーバイザ エンジン 2 では、各 GRE パケットは MSFC に送信されて処理されます。GRE カプセル化はハードウェアでサポートされていないため、MSFC は GRE および WCCP の両方のヘッダーに適用する必要があります。この結果、すべてのトラフィックでソフトウェア スイッチングが強制されます。

マスク ベースの割り当て方式では、GRE がネイティブにサポートされているため、スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 によって最初および後続のパケットがハードウェアで転送され、マスク割り当てでは転送のために ACL TCAM ハードウェアを使用します。

出力：L3（GRE）リダイレクション + ハッシュ割り当て

スーパーバイザ エンジン 2 では、各パケットは、MSFC に送信されて処理されます。GRE カプセル化はハードウェアでサポートされていないため、MSFC は GRE および WCCP の両方のヘッダーに適用する必要があります。この結果、すべてのトラフィックでソフトウェア スイッチングが強制されます。

スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 を使用するハッシュ ベースの割り当て方式の場合は、Catalyst 6500 によって、NetFlow テーブル エントリが確立されるようにソフトウェアの全フローで最初のパケットが転送されます。次に、パケットは GRE にカプセル化され、WCCP エンティティに転送されます。

NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。

スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。

出力：L3（GRE）リダイレクション + マスク割り当て

スーパーバイザ エンジン 2 では、各パケットは、MSFC に送信されて処理されます。GRE カプセル化はハードウェアでサポートされていないため、MSFC は GRE および WCCP の両方のヘッダーに適用する必要があります。この結果、すべてのトラフィックでソフトウェア スイッチングが強制されます。

スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 を使用するマスク ベースの割り当て方式では、NetFlow テーブルのエントリを確立するように、全フローで最初のパケットがソフトウェア スイッチングされます。出力 ACL の隣接関係のプログラミングをサポートしているスーパーバイザはありません。このため、このソフトウェア処理が強制され、各フローの最初のパケットに対してハードウェア ACL TCAM ではなく NetFlow リソースが使用されます。次に、パケットは GRE にカプセル化され、WCCP アプライアンスに転送されます。

NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。

スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。

L2 転送方式

L2 フォワーディングを使用する場合、サービス グループ内の WCCP エンティティ（ACNS、WAFS、WAAS など）は同じサブネットの一部であり、Catalyst 6500 と L2 隣接関係にあります。これにより、高スループット、低遅延、およびトラフィックのリダイレクションが実現されます。入力インターフェイス（WCCP が設定されている）と、WCCP アプライアンスが配置されているインターフェイスは、異なる VLAN 上に存在する必要があります。

注：L2 リダイレクションでは、送信元 MAC にルータを設定し、宛先 MAC にキャッシュ エンジンを設定して、パケットが書き換えられます。このリダイレクション方式の唯一の欠点は、キャッシュ エンジンが Catalyst 6500 によって L2 で到達可能である必要があり、設定されている入力 WCCP インターフェイスとは異なる L3 インターフェイス上に存在する必要がある点です。

注：WCCP デバイスへの転送方式は、WCCP デバイスでトラフィックを Catalyst 6500 に戻すために使用する方式と同じではない場合があります。WCCP は両方のデバイスがサポートする転送および返信方式をネゴシエートするために使用されます。WCCP リターン方式を参照してください。

このシナリオで WCCP リダイレクションに使用できるオプションは次のとおりです。

• 入力：L2 リダイレクション + ハッシュ割り当て。これにはソフトウェア処理が必要です。
• 入力：L2 リダイレクション + マスク割り当て。これには、フルハードウェア処理が必要であり推奨されます。
• 出力：L2 リダイレクション + ハッシュ割り当て。これにはソフトウェア処理が必要です。
• 出力：L2 リダイレクション + マスク割り当て。これにはソフトウェア処理が必要です。

入力：L2 + ハッシュ割り当て

L2 + ハッシュ割り当てで入力に設定されている場合、WCCP トラフィックでは、ソフトウェア スイッチングされるように全フローの最初のパケットを送信します。この結果、ハードウェア NetFlow テーブルに NetFlow エントリが作成されます。

注：NetFlow フロー マスクは、interface full-flow モードに設定されます。これは、スイッチに設定されている他の NetFlow 機能に影響する可能性があります。

WCCP は、ステートレス メカニズムであるため、この情報はソフトウェアで維持されません。代わりに、ハードウェアで NetFlow テーブルのエントリとして維持されます。フローの後続トラフィックは、NetFlow テーブル エントリが存在する限り、ハードウェアで転送されます。

NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。

スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。

入力：L2 + マスク割り当て

入力上に設定されている場合、L2 + マスク割り当ては Catalyst 6500 でサポートされている最も効率的な WCCP 方式です。各フローの最初のパケットを含むすべてのトラフィックはハードウェア スイッチングされます。ソフトウェア リダイレクションは必要ありません。最初および後続のパケット転送はハードウェアで実現されます。

Catalyst 6500 のハードウェア ACL TCAM リソースは、WCCP パケットを受信する前に、ハードウェア エントリを事前にプログラミングするために使用されます。

この方式を使用し、ハードウェア スイッチングの全機能を使用するには、WCCP エンティティで L2 リダイレクションおよびマスク ベースの割り当て方式もサポートしている必要があります。この方式の設定は WCCP エンティティで実行し、Catalyst 6500 では WCCP の最初の通信中に WCCP エンティティやグループと最適な方式をネゴシエートします。

出力：L2 + ハッシュ割り当て

出力 L2 + ハッシュ割り当てでは、WCCP トラフィックでは、ソフトウェア スイッチングされるように全フローの最初のパケットを送信します。この結果、ハードウェア NetFlow テーブルに NetFlow エントリが作成されます。

注：NetFlow フロー マスクは、interface full-flow モードに設定されます。これは、スイッチに設定されている他の NetFlow 機能に影響する可能性があります。

また、出方向で設定されている場合、CE に関連付けられている隣接関係を判別するためにフロー内の最初のパケットで追加の転送情報ベース（FIB）ルックアップが必要です。これには、Catalyst 6500 内部でのパケット再循環を必要とします。後続のパケットはハードウェアで NetFlow スイッチングされます。

NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。

スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。

出力：L2 + マスク割り当て

出方向で設定されている場合、L2 + マスク割り当てでは、L2 + ハッシュ割り当ての場合同様、ソフトウェアで各フローの最初のパケットがスイッチングされます。後続のパケットはハードウェアで NetFlow スイッチングされます。

注：NetFlow フロー マスクは、interface full-flow モードに設定されます。これは、スイッチに設定されている他の NetFlow 機能に影響する可能性があります。

PFC2 および PFC3 では出力 ACL の隣接関係のプログラミングをサポートしていません。このため、各フローの最初のパケットに対するソフトウェア処理が強制されます。フローの後続のパケットはハードウェアで転送されます。

NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。

スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。

WCCP リターン方式

WCCP エンティティで要求を処理可能

トラフィックの代行受信に WCCP が使用され、WCCP エンティティがこれらのパケットで完全な操作を実行する場合、パケットは WCCP デバイスからクライアントに返信できる状態にまで処理されます。ネットワーク上のクライアントを送信先とする、この通常どおり処理されたトラフィックは、WCCP デバイスからクライアントに返送するときに特別なカプセル化を必要としません。

WCCP の代行受信の結果、クライアント要求は通常どおり処理されたため（キャッシュからのファイル、キャッシュからの分割ストリーム、WAAS からファイル）、パケット内の宛先アドレスに元の要求側を設定して正常なトラフィックとしてネットワークに送り返すことができます。このトラフィックは、WCCP アプライアンスからクライアントへのネットワーク パスにあれば、Catalyst 6500 によって順当に L3 スイッチングできます。L2 で接続された WCCP アプライアンスがある場合、トラフィックはネットワーク パスにあります。宛先がインターネットまたはイントラネットのサーバではなく元のクライアントになったため、WCCP デバイスから Catalyst 6500 に送り返すためカプセル化は必要ありません。ネットワークでは、次に、他のすべての IP トラフィック フローの同様にこれを処理し、要求されたトラフィックをクライアントに返すために Catalyst 6500 内のハードウェア転送を使用します。

WCCP エンティティで要求を処理できない

WCCP エンティティが要求された操作を実行できないという特定の状況では、WCCP アプライアンスはトラフィックを Catalyst 6500 に返信し、パケットの元の宛先を保存しなければならない可能性があります。カプセル化なしで WCCP エンティティからのこのトラフィックを転送することで、トラフィックのループが発生する可能性があります。サービス試行の失敗をクライアントで検出されないようにし、元の宛先にパケットを送信して実行するには、パケットを変更せず、元の転送パスに再度配置し、WCCP の代行受信なしで元の宛先に転送する必要があります。

WCCP リターン方式では、WCCP を使用して、これらのパケットをカプセル化し、まず、パケットを代行受信したデバイスに返信し、すべてのカプセル化を削除し、代行受信された転送パスに再度配置できます。これらのパケットは、WCCP によって代行受信されていないかのように通常どおり送信される必要があります。

これに該当する例を次に示します。

• トラフィックがバイパスされている、キャッシュが過負荷なトラフィック
• WCCP エンティティによるトラフィックの処理を拒否するキャッシュ デバイスのルール
• デバイス上にないサービスを探しているバイパスされたトラフィック

現在、このリターン方式は、GRE カプセル化の場合にだけ使用でき、Catalyst 6500 ハードウェアではまだサポートされていません。このトラフィックはソフトウェアで処理されるため、大量のトラフィックがこの方式で Catalyst 6500 に返信されると、高 CPU 使用率が発生する可能性があります。Cisco IOS ソフトウェア リリース 12.1(18) SXH では、Catalyst 6500 ハードウェアでサポートされている L2 リターン方式があります。

GRE リターン

12.2(18) SXH よりも前の Cisco IOS ソフトウェア リリースでは、Catalyst 6500 でサポートされる唯一のリターン方式は GRE カプセル化です。リターン トラフィックに付加される GRE ヘッダーに加えて、WCCP ヘッダーも付加されます。GRE はスーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 のハードウェアでネイティブにサポートされていますが、このヘッダーが追加されると GRE はハードウェアでアシストされなくなります。Catalyst 6500 および WCCP アプライアンスの両方が L2 リターン方式をサポートしており、ネゴシエートする必要があることに注意してください。

スーパーバイザ エンジン 2 には、GRE、入力、出力、および WCCP リターンのいずれに対しても GRE ハードウェア サポートはありません。このタイプの GRE の脱カプセル化を処理するために、Cisco IOS ソフトウェアでは、ルート プロセッサ（RP）をポイントするように、WCCP 対応インターフェイス上の WCCP GRE トンネルの受信隣接関係をプログラミングします。この結果、リターン トラフィックはソフトウェア処理されます。

GRE を介して戻す必要がある可能性のあるトラフィックを回避するために、Catalyst 6500 でリダイレクトのリストを使用する方式は、WCCP エンティティから返信されるトラフィックのソフトウェア処理の要件を軽減するために有効です。この方式は、WCCP エンティティでトラフィックを拒否し、強制的に GRE カプセル化して Catalyst 6500 に返信する方式よりもはるかに効率的です。

WCCP サービス グループはスケーラブルであることに注意してください。負荷が原因で超過トラフィックがバイパスされると、このトラフィックは返信されます。その結果、Catalyst 6500 で CPU に負荷がかかります。WCCP サービス グループを適切に拡張するか、さらには過剰に作成することが、この状況を回避する唯一の方法です。

L2 リターンの機能拡張

12.2(18) SXH では、リターン トラフィックをカプセル化する代わりに、オプションの 1 つを使用して、WCCP エンティティで L2 MAC アドレスを書き換えることができます。この L2 リターンの機能拡張（Cisco Bug ID CSCuk59825）により、マスク割り当てを使用する入力リダイレクションを使用するように WCCP が設定されている場合にリターン トラフィックのハードウェアの処理が可能になります。

WCCP オプションの概要

Catalyst 6500 に実装した場合、WCCP は次の表に示すように多くの設定オプションを提供します。WCCP アプライアンスでは、これらのオプションをネゴシエートし、Catalyst 6500 で使用されるオプションを制御することに注意してください。設定は、WCCP 接続の WCCP アプライアンス側で行われます。

ハードウェアの観点からすると、すべての出力 WCCP 設定でソフトウェア処理を必要とし、CPU 使用率に影響します。ハッシュ ベースの割り当て方式を使用する場合は、入力でもソフトウェア処理を必要とし、CPU 使用率に同じ潜在的な影響があります。

Catalyst 6500 での WCCP 導入に推奨される方式は、マスク割り当てを使用する L2 リダイレクションと、使用可能であれば、L2 リターンです。

ヒント：高パフォーマンス、完全なハードウェア ベースの転送が保証されるオプションは 1 つだけです。スーパーバイザ エンジン 2、スーパーバイザ エンジン 32、スーパーバイザ エンジン 720 でのマスク割り当てを使用した入力ベースの L2 リダイレクションです。

WCCP の設計上の推奨事項

これらの推奨設定を使用して、状況に応じた最適な WCCP 導入方式を決定します。

要約

WCCP 入力をリダイレクション方式として使用できるようにネットワークを設計します。優れた設計方法は、L3 分散ネットワーク階層の一部としてキャッシュのスイッチブロックを使用することです。これにより、WCCP で処理されたトラフィックがいくつかの主要な入力ポートで識別できることが保証されます。

• 12.2(18) SXF7 以降の Cisco IOS ソフトウェアを使用します。
• 入力インターフェイス上でトラフィックを識別し、リダイレクトします。
• L2 リダイレクト方式をサポートする WCCP アプライアンスを使用します。
• マスク ベースの割り当て方式をサポートする WCCP アプライアンスを使用します。
• 可能であれば、WCCP アプライアンスによって処理できないトラフィックのために Catalyst 6500 でリダイレクト リストを使用します。
• 出力を使用した NetFlow タイマーまたはスーパーバイザ エンジン 720 を使用したハッシュ ベースの割り当ての設定を調整します。
• WCCP アプライアンスには、専用の L3 環境および SVI/VLAN インターフェイスが必要です。

さらに、シスコ アドバンスド サービスでは、次の設計上の考慮事項を推奨します。

• マスク割り当てによる L2 リダイレクションが完全ではない環境では、スーパーバイザ エンジン 720 を使用してもスーパーバイザ エンジン 2 プラットフォームと同等の性能しか出ません。この状況では、ハードウェアをアップグレードせず、パフォーマンスの向上を想定しないでください。
• 大量トラフィックの要件を持つ、大規模な中央サイト導入では、トラフィック代行受信と転送のために、ポリシーベース ルーティング（PBR）および Cisco Content Switching Model（CSM）/アプリケーション コントロール エンジン（ACE）を使用する設計を検討してください。
• WCCPv2 は、完全な状況の下では期待どおりに動作します。ただし、状況によっては、デバイスが使用不可能になりリロードを必要とする高いレベルにルータの CPU 使用率が到達することがあります。
  
  
  • WCCPv2 は、入力のハードウェア アクセラレーション L2 マスク ベースの割り当てのモードから、MSFC 上の CPU を必要とする他の任意のモードにフォールバックします。
  • WCCP の設定が誤っている（たとえば、入力ではなく出力またはマスク割り当てではなく L2 ハッシュ）。
• Catalyst 6500 を使用する大容量 WCCP 導入（キャッシュ、ストリーミング、WAAS、またはその他の「高トラフィック レート」シナリオ）では、本番環境に完全に導入する前に、実際のトラフィックでパフォーマンス テストを実施する必要があります。

その他の推奨事項

Catalyst 6500 に返送されるパケットを避けるために、スイッチでリダイレクト リストを使用します。リダイレクト リストとして Catalyst 6500 に移動できる、キャッシュ デバイスのルールがあれば、これにより、ハードウェアのパフォーマンスが向上することがあります。

スーパーバイザ エンジン 720 プラットフォームでの NetFlow リソースは、入力 L2 マスク割り当て以外の方式を使用すると、すぐに枯渇することがあります。他の方式では、スーパーバイザ エンジン 720 によって、スーパーバイザ エンジン 2 を超えるパフォーマンスは実現されません。

スーパーバイザ エンジン 720 またはスーパーバイザ エンジン 32 を最適でない設計で使用する必要がある場合は、WCCP の初期パケットの NetFlow 処理を高速化できるために mls ip netflow creation software-mode fast コマンドの使用を検討してください。これにより、スーパーバイザ エンジン 32 とスーパーバイザ エンジン 720 の NetFlow に追加された拡張機能が削除され、スーパーバイザ エンジン 2 の NetFlow ハードウェアと同等のパフォーマンスが実現されます。

マスク割り当て用の Cisco コンテンツ エンジン（CE）の設定は次のとおりです。

• wccp version 2
• wccpルータリスト number ip-address
• wccp サービス router-list-num num mask-assign

NetFlow の使用率を見直し、WCCP で NetFlow エントリを使用し尽くしているかどうかおよびソフトウェア処理を使用しているかどうかを判別するには、次のコマンドを使用します。

• show mls netflow table-contention detailed
• show mls netflow ip sw-installed
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

NetFlow リソースが消費されているために WCCP ソフトウェアに関する問題が発生している場合は、これらのコマンドによって既存のエントリが積極的に空にされ、新しいエントリ用の空きが作成されることがあります。（これは単に NetFlow 領域を上回るエントリがある場合は役に立ちません）。

• mls aging fast time 3 threshold 1
• mls aging long 64
• mls aging normal 32
• mls ip netflow creation software-mode fast（これにより、スーパーバイザ エンジン 2 に存在しなかった、一部のスーパーバイザ エンジン 720 の NetFlow 変更がディセーブルになります）。

パケットのドロップを避けるには、WCCP エンティティで、WCCP が設定されているインターフェイス以外のインターフェイスから送信されるトラフィックをリダイレクトする必要があります。この場合、Catalyst 6500 での WCCP では、すべての条件が満たされるとパケットをドロップします。

• クライアントと WCCP エンティティの両方が同じ L3 インターフェイスにあります。
• WCCP のリダイレクト ポリシーがこのインターフェイスに適用されます。
• GRE リダイレクション方式が使用されています。
• パケット フラグメンテーションのリダイレクトが必要です。
• スーパーバイザ エンジン 720 が使用されています。

この状況は、Catalyst 6500 に組み込まれている保護メカニズムによって引き起こされます。Cisco IOS ソフトウェアには、ループの可能性があり、望ましくない動作を引き起こすことのある、同じ Cisco IOS ソフトウェア仮想インターフェイスに対するパケットの着信と発信を防ぐチェックがあります。これを防ぐには、専用の L3 環境に WCCP アプライアンスを移動します。

User Based Rate Limiting（UBRL）および WCCP は、フローマスクが原因で、単一インターフェイス上で同時に動作しません。各ユニキャスト機能のインターフェイスごとに 1 つのフローマスクがあります。WCCP では full-flow が必要であり、UBRL では、src-only または dst-only を使用します。

WCCPのサポートは、12.2(18)SXF5でSupervisor Engine 2およびL2リターンに追加されました。これは、2007年4月/5月の12.2(18)SXHまでは、Supervisor Engine 720に含まれていませんでした。

WCCP L2 PFC リダイレクションのみが Cisco IOS ソフトウェアのサーバ ロード バランシング（SLB）と一緒に使用できます。他の WCCP 設定は互換性が無く、GRE は機能しません。WCCP acceleratedコマンドは、Supervisor Engine 2/MSFC2にのみ適用されます。このコマンドの目的は、ルータにマスク割り当てとL2リダイレクトのネゴシエートを強制することです。これは、すべてのWCCPリダイレクションがハードウェアで実行されることを意味します。スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 は、このコマンドの必要性なしでこれをネゴシエートします。

解決方法

注：このセクションで使用されるコマンドの詳細については、Command Lookup Tool（登録ユーザ専用）を使用してください。

ACNS

標準トランスペアレント キャッシング リダイレクションでは、WCCP エンティティが、サポートされている方式を WCCP ルータに提示し、この処理を行うように設定する必要がある場合があることに注意してください。Cisco ACNS の場合、この設定例には、最適化された L2 リダイレクトおよびマスク ベースの割り当て方式が必要です。

1. Catalyst 6500 の最適化用に WCCPv2 があることを確認します。
   
   

   ContentEngine(config)# wccp version 2

2. 使用する Catalyst 6500 を定義するルータ リストを設定します。
   
   

   ContentEngine(config)# wccp router-list 1 172.16.16.1

3. 最適化方式を使用するサービスを設定します。
   
   

   ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign

ルータ側では、Catalyst 6500 の設計で、WCCP デバイスが現在のトラフィック パスにない専用 L3 インターフェイス上にあることを保証する必要があります（入力または出力）。 ハードウェアのパフォーマンスを確保するために、単一の出力インターフェイスを選択した場合よりも多くのインターフェイス設定が必要であっても、Catalyst 6500 に対する着信でトラフィック フローをキャプチャする必要があります。理想的な設計は、このデバイスに到達する前にすべてのトラフィックを集約し、少数のインターフェイスだけで WCCP の入力設定を必要とする設計です。

Catalyst 6500 での WCCP 設定は次のとおりです。

1. WCCPv2 を設定します。
   
   

   6500Switch# ip wccp version {1 | 2}

2. WCCP サービス グループを設定します。
   
   

   6500Switch (config)# ip wccp service [accelerated] redirect-list access-list

   高速化コマンドは、12.1E Cisco IOS ソフトウェアを実行しているスーパーバイザ エンジン 2 プラットフォームにだけ使用します。

リダイレクト リストは、リダイレクションで選択する必要があるか選択しない必要があるトラフィックを特定するために使用されます。この ACL はハードウェアで実行できることに注意してください。これは、WCCP デバイスによって処理できないトラフィックのリダイレクションを防ぐ非常に効率的な方法です。デバイスに送信されてここで処理できないトラフィックは、元のトラフィック パスに再配置するためにこの Catalyst 6500 に戻される必要があります。このためには、追加の処理が必要です。WCCP アクセス リストは、標準または拡張アクセス リストです。

この例では 10.1.1.1 から 12.1.1.1 に対するすべての要求がキャッシュをバイパスすること、および他のすべての要求がリダイレクトされることを示します。

6500Switch(config)# ip wccp service redirect-list 120
6500Switch(config)# access-list 120 deny tcp host 10.1.1.1 any
6500Switch(config)# access-list 120 deny tcp any host 12.1.1.1
6500Switch(config)# access-list 120 permit ip any any

リダイレクトするトラフィックを受信する各入力インターフェイスに入力 WCCP 方式を設定します。

Router(config-if)# ip wccp service redirect in

これで WCCP アプライアンスおよびスイッチでの設定が完了するため、トラフィック リダイレクションは、この時点で実行されるはずです。

デバイスの最終的な WCCP 設定は次のようになります。

wccp version 2
wccp router-list 1 router-ip-addresses
wccp service router-list-num 1 l2-redirect mask assign

ip wccp version 2
ip wccp service redirect-list 120
access-list 120 deny tcp ...
access-list 120 deny udp ...
access-list 120 permit ip any any

ip wccp redirect service in

この設定を確認するには、次のコマンドを入力します。

Show ip wccp service detail

マルチキャストを使用したグループ アドレスなど追加 WCCP 設定オプションや、追加の WCCP セキュリティについては、『WCCP を使用した Web キャッシュ サービスの設定』を参照してください。

WCCP IOS の show および debug コマンド

• show ip wccp service-number：「合計リダイレクト パケット」カウントを示します。このカウントはリダイレクトされるフロー、またはセッションの数です。
• show ip wccp service-number detail：「リダイレクト パケット」カウントを示します。このカウントはリダイレクトされるフロー、またはセッションの数です。
• show ip wccp web-cache detail：L2 リダイレクションを使用しているパケットではなくフローの数を示します。
• clear ip wccp：「リダイレクト パケット」情報のカウンタをリセットします。
• show ip wccp service-number view：サービス グループの一部である WCCP デバイスを表示します。
• show ip wccp service-number service：サービスのハッシュ、ポート、および WCCP 優先順位を表示します。複数のサービスがインターフェイスに設定されている場合は、優先順位の高いサービスが最初にヒットします。
• debug ip wccp events：WCCP プロトコルの状態をトラブルシューティングします。
• debug ip wccp packets：WCCP パケット処理エンティティ間の通信を確認します。

WCCP およびハードウェア転送を使用する場合は、一部のカウンタが予想どおりに表示されない可能性があります。

• WCCP ACL が完全にハードウェアで処理される場合、WCCP のカウンタは正確なパケット カウントを表示しない可能性があります。
• WCCP がハッシュ ベースの割り当ておよび NetFlow ハードウェア リソースを使用すると、WCCP のカウンタはパケット数ではなくフロー数を反映する可能性があります。

NetFlow コマンド

NetFlow ハードウェア リソースの使用を必要とする WCCP の設定がある場合は、NetFlow リソースのステータスを確認するには、これらのマルチレイヤ スイッチング（MLS）コマンドと Fabric Manager（FM）コマンドを使用します。

• show mls netflow table-contention detailed
• show mls netflow ip sw-installed
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

WCCP の問題

次の Cisco Bug ID および解決策の表では、WCCP の最適なサポートのために、Cisco IOS ソフトウェア リリース 12.2(18) SXF7 以降を使用するための一般的な推奨事項に対応しています。