WCCP は、Cisco Content Engine（または WCCP を実行する他のコンテンツエンジン）を使用して、ネットワークのトラフィックパターンをローカライズし、ローカルでコンテンツ要求を実行できるようにします。トラフィックのローカライズによって伝送コストを引き下げ、ダウンロード時間を短縮できます。

WCCP によって、Cisco IOS XE プラットフォームはコンテンツ要求を透過的にリダイレクトできます。透過的リダイレクションを使用すると、ユーザーは、Web プロキシを使用するようにブラウザを設定せずに、コンテンツ要求をローカルで実行できます。ユーザーはターゲット URL を使用してコンテンツを要求できます。また、ユーザーの要求はコンテンツ エンジンに自動的にリダイレクトされます。この場合の「透過的」とは、エンドユーザーが要求したファイル（Web ページなど）が、元々指定していたサーバーからではなく、コンテンツエンジンから送信されることをそのユーザーが意識しないという意味です。

要求を受信したコンテンツエンジンは、独自のローカルキャッシュからサービスを提供しようとします。要求した情報が存在しない場合、コンテンツ エンジンから独自の要求が元のターゲット サーバーに発行され、必要な情報が取得されます。コンテンツエンジンは、要求された情報を取得すると、要求元のクライアントに転送し、以降の要求に対応するためにキャッシュします。その結果、ダウンロードのパフォーマンスが最大になり、送信コストが大幅に削減されます。

WCCP により、一連のコンテンツエンジン（コンテンツエンジンクラスタと呼ばれる）が 1 つまたは複数のデバイスにコンテンツを提供できるようになります。ネットワーク管理者は、このようなクラスタ処理機能によって容易にコンテンツ エンジンを拡張し、高いトラフィック負荷を管理できます。シスコ クラスタ処理テクノロジーを使用すると、各クラスタ メンバを同時に実行できるため、リニア スケーラビリティが実現します。クラスタ処理コンテンツ エンジンによって、キャッシュ ソリューションのスケーラビリティ、冗長性、および可用性が大幅に改善されます。最大 32 個のコンテンツ エンジンをクラスタ処理し、目的の容量まで拡張できます。

WCCP マスク割り当て機能によって、（デフォルトのハッシュ割り当て方式ではなく）WCCP サービスのロード バランシング方式としてマスク割り当てを使用できます。

Application and Content Networking System（ACNS）ソフトウェアを実行するコンテンツエンジンの場合、mask-assign キーワードを指定した wccp custom-web-cache コマンドを使用して、マスク割り当てを設定します。Cisco Wide Area Application Services（WAAS）ソフトウェアを実行するコンテンツエンジンの場合、mask-assign キーワードを指定した wccp tcp-promiscuous コマンドを使用して、マスク割り当てを設定します。

複数のデバイスが WCCPv2 を使用して 1 つのコンテンツエンジンクラスタにサービスを提供できます。次の図に、複数のデバイスを使用した設定例を示します。

クラスタ、および同じサービスを実行しているクラスタに接続するデバイス内のコンテンツエンジンのサブセットは、サービスグループと呼ばれます。利用可能なサービスには、TCP および UDP リダイレクションが含まれます。

WCCPv2 の場合、各コンテンツエンジンがサービスグループ内のすべてのデバイスを認識している必要があります。サービスグループ内のすべてのデバイスのアドレスを指定するには、次のいずれかのメソッドを選択する必要があります。

• ユニキャスト：グループ内の各デバイスの IP アドレスリストを、各コンテンツエンジンで設定します。この場合、グループ内の各デバイスのアドレスは、設定の際、コンテンツエンジンごとに明示的に指定する必要があります。

• マルチキャスト：単一のマルチキャスト アドレスを各コンテンツ エンジンで設定します。マルチキャスト アドレス メソッドの場合、コンテンツエンジンは、サービスグループのすべてのスイッチに提供されるシングルアドレス通知を送信します。たとえば、コンテンツエンジンは、パケットを常にマルチキャストアドレス 224.0.0.100 に送信するように指示できます。その場合、マルチキャストパケットは、WCCP を使用してリッスンしているグループ用に設定されたサービスグループ内のすべてのデバイスに送信されます（詳細については、ip wccp group-listen インターフェイス コンフィギュレーション コマンドを参照してください）。

マルチキャスト オプションの場合に必要な操作は、各コンテンツ エンジンで単一のアドレスを指定することだけなので、設定が容易です。このオプションを使用して、サービス グループからルータを動的に追加および削除できます。毎回、異なるアドレス リストを使用してコンテンツ エンジンを再設定する必要はありません。

WCCPv2 での設定は次の順序で行います。

1. 各コンテンツエンジンは、ルータリストを使用して設定されます。

2. 各コンテンツエンジンは、各自の存在と、通信の確立に使用されたすべてのデバイスのリストについて通知します。ルータは、グループ内のコンテンツ エンジンのビュー（リスト）で応答します。

3. そのビューがクラスタ内のすべてのコンテンツエンジンで一貫している場合、1 つのコンテンツエンジンがリードとして指定され、デバイスがパケットのリダイレクト時に展開する必要のあるポリシーが設定されます。

WCCPv2 では、複数のデバイスをキャッシュエンジンのクラスタに追加できます。サービスグループで複数のデバイスを使用すると、冗長構成、インターフェイスの集約、およびリダイレクトの負荷分散が可能になります。WCCPv2 は、サービスグループごとに最大 32 のデバイスをサポートします。各サービス グループの確立および保守は独立して行われます。

WCCPv2 には、パスワードとハッシュメッセージ認証コード - メッセージダイジェスト（HMAC MD5）規格を使用して、サービスグループの一部になるスイッチとコンテンツエンジンを制御できる、オプションの認証機能があります。共有秘密キー MD5 ワンタイム認証（ip wccp password password グローバル コンフィギュレーション コマンドを使用して設定）では、メッセージを代行受信、検査、およびリプレイから保護します。

エラーまたは過負荷のために、コンテンツエンジンが、キャッシュした要求オブジェクトを提供できない場合、コンテンツエンジンは、元々指定されていた宛先サーバーに転送するように、要求をデバイスに返します。WCCPv2 には、機能していないコンテンツ エンジンから返送された要求を判断できるパケットのチェック機能があります。デバイスは、この情報を使用して（要求をコンテンツエンジンクラスタに再送信しようとするのではなく）要求を元の宛先サーバーに転送できます。このプロセスのエラー処理はクライアントに意識されません。

コンテンツ エンジンがパケットを拒否し、パケット返送機能を開始する場合、一般的に次のような理由があります。

• コンテンツ エンジンが過負荷になり、パケットを処理する余裕がなくなった場合

• コンテンツ エンジンが、パケットのキャッシング機能が低下する特定の条件についてフィルタリングしている場合（たとえば、IP 認証が有効になった場合）

WCCP は IP パケットを代行受信し、IP ヘッダーに指定されている宛先以外の宛先に、そのパケットをリダイレクトします。パケットは、インターネット上にある Web サーバーから、宛先のローカルの Web キャッシュにリダイレクトされるのが一般的です。

場合によっては、Web キャッシュでリダイレクトされたパケットを適切に管理できず、パケットを変更せずに元のデバイスに返送することがあります。このようなパケットはバイパスパケットと呼ばれ、カプセル化なしのレイヤ 2 転送（L2）を使用して、発信元のデバイスに返送されます。デバイスはカプセル化を解除し、通常どおりにパケットを転送します。入力インターフェイスと関連付けられている VRF（関連付けられている VRF がない場合はグローバル テーブル）は、パケットを宛先にルーティングするときに使用されます。

パケットを代行受信し、Cisco スイッチまたはルータによって外部 WCCP クライアントデバイスにリダイレクトするアプリケーションの場合、WCCP クライアントデバイスを使用できないと、状況によってはアプリケーションのパケットをブロックする必要があります。このブロックを実行するには、WCCP クローズド サービスを設定します。WCCP サービスがクローズドに設定されている場合、サービスを提供するもののアクティブなクライアントデバイスを持たないパケットは破棄されます。

デフォルトでは、WCCP はオープン サービスとして動作します。この場合、中間デバイスがなくても、クライアントとサーバー間の通信は正常に進行します。

ip wccp service-list コマンドは、クローズドモードとオープンモード両方のサービスに使用できます。アプリケーション プロトコル タイプまたはポート番号を登録するには、service-list キーワードと service-access-list 引数を使用します。オープンサービスまたはクローズドサービスを選択するには、mode キーワードを使用します。

入力インターフェイスで WCCP のリダイレクションが有効になっている場合、パケットは WCCP によってリダイレクトされ、代わりに IP ヘッダーで指定された宛先以外のインターフェイスで出力されます。パケットは、引き続き入力インターフェイスで設定された ACL の影響下にあります。ただし、リダイレクションによって、パケットが元の出力インターフェイスで設定された ACL をバイパスする可能性があります。元の出力インターフェイスで ACL が設定されているためにドロップされたパケットは、リダイレクト出力インターフェイスに送信される場合があります。その結果、セキュリティ上の問題が発生する可能性があります。WCCP アウトバウンド ACL チェック機能を有効にすると、リダイレクトされたパケットは、元の出力インターフェイスで設定された ACL 条件の対象になります。

WCCP は、Cisco IOS XE ソフトウェアのコンポーネントで、定義済みの特性を持つトラフィックを元の宛先から代替の宛先へとリダイレクトします。一般的な WCCP アプリケーションには、リモート Web サーバー宛ての発信トラフィックをローカル Web キャッシュにリダイレクトして、応答時間を改善し、ネットワーク リソースの使用状況を最適化する機能があります。

リダイレクトに選択されるトラフィックの性質は、コンテンツエンジンで指定されるサービスグループ（下の図を参照）によって定義され、WCCP を使用してスイッチやルータに伝達されます。

WCCPv2 は、サービスグループごとに最大 32 のスイッチをサポートします。各サービス グループの確立および保守は独立して行われます。

WCCPv2 では、トラフィックの代行受信およびリダイレクションを行うために使用されている論理リダイレクション サービスを基にサービス グループを使用します。標準のサービスは Web キャッシュです。Web キャッシュは TCP ポート 80（HTTP）トラフィックを代行受信し、そのトラフィックをコンテンツ エンジンにリダイレクトします。Web キャッシュサービスの特徴はスイッチとコンテンツエンジンの両方から認識されているため、このサービスは既知のサービスと呼ばれます。サービスの識別よりも詳細な既知のサービスの説明は必要ありません。標準の Web キャッシュサービスを指定するには、ip wccp コマンドと web-cache キーワードを使用します。

（注）	スイッチでは同時に複数のサービスが実行できます。また、スイッチとコンテンツエンジンは、同時に複数のサービスグループの一部になることができます。

ダイナミックサービスは、コンテンツエンジンによって定義されます。コンテンツエンジンは、代行受信するプロトコルまたはポート、およびトラフィックの配信方法をスイッチに指示します。ダイナミック サービス グループのトラフィックの特性に関する情報は、スイッチ自体にはありません。この情報は、グループに参加する最初のコンテンツエンジンから提供されるためです。ダイナミック サービスでは、1 つのプロトコルに最大 8 ポートを指定できます。

たとえば、Cisco Content Engine ではダイナミック サービス 99 を使用して、リバース プロキシ サービスを指定します。ただし、他のコンテンツ エンジン デバイスでは、その他のサービスにこのサービス番号を使用する可能性があります。

インターフェイスは、WCCP サービスを複数使用して設定できます。1 つのインターフェイスに複数の WCCP サービスを設定する場合、サービスの優先順位は、他の設定済みサービスのプライオリティと比較した、そのサービスの相対的なプライオリティによって変わります。各 WCCP サービスには、定義の一部にプライオリティ値があります。複数の WCCP サービスを使用してインターフェイスを設定する場合、パケットの優先順位は、プライオリティ順でサービス グループに対して対応付けられます。

（注）	WCCP サービスグループの優先順位は、Cisco IOS XE ソフトウェアでは設定できません。

ip wccp check services all コマンドを使用すると、すべての設定済みサービスを一致についてチェックし、必要に応じてそのサービスに関するリダイレクションを実行するように WCCP を設定できます。パケットのリダイレクト先キャッシュは、リダイレクト ACL およびサービスの優先順位で制御できます。複数の WCCP サービスをサポートするには、ip wccp check services all コマンドをグローバルレベルで設定する必要があります。

WCCP サービスをリダイレクト ACL を使用して設定する場合、IP パケットに一致するサービスが見つかるまで、プライオリティ順にサービスがチェックされます。パケットに一致するサービスがない場合、パケットはリダイレクトされません。サービスがパケットに一致し、サービスにリダイレクト ACL が設定されている場合、IP パケットは ACL に対してチェックされます。ACL によってパケットが拒否される場合、ip wccp check services all コマンドを設定しない限り、低い優先順位のサービスにパケットは渡されません。ip wccp check services all コマンドを設定すると、インターフェイスで設定されている残りの低い優先順位のサービスに対して、引き続きパケットのマッチングが試行されます。

WCCP VRF は、Virtual Routing and Forwarding（VRF）のサポートを追加することで WCCPv2 プロトコルを強化します。WCCP VRF では、グローバルに定義するだけでなく、VRF 単位でサービスグループを設定できます。サービス ID の他に、デバイスに到着する WCCP パケットの VRF が、設定されたサービスグループにキャッシュエンジンを関連付けるために使用されます。同じ WCCP VRF に、リダイレクトが適用されたインターフェイス、キャッシュエンジンに接続されたインターフェイス、およびリダイレクトされなかったパケットが残されるインターフェイスを設定する必要があります。

WCCP をイネーブルにすると、CPU の使用率が非常に高くなる場合があります。WCCP カウンタを使用すると、直接スイッチでバイパストラフィックを確認できます。また、その原因が WCCP の有効化による CPU の使用率の高さにあるかどうかを示すことができます。場合によっては 10 % のバイパス トラフィックが標準で、他の状況では 10 % が高いこともあります。ただし、25% を超える数値の場合、Web キャッシュの状況をより詳しく調査する必要があります。

バイパス トラフィックのレベルが高いことをカウンタが示している場合、次の手順は、コンテンツ エンジンのバイパス カウンタを確認し、コンテンツ エンジンがトラフィックのバイパスを選択した理由を判定します。さらに詳細に調査するには、コンテンツ エンジン コンソールにログインし、CLI を使用します。カウンタを使用すると、バイパスするトラフィックの割合を決定できます。

特定のサービスに関してデバイスで保持している WCCP 統計情報（カウント）を削除するには、clear wccp コマンドを使用します。

すべての WCCP グローバル統計情報（カウント）を表示するには、show wccp コマンドを使用します。