このドキュメントでは、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 と総称している機能には、実際は 3 個のコンポーネントを含みます。
このドキュメントでは、WCCP の運用に関する次の 3 つの特性を確認します。
Catalyst 6500 スーパーバイザ エンジン 2、スーパーバイザ エンジン 32、スーパーバイザ エンジン 720 では、次の WCCP の機能や方式をサポートしています。
機能の詳細については、『WCCP の設定』(Cisco 6500 シリーズ Cisco IOS ソフトウェア コンフィギュレーション ガイド、12.2SX)を参照してください。
WCCP 割り当てによって、WCCP プロトコルでリダイレクトするトラフィックおよびリダイレクトされたトラフィックを受信する WCCP エンティティが決まります。
WCCP がルータのインターフェイスと WCCP エンティティに設定されている場合、リダイレクションを行うデバイス(Catalyst 6500)では、どのトラフィックをリダイレクトするのかおよびこのトラフィックの送信先を知る必要があります。サービス グループ クラスタ内の WCCP エンティティは、すべて WCCP プロトコルを介して Catalyst 6500 と通信します。ただし、クラスタの動作を制御するためにクラスタを代表する 1 台の WCCP アプライアンスが選択されます(割り当て方式、リダイレクション方式などによる)。 WCCP アプライアンスおよびルータでは、サービス グループ内の Web キャッシュ間でパケットを配信する方式をネゴシエートできます。サービス グループは最大 32 台のルータと 32 台の WCCP エンティティ間の多対多関係として定義されます。ネゴシエーションはサービス グループごとです。したがって、複数のサービス グループに関与する Web キャッシュは、サービス グループごとに異なる割り当て方式をネゴシエートする可能性があります。現在使用可能な WCCP サービスは次のとおりです。
WCCP サービス | プロトコル |
Web キャッシュ | HTTP |
53 | DNS キャッシュ |
60 | FTP |
61 | WAAS - フォワード |
62 | WAAS - リバース |
70 | HTTPS |
80 | リアルタイム ストリーミング プロトコル(RTSP) |
81 | UDP 上の Microsoft メディア サーバ(MMS)(MMSU) |
82 | MMS over TCP(MMST) |
83 | UDP を使用する RTSP(RTSPU) |
89 | CIFS キャッシュ WAAS |
98 | カスタム Web キャッシュ |
99 | 逆プロキシ |
90 ~ 97 | ユーザ設定可能* |
*ユーザ設定可能なサービスは、着信方向または発信方向に対して適用されたインターフェイス レベルのコマンドを使用して 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 種類あります。
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 が設定されているか、ハッシュ ベースの割り当てが使用中(イングレスまたはイーグレス)の場合は、一定レベルのソフトウェア処理が常に必要です。
ハッシュ ベース割り当て方式を使用すると、次の機能に影響します。
ソフトウェア処理のハッシュ ベースの割り当て要件による制限は、イングレスとイーグレスの両方のトラフィックにも適用されます。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 ハードウェアによってハードウェア内でリダイレクトされます。
2 つのマスク ベース オプションのうちで、入力マスク ベース割り当てだけで、最初と後続のパケットに対する完全なハードウェア ベース転送が可能です。ハッシュ ベースの割り当ての使用や出力処理の使用など他のオプションでは、最初のパケットのソフトウェア スイッチングと後続パケットのハードウェア NetFlow スイッチング転送が発生します。
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 L3 オペレーションでは、カプセル化方式として GRE を使用します。リダイレクトされたパケットは、プロトコル タイプ 0x883e で GRE ヘッダーにカプセル化され、一致するサービス ID とハッシュ バケットを含む 4 バイト WCCP リダイレクション ヘッダーが付随します(WCCPv2 のみ)。 GRE を使用すると、複数の L3(ルート指定)ホップによって WCCP クライアントを Catalyst 6500 から分離できます。
このシナリオでは、WCCP リダイレクションに使用できるオプションは次のとおりです。
スーパーバイザ エンジン 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 で使用できます。
スーパーバイザ エンジン 2 では、各 GRE パケットは MSFC に送信されて処理されます。GRE カプセル化はハードウェアでサポートされていないため、MSFC は GRE および WCCP の両方のヘッダーに適用する必要があります。この結果、すべてのトラフィックでソフトウェア スイッチングが強制されます。
マスク ベースの割り当て方式では、GRE がネイティブにサポートされているため、スーパーバイザ エンジン 32 およびスーパーバイザ エンジン 720 によって最初および後続のパケットがハードウェアで転送され、マスク割り当てでは転送のために ACL TCAM ハードウェアを使用します。
スーパーバイザ エンジン 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 で使用できます。
スーパーバイザ エンジン 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 フォワーディングを使用する場合、サービス グループ内の WCCP エンティティ(ACNS、WAFS、WAAS など)は同じサブネットの一部であり、Catalyst 6500 と L2 隣接関係にあります。これにより、高スループット、低遅延、およびトラフィックのリダイレクションが実現されます。入力インターフェイス(WCCP が設定されている)と、WCCP アプライアンスが配置されているインターフェイスは、異なる VLAN 上に存在する必要があります。
このシナリオで WCCP リダイレクションに使用できるオプションは次のとおりです。
L2 + ハッシュ割り当てで入力に設定されている場合、WCCP トラフィックでは、ソフトウェア スイッチングされるように全フローの最初のパケットを送信します。この結果、ハードウェア NetFlow テーブルに NetFlow エントリが作成されます。
WCCP は、ステートレス メカニズムであるため、この情報はソフトウェアで維持されません。代わりに、ハードウェアで NetFlow テーブルのエントリとして維持されます。フローの後続トラフィックは、NetFlow テーブル エントリが存在する限り、ハードウェアで転送されます。
NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。
スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。
入力上に設定されている場合、L2 + マスク割り当ては Catalyst 6500 でサポートされている最も効率的な WCCP 方式です。各フローの最初のパケットを含むすべてのトラフィックはハードウェア スイッチングされます。ソフトウェア リダイレクションは必要ありません。最初および後続のパケット転送はハードウェアで実現されます。
Catalyst 6500 のハードウェア ACL TCAM リソースは、WCCP パケットを受信する前に、ハードウェア エントリを事前にプログラミングするために使用されます。
この方式を使用し、ハードウェア スイッチングの全機能を使用するには、WCCP エンティティで L2 リダイレクションおよびマスク ベースの割り当て方式もサポートしている必要があります。この方式の設定は WCCP エンティティで実行し、Catalyst 6500 では WCCP の最初の通信中に WCCP エンティティやグループと最適な方式をネゴシエートします。
出力 L2 + ハッシュ割り当てでは、WCCP トラフィックでは、ソフトウェア スイッチングされるように全フローの最初のパケットを送信します。この結果、ハードウェア NetFlow テーブルに NetFlow エントリが作成されます。
また、出方向で設定されている場合、CE に関連付けられている隣接関係を判別するためにフロー内の最初のパケットで追加の転送情報ベース(FIB)ルックアップが必要です。これには、Catalyst 6500 内部でのパケット再循環を必要とします。後続のパケットはハードウェアで NetFlow スイッチングされます。
NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。
スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。
出方向で設定されている場合、L2 + マスク割り当てでは、L2 + ハッシュ割り当ての場合同様、ソフトウェアで各フローの最初のパケットがスイッチングされます。後続のパケットはハードウェアで NetFlow スイッチングされます。
PFC2 および PFC3 では出力 ACL の隣接関係のプログラミングをサポートしていません。このため、各フローの最初のパケットに対するソフトウェア処理が強制されます。フローの後続のパケットはハードウェアで転送されます。
NetFlow エントリの確立は CPU 使用率に影響しますが、後続のパケット転送はハードウェアで実施されます。トラフィック パターン、特に一意のフローの数が、CPU 使用率に影響します。Catalyst 6500 の NetFlow リソースが消費されている場合、すべてのトラフィックはソフトウェアで転送されます。
スーパーバイザ PFC の NetFlow リソースは、さまざまなプラットフォームによって異なります。現在、最大の NetFlow リソースは、スーパーバイザ エンジン 720 プラットフォームの PFC-3BXL で使用できます。
トラフィックの代行受信に WCCP が使用され、WCCP エンティティがこれらのパケットで完全な操作を実行する場合、パケットは WCCP デバイスからクライアントに返信できる状態にまで処理されます。ネットワーク上のクライアントを送信先とする、この通常どおり処理されたトラフィックは、WCCP デバイスからクライアントに返送するときに特別なカプセル化を必要としません。
WCCP の代行受信の結果、クライアント要求は通常どおり処理されたため(キャッシュからのファイル、キャッシュからの分割ストリーム、WAAS からファイル)、パケット内の宛先アドレスに元の要求側を設定して正常なトラフィックとしてネットワークに送り返すことができます。このトラフィックは、WCCP アプライアンスからクライアントへのネットワーク パスにあれば、Catalyst 6500 によって順当に L3 スイッチングできます。L2 で接続された WCCP アプライアンスがある場合、トラフィックはネットワーク パスにあります。宛先がインターネットまたはイントラネットのサーバではなく元のクライアントになったため、WCCP デバイスから Catalyst 6500 に送り返すためカプセル化は必要ありません。ネットワークでは、次に、他のすべての IP トラフィック フローの同様にこれを処理し、要求されたトラフィックをクライアントに返すために Catalyst 6500 内のハードウェア転送を使用します。
WCCP エンティティが要求された操作を実行できないという特定の状況では、WCCP アプライアンスはトラフィックを Catalyst 6500 に返信し、パケットの元の宛先を保存しなければならない可能性があります。カプセル化なしで WCCP エンティティからのこのトラフィックを転送することで、トラフィックのループが発生する可能性があります。サービス試行の失敗をクライアントで検出されないようにし、元の宛先にパケットを送信して実行するには、パケットを変更せず、元の転送パスに再度配置し、WCCP の代行受信なしで元の宛先に転送する必要があります。
WCCP リターン方式では、WCCP を使用して、これらのパケットをカプセル化し、まず、パケットを代行受信したデバイスに返信し、すべてのカプセル化を削除し、代行受信された転送パスに再度配置できます。これらのパケットは、WCCP によって代行受信されていないかのように通常どおり送信される必要があります。
これに該当する例を次に示します。
現在、このリターン方式は、GRE カプセル化の場合にだけ使用でき、Catalyst 6500 ハードウェアではまだサポートされていません。このトラフィックはソフトウェアで処理されるため、大量のトラフィックがこの方式で Catalyst 6500 に返信されると、高 CPU 使用率が発生する可能性があります。Cisco IOS ソフトウェア リリース 12.1(18) SXH では、Catalyst 6500 ハードウェアでサポートされている L2 リターン方式があります。
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 サービス グループを適切に拡張するか、さらには過剰に作成することが、この状況を回避する唯一の方法です。
12.2(18) SXH では、リターン トラフィックをカプセル化する代わりに、オプションの 1 つを使用して、WCCP エンティティで L2 MAC アドレスを書き換えることができます。この L2 リターンの機能拡張(Cisco Bug ID CSCuk59825)により、マスク割り当てを使用する入力リダイレクションを使用するように WCCP が設定されている場合にリターン トラフィックのハードウェアの処理が可能になります。
Catalyst 6500 に実装した場合、WCCP は次の表に示すように多くの設定オプションを提供します。WCCP アプライアンスでは、これらのオプションをネゴシエートし、Catalyst 6500 で使用されるオプションを制御することに注意してください。設定は、WCCP 接続の WCCP アプライアンス側で行われます。
リダイレクト方式 | 割り当て メソッド |
入力/ 出力 |
スイッチングの結果 |
L2 | ハッシュ | 入力 | ソフトウェア処理 |
L2(推奨) | マスク | 入力 | ACL TCAM を使用した完全なハードウェア処理 |
L2 | ハッシュ | 出力 | ソフトウェア処理 |
L2 | マスク | 出力 | ソフトウェア処理 |
GRE | ハッシュ | 入力 | ソフトウェア処理 |
GRE(PFC3 以降) | マスク | 入力 | NetFlow full-flow を使用した完全なハードウェア処理 |
GRE | ハッシュ | 出力 | ソフトウェア処理 |
GRE | マスク | 出力 | ソフトウェア処理 |
ハードウェアの観点からすると、すべての出力 WCCP 設定でソフトウェア処理を必要とし、CPU 使用率に影響します。ハッシュ ベースの割り当て方式を使用する場合は、入力でもソフトウェア処理を必要とし、CPU 使用率に同じ潜在的な影響があります。
Catalyst 6500 での WCCP 導入に推奨される方式は、マスク割り当てを使用する L2 リダイレクションと、使用可能であれば、L2 リターンです。
これらの推奨設定を使用して、状況に応じた最適な WCCP 導入方式を決定します。
WCCP 入力をリダイレクション方式として使用できるようにネットワークを設計します。優れた設計方法は、L3 分散ネットワーク階層の一部としてキャッシュのスイッチブロックを使用することです。これにより、WCCP で処理されたトラフィックがいくつかの主要な入力ポートで識別できることが保証されます。
さらに、シスコ アドバンスド サービスでは、次の設計上の考慮事項を推奨します。
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)の設定は次のとおりです。
NetFlow の使用率を見直し、WCCP で NetFlow エントリを使用し尽くしているかどうかおよびソフトウェア処理を使用しているかどうかを判別するには、次のコマンドを使用します。
NetFlow リソースが消費されているために WCCP ソフトウェアに関する問題が発生している場合は、これらのコマンドによって既存のエントリが積極的に空にされ、新しいエントリ用の空きが作成されることがあります。(これは単に NetFlow 領域を上回るエントリがある場合は役に立ちません)。
パケットのドロップを避けるには、WCCP エンティティで、WCCP が設定されているインターフェイス以外のインターフェイスから送信されるトラフィックをリダイレクトする必要があります。この場合、Catalyst 6500 での WCCP では、すべての条件が満たされるとパケットをドロップします。
この状況は、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 は、このコマンドの必要性なしでこれをネゴシエートします。
標準トランスペアレント キャッシング リダイレクションでは、WCCP エンティティが、サポートされている方式を WCCP ルータに提示し、この処理を行うように設定する必要がある場合があることに注意してください。Cisco ACNS の場合、この設定例には、最適化された L2 リダイレクトおよびマスク ベースの割り当て方式が必要です。
ContentEngine(config)# wccp version 2
ContentEngine(config)# wccp router-list 1 172.16.16.1
ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign
ルータ側では、Catalyst 6500 の設計で、WCCP デバイスが現在のトラフィック パスにない専用 L3 インターフェイス上にあることを保証する必要があります(入力または出力)。 ハードウェアのパフォーマンスを確保するために、単一の出力インターフェイスを選択した場合よりも多くのインターフェイス設定が必要であっても、Catalyst 6500 に対する着信でトラフィック フローをキャプチャする必要があります。理想的な設計は、このデバイスに到達する前にすべてのトラフィックを集約し、少数のインターフェイスだけで WCCP の入力設定を必要とする設計です。
Catalyst 6500 での WCCP 設定は次のとおりです。
6500Switch# ip wccp version {1 | 2}
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 アプライアンス | wccp version 2 |
WCCP ルータ: グローバル |
ip wccp version 2 |
WCCP ルータ: 各入力インターフェイス |
ip wccp redirect service in |
この設定を確認するには、次のコマンドを入力します。
Show ip wccp service detail
マルチキャストを使用したグループ アドレスなど追加 WCCP 設定オプションや、追加の WCCP セキュリティについては、『WCCP を使用した Web キャッシュ サービスの設定』を参照してください。
WCCP およびハードウェア転送を使用する場合は、一部のカウンタが予想どおりに表示されない可能性があります。
NetFlow ハードウェア リソースの使用を必要とする WCCP の設定がある場合は、NetFlow リソースのステータスを確認するには、これらのマルチレイヤ スイッチング(MLS)コマンドと Fabric Manager(FM)コマンドを使用します。
次の Cisco Bug ID および解決策の表では、WCCP の最適なサポートのために、Cisco IOS ソフトウェア リリース 12.2(18) SXF7 以降を使用するための一般的な推奨事項に対応しています。
Cisco Bug ID | 解決された Cisco IOS ソフトウェア リリース | 詳細 |
CSCsd20327 | 12.2(18)SXF7 | サービス 90 の WCCP が起動後停止して、WCCP サービスが失われます。この問題は、サービス 81、82、および 90 が設定されていると発生します。パケット トレースは、キャッシュからの「Here_I_Am」のメッセージに、ルータが誤った宛先 IP アドレスを含む「I_See_You」メッセージで応答した可能性があることを示しています。 |
CSCsa77785 | 12.2(18)SXF6 | ホスト ベースの標準 ACL を WCCP リダイレクト ACL として、WCCP L2 リダイレクションとマスク割り当てのモードを使用すると、リロードが発生する可能性があります。 |
CSCse69713 | 12.2(18)SXF6 | 単一 WCCP サービス グループ内のすべてのキャッシュ エンジンが失われると、トラフィックはハードウェアでスイッチングされるのではなくソフトウェアで処理されます。 |
CSCsd28870 | 12.2(18)SXF5 | WCCP リダイレクト ACL リストで、log キーワードを指定して設定された ACE が TCAM テーブルにプログラムされません。 |
CSCsb61021 | 12.2(18)SXF5 | IP スプーフィング機能がキャッシュ エンジンで設定されており、WCCP リダイレクションが出方向で設定されている場合、スーパーバイザ エンジン 720 またはスーパーバイザ エンジン 32 で高 CPU 使用率が発生する可能性があります。クライアントまたはサーバを宛先とするキャッシュ エンジンからの IP スプーフィングされたパケットは、ハードウェアではなく、ソフトウェアでスイッチングされます。 回避策として、着信インターフェイスと発信インターフェイスの両方で ip wccp service redirect in コマンドを使用します。 |
CSCsb21972 | 12.2(18)SXF2 | WCCP と NDE の両方を設定すると、アラインメント エラーにより多数のトレースバックが発生し、CPU 使用率が許容できないほど高くなる場合があります。 |
CSCeh85087 | 12.2(18)SXF | WCCP リダイレクト ACL にユーザ設定の「deny ip any any」があり、多くの WCCP のサービス グループを処理していると、一部のサービス グループに関連付けられたトラフィックが CE のルータにリダイレクトされません。 |
CSCeh56916 | 12.2(18)SXF | WCCP サービスがイネーブルの場合、マスク割り当てが割り当て方式として設定されているときと、5 つ以上のキャッシュがサービス グループにあるときは、キャッシュに送信されるプロトコル メッセージがオーバーフローし、メモリ不良およびリロードを引き起こす可能性があります。 |
CSCsb18740 | 12.2(18) SXF および SXE6 | GRE ベースの転送モードの場合、WCCP では、MSFC の CPU 使用率を上げるソフトウェア キャッシュを不必要に使用します。 |
CSCsb26773 | 12.2(18)SXF | 着信 ACL が原因で、WCCP リダイレクションが失敗し、リダイレクトされたすべてのトラフィックが失われることがあります。 |
CSCsa90830 | 12.2(18)SXE2 | WCCP 入力リダイレクト トラフィックは、キャッシュ エンジンが、マスク割り当てのモードを使用する GRE 転送に設定されている場合、ハードウェア スイッチングに NetFlow テーブルを使用します。NetFlow テーブルが満杯の場合、WCCP 入力リダイレクションは失敗します。 |
CSCec55429 | 12.2(18)SXE | WCCP サービス グループ リストは、優先順位ではなくサービス グループの作成順序でスキャンされます。複数のダイナミック WCCP サービスが定義されている場合、複数のサービス グループの選択基準に一致するトラフィックは、優先順位が最高のサービス グループにリダイレクトされません。 |
CSCuk50878 | 12.2(18)SXE | Cisco Bug ID CSCec55429 解決されているリリースでは、単一サービス グループ内のすべてのキャッシュで多数の WCC 'cache lost' イベントおよび 'cache found' イベントが発生すると、次のイベントが発生する可能性があります。
|
CSCsa67611 | 12.2(18)SXE | 出力機能が設定されている非 MPLS インターフェイス(IP パスへのタグ)で終了する着信マルチプロトコル ラベル スイッチング(MPLS)パケット(出力 ACL、出力 WCCP など)に、出力機能が適用されないことがあります。この問題は、出力 ACL のルックアップがバイパスされるために発生します。 |
CSCeh13292 | 12.2(18)SXD4 | スーパーバイザ エンジン 720 での WCCPv2 の設定により CPU 使用率が高くなります。 |
CSCeb28941 | 12.2(18)SXD1 | WCCP が設定されている場合、ネットワーク アドレス変換(NAT)は機能しません。 |
CSCed92290 | 12.2(17d)SXB2 | ネクスト ホップのアドレス解決プロトコル(ARP)のキャッシュ エントリを持たない WCCP リダイレクト パケットは、プロセス スイッチングされて ARP 要求が生成されます。ただし、WCCP リダイレクションが原因で ARP 要求は送信されず、ARP キャッシュはネクスト ホップ用に入力されず、後続の WCCP リダイレクト パケットは引き続きプロセス スイッチングされます。 |
CSCuk59825 | 12.2(17d)SXF5 - Sup720 用の Sup2 Whitney1.0 | この Cisco IOS ソフトウェア リリースでは L2 リターン トラフィックのハードウェア サポートが追加されました。WCCP の Requests for Comments(RFC)では、ルータとキャッシュ間のネゴシエーションに対して L2 リターンが任意選択の機能として指定されています。これまで、Cisco IOS ソフトウェア上の WCCP では、必要なハードウェア サポートがないために、この機能のネゴシエーションを許可していませんでした。このサポートが提供されたため、ルータとキャッシュ間での WCCP のプロトコル交換において L2 リターンのネゴシエーションをイネーブルにできます。 |
改定 | 発行日 | コメント |
---|---|---|
1.0 |
16-Jul-2013 |
初版 |