Cisco ACNS キャッシング/ストリーミング コンフィギュレーション ガイド
透過キャッシング
透過キャッシング
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

透過キャッシング

透過キャッシング

CSS スイッチを経由した透過キャッシング

WCCP を経由した透過キャッシング

WCCP 対応ルータを経由した透過キャッシング

透過キャッシングおよび WCCP サービス グループ

WCCP サービス グループ

カプセル化方式と負荷分散方式

透過 HTTPS キャッシング

透過 HTTP キャッシングの設定例

拡張透過キャッシング機能

認証トラフィックのバイパス

ダイナミック トラフィック バイパス

過負荷バイパス

スタティック バイパス

マルチポート透過リダイレクション

WCCP フロー保護

拡張キャッシング サービスの設定例

ダイナミック バイパスの設定例

過負荷バイパスの設定例

スタティック バイパスの設定例

マルチポート透過リダイレクション

マルチポート透過リダイレクションの設定例

WCCP 対応ルータを経由した透過キャッシングの設定

前提条件

透過キャッシング用の ContentEngine の設定

ルータ上での WCCP のイネーブル化

透過キャッシング サービスの設定

クライアントと ContentEngine が同一サブネット上にある場合の Web キャッシュ サービス設定

クライアントと ContentEngine が異なるサブネット上にある場合の Web キャッシュ サービス設定

ContentEngine 上の透過キャッシング サービスのディセーブル化

ソフトウェア設定の確認

IP スプーフィングの設定

透過プロキシ スタイル要求の IP アドレス スプーフィング

IP スプーフィング用の ContentEngine および WCCP 対応ルータの設定

高速 WCCP レイヤ 2 のサポートの設定

ハッシュ負荷分散方式を使用する Layer 2 転送の設定

マスク負荷分散方式を使用する Layer 2 転送の設定

CSS スイッチを経由した透過キャッシングの設定

CSS スイッチを使用した透過キャッシングのイネーブル化

透過キャッシングの設定出力例

Content Engine 上での転送レイヤ 4 トラフィックの受信イネーブル化

透過キャッシング

この章では、Web Cache Communication Protocol(WCCP)対応のルータ、または Cisco Content Services Switches(CSS)11000 シリーズのようなレイヤ 4 スイッチ(以降は CSS スイッチと呼びます)を使用した透過キャッシングを説明します。

この章の構成は、次のとおりです。

「透過キャッシング」

「拡張透過キャッシング機能」

「WCCP 対応ルータを経由した透過キャッシングの設定」

「CSS スイッチを経由した透過キャッシングの設定」


) この章で使用される CLI コマンドの構文と使用法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


透過キャッシング

透過キャッシングでは、Content Engine の存在にユーザが気付きません。ユーザ(Web クライアント)は、ブラウザにオリジン サーバの URL を入力して、直接ソース(オリジン Web サーバ)にコンテンツ(Web オブジェクト)を要求します。この要求は、WCCP 対応ルータまたはレイヤ 4 CSS スイッチによって代行受信されます。

Content Engine は、WCCP Version 2 をサポートするか、Cisco CSS スイッチと相互動作して、透過キャッシングをサポートできます。透過キャッシングを使用する利点には、次のものがあります。

コンテンツ トラフィックの透過的受信

フォールト トレランス

スケーラブルなクラスタ作成


) この章では、CSS スイッチは Cisco CSS 11000 シリーズ スイッチを示します。


高度な透過キャッシング サービスに関連する情報は、「拡張透過キャッシング機能」を参照してください。

CSS スイッチを経由した透過キャッシング

CSS スイッチを経由した透過キャッシング(図 4-1)では、ユーザは、オリジン サーバに対する要求が、CSS スイッチにより Content Engine にリダイレクトされることに気付きません。CSS スイッチを設定して、動的に要求を分析して、要求されたコンテンツがキャッシングできるかどうかの判断ができるようにします。

要求されたコンテンツのキャッシングができない場合、CSS スイッチは直接、オリジン Web サーバにその要求を送信します。

要求されたコンテンツがキャッシングできる場合、CSS スイッチはその要求を Content Engine に送信します。

Content Engine は、次のいずれかの方法で要求されたコンテンツをクライアントに送ります。ローカル コピーがある場合は、そのコピーを送り、新しいコンテンツに対する要求である場合は、その要求をオリジン Web サーバに送信します。すべての Content Engine で透過キャッシングが設定できない場合、CSS スイッチは、すべてのクライアント要求をオリジン Web サーバに送信します。

図 4-1 CSS スイッチを経由した透過キャッシング ネットワーク

 

Content Engine には、スタティック データ(つまり、HTML、AVI、JPEG、または GIF の各ファイル)が保存されます。キャッシングできないファイルに対する要求がある場合、その要求はオリジン Web サーバに直接渡されます。

キャッシング対象となっているコンテンツに対する各要求は、URL に基づいて複数の Content Engine に負荷分散されます。実際の環境では、これらの要求はドメイン名に基づいて負荷分散される場合もあります。


) CSS スイッチを経由して透過キャッシングを設定する方法については、「CSS スイッチを経由した透過キャッシングの設定」を参照してください。


WCCP を経由した透過キャッシング

WCCP は、サービス グループの概念を取り入れ、WCCP 対応のルータおよび Content Engine に対するキャッシング関連サービスを 1 つのクラスタ内に定義します。また、それらのキャッシング関連サービスを要求するクライアントからのユーザ要求を、キャッシング クラスタにリアルタイムでリダイレクトします。WCCP を経由した透過キャッシングでは、WCCP 対応ルータを設定して、透過キャッシング エンジンとして機能している Content Engine に要求をリダイレクトできます。

ここでは、WCCP 環境でのキャッシングに関連する次の項目についての概要を説明します。

WCCP 対応ルータを経由した透過キャッシングを設定する方法

透過キャッシングおよび WCCP サービス グループ

カプセル化方式および負荷分散方式

IP スプーフィング


) WCCP Version 1 および Version 2 の詳細は、付録 B「Web Cache Communication Protocol Version 1」および付録 C「Web Cache Communication Protocol Version 2」 を参照してください。サービス グループの詳細は、「WCCP サービス グループ」を参照してください。


WCCP 対応ルータを経由した透過キャッシング

WCCP を経由した透過キャッシングでは、ユーザは、オリジン Web サーバに対する要求が WCCP 対応ルータによって Content Engine に宛先変更されたことに気付きません。WCCP 対応ルータへの要求では、WCCP 対応ルータ、またはスイッチを通過するトラフィック用の任意番号のポート上で、要求のトラフィックが代行受信されます。

図 4-2 で示すように、Content Engine は、次のように WCCP を経由してコンテンツを透過的にキャッシングします。

1. ユーザがブラウザから Web ページを要求する。

2. WCCP 対応ルータがユーザの要求を分析する。ルータは、TCP 宛先ポート番号に基づいて、ユーザの要求を Content Engine に透過的にリダイレクトするかどうかを判断します。どの要求を転送するかを管理するために、アクセス リストが使用されます。

3. Content Engine に要求されたコンテンツがない場合、次の処理が実行されます。

目的のコンテンツを取得するために、オリジン Web サーバとの TCP 接続を別途セットアップします(3a)。

目的のコンテンツが、Content Engine に送られて保存されます(3b)。

4. Content Engine が、要求されたコンテンツを Web クライアントに送信します。これ以降に同じコンテンツに対する要求があった場合、Content Engine はローカル ストレージ(キャッシュ)から透過的にその要求を処理します。

図 4-2 WCCP を経由した透過キャッシング

 

キャッシング ソリューションが、エンド ユーザに完全に透過的に行われるために、WCCP には、多くのフェールセーフ メカニズムが備えられています。この機能の詳細は、「拡張透過キャッシング機能」を参照してください。

透過キャッシングおよび WCCP サービス グループ

透過要求とは、ルータから Content Engine に宛先変更された要求です。透過要求内の URL のスタイルは、通常、サーバ スタイルです。ただし、別のプロキシ サーバ宛ての要求を Content Engine が代行受信するときは、プロキシ スタイルの場合があります。サーバスタイルの要求には、プロトコルとホスト名が含まれません。ただし RTSP 要求では、サーバスタイルの URL とプロキシスタイルの URL との相異はありません。サーバ スタイルの URL が受信される場合、サポートされるのは HTTP と RTSP だけです(RTSP ユーザ エージェント基準に適合する場合)。プロキシ スタイルの URL が受信された場合、HTTP、HTTPS (HTTP over Secure Socket Layer)、FTP、および RTSP がサポートされます(それぞれのプロキシ サービスが設定されている場合)。

wccp service-number グローバル設定コマンドは、Content Engine 上で最高 8 つの動的 WCCP リダイレクション サービス(90 ~ 97)を使用可能にできます。ただし、これらのサービスがルータ上でも設定されている場合です。各 wccp service-number コマンドでは、ルータ リスト、シングル ポート リスト(最高 8 つのポートを含む)、アプリケーション タイプ、ハッシュ パラメータ、パスワード、および重みを指定します。

WCCP サービス グループ

表 4-1 には、WCCP 対応ルータがサポートするサービス グループがリストされています。

 

表 4-1 WCCP サービス グループ

サービス
グループ番号
サービスの説明

0

Web キャッシュ

50

ブーメラン

80

HTTP、RTSP

81

MMST

82

MMSU

90 ~ 97

ユーザが設定可能

98

カスタム Web キャッシュ

99

リバース プロキシ


) Web キャッシュ サービス (サービス グループ 0)を除き、表 4-1 にリストされているすべてのサービス グループ番号は、WCCP Version 2 でサポートされます。


従来のカスタム Web キャッシュ サービス、およびリバース プロキシ サービス(サービス番号 98 と 99)は、それぞれ 1 ポートだけを使用して設定できます。したがって、従来のサービスを 1 つだけ設定している場合、透過リダイレクション ポートの最大合計数は 57 になります。これらの両方の従来型サービスが設定される場合、最大合計ポート数は 50 になります。

最大 8 個ずつのポートを使用する 8 つの動的サービスを実行する場合、透過リダイレクション用に指定できる最大ポート数は 64 です。図 4-3 では、左側の 2 台の Content Engine は、ポート 80 を介した HTTP トラフィックだけを処理し、Service Group 90 のメンバーとして指定されています。右側の 2 台の Content Engine は、MMS(Microsoft Media Server)要求だけを処理し、Service Group 91 のメンバーとして指定されています。

図 4-3 WCCP サービス グループ

 

同じ WCCP サービスのメンバーとして設定され、HTTP を受信するすべてのポートは、次の特性を共有します。

wccp service-number コマンドを使用して設定された同じハッシュ パラメータまたはマスク パラメータをもつ。それらのパラメータの説明については、「カプセル化方式と負荷分散方式」を参照してください。

個々のポート上のサービスは、個別に停止または開始できない(WCCP Version 2 の制約事項)。

Content Engine ファームの制約事項

ファーム内の Content Engine には、次の制約事項が適用されます。

同じ WCCP サービスを使用するすべての Content Engine には、同じポート リストおよび同じハッシュ パラメータまたはマスク パラメータを使用する必要がある。

同じ WCCP サービスのファームに参加しようとする Content Engine が、異なったポート リストまたは異なったハッシュ パラメータまたはマスク パラメータを使用する場合、ルータによって拒否される。

特定の WCCP サービス用のポート リストを変更するには、関係しているすべての Content Engine 上で WCCP サービスを停止して、新しいパラメータを指定した後、すべての Content Engine 上で再開する必要がある。

Content Engine WCCP の実装では、現在、すべての WCCP サービスに適用されるグローバル設定(たとえば、ヒーリング パラメータ、スロースタート)が可能です。マルチ サービス モデルでもその仕様は変更されず、該当する設定値は WCCP システム全体に対して、グローバルなまま維持されます。

カプセル化方式と負荷分散方式

WCCP 対応ルータでは、代行受信した要求を Content Engines へリダイレクトする場合は、次の 2 つのパケットカプセル化方式を使用します。

GRE (Generic routing encapsulation)

レイヤ 2 リダイレクション

これら 2 つのカプセル化方式では、ハッシュ アサイメント方式とマスク アサイメント方式の 2 つの負荷分散方式をサポートしています。両方のカプセル化技法はハッシュ アサイメント方式を備えていて、ハッシュ パラメータは異なるサービス グループ間で負荷分散方法を指定します。具体的には、ハッシュは、それぞれの複数項目をある項目セットから別の項目セットにマップします。たとえば、負荷分散の目的で、複数の宛先 IP アドレスを、WCCP 対応ルータからサービス グループ内の個別の Content Engine にマップします。

GRE カプセル化

GRE カプセル化は、レイヤ 3 の記述であり、データグラムを WCCP 対応ルータで IP パケットにカプセル化した後、Content Engine へリダイレクトします。この中間点宛先では、データグラムはカプセル化が解除され、次に、キャッシュミスの場合に要求が満たされるように、オリジンサーバへルーティングされます。この過程で、サーバへのトリップは 1 ホップの内部データグラムとして扱われます。通常、GRE カプセル化を使用して行われるリダイレクト トラフィックは、GRE トンネル トラフィックと呼ばれています。

リダイレクションはすべてルータ ソフトウェアによって処理されます。マスク アサイメント方式は推奨されません。

レイヤ 2 リダイレクション

レイヤ 2 リダイレクションとは、ルータまたはスイッチ上の WCCP が、レイヤ 2 のハードウェアに WCCP のトラフィック代行受信機能、およびリダイレクション機能を部分的または完全に実装する、スイッチング ハードウェアを利用できる配置のことを言います。このリダクション タイプは、「高速 WCCP」とも呼ばれ、現在のところ、Cisco Catalyst 6000 ファミリー、および 6500 ファミリーのスイッチ製品だけがサポートしています。

初めにリダイレクトされたトラフィック パケットはソフトウェアで処理されます。それ以降のトラフィックはハードウェアで処理されます。

レイヤ 2 インまたはアウト リダイレクションは、完全にルータ ハードウェアまたはスイッチ ハードウェアで処理されます。レイヤ 2 リダイレクションのカプセル化では、Content Engine がルータまたはスイッチに特定パケット フィールドにビットマスクを適用するように指示します。このビットマスクが順にクラスタ内の Content Engines にマスクの結果、つまりマスク インデックス アドレス テーブルの形にマップされたインデックスを渡します。リダイレクション プロセスはスイッチング ハードウェアで加速されるので、この方式はレイヤ 3 GRE カプセル化よりも効率的です。レイヤ 2 リダイレクション カプセル化方式に関する設定情報は、「高速 WCCP レイヤ 2 のサポートの設定」を参照してください。

透過 HTTPS キャッシング

SSL を使用した透過 HTTPSキャッシングは、次のように機能します。

1. Content Engine は、HTTPS サーバとして設定され、WCCP 対応ルータ経由で転送された HTTPS 要求を受信します。

2. Content Engine は、SSL 証明(オリジン サーバから取得した)を要求 Web クライアントに戻して、SSL 接続をネゴシエートします。

3. Web クライアントは、ネゴシエートされた SSL 接続内部に HTTPS 要求を送信します。

4. Content Engine は、その要求をチェックし、キャッシュを調べ、通常の HTTP 要求処理をします。

5. Content Engine は、ローカル ストレージから要求に応えられる場合(キャッシュ ヒット)、SSL 接続を使用して、要求されたコンテンツを戻します。

6. Content Engine が、ローカル ストレージを使用して要求に応えられない場合(キャッシュ ミス)、オリジン サーバへの接続を開始し、SSL 接続を使って、要求されたコンテンツを取得します。

7. Content Engine は、要求されたコンテンツをキャッシュし(可能な場合)、さらに、ネゴシエートされた SSL 接続を使用して、コピーを要求クライアントに送信します。


ヒント 要求された特定のコンテンツをキャッシュする場合、ACNS システム管理者は、それらのサイトの適切な証明書およびキーを Content Engine にインポートし、それらのサイトをキャッシングするように Content Engine に指示する必要があります。


表 4-2 では、透過 HTTPS キャッシングに関連する CLI コマンドを説明します。

表 4-2 透過 HTTPS キャッシングおよび関連する CLI コマンド

コマンド
目的

https server name

HTTPS サーバおよびキャッシング ソリューションを設定して、Content Engine がオリジン HTTPS サーバとして機能できるようにします。これにより、許可されたクライアントが遠隔地の営業所から HTTPS を使用して、中央サイトに常駐する HTTPS サーバであるかのように設定された、独自の Content Engine にアクセスできるので、WAN トラフィックが減少し、データのセキュリティが向上します。

https server name cert

https server name key

Content Engine を設定して、1 組の SSL 証明書およびキーを使用し、Content Engine を オリジン HTTPS サーバとして機能するようにします。Content Engine は、クライアントからの HTTPS トラフィックをデコードして、キャッシング、要求処理などの通常の HTTPS 操作を実行できるようになります。キャッシュ ミス(またはキャッシュ検証)の際には、Content Engine は、オリジン サーバへの HTTPS 接続を開始し、オリジン サーバからコンテンツを取り出せます。

https server name host

オリジン HTTPS サーバの IP アドレスを指定します。このコマンドでは、HTTPS サーバとして機能するセントラル オフィスの Content Engine の IP アドレスを使用します。 https server name enable コマンドを使用すると、この HTTPS サーバを使用できます。

https server name protocol-version

クライアントと HTTPS サーバ間の通信を制御するために使用する SSL プロトコル バージョンを設定します。

https server name serverauth

HTTPS へのアクセスに、認証が使用できます。また、ACNS システム管理者は、無効な認証、ドメイン名の不一致、証明書の有効期限エラー、未承認の CA(認証局)などの認証エラーを無視する認証も認定できます。

透過 HTTP キャッシングの設定例

表 4-3 では、ローカル側に配置する Content Engine 上に透過 HTTPS キャッシングを設定する方法の例を示します。

表 4-3 CLI を使用した HTTPS キャッシングの設定例

目的
コマンド

Content Engine をポート 8081 上で HTTPS 要求を受け入れる HTTPS プロキシ サーバとして設定します。HTTPS プロトコルでは 1 つのポートだけがサポートされます。

ContentEngine(config)# https proxy incoming 8081

Content Engine を設定して、ポート 8880 で HTTPS 要求を発信プロキシ サーバ(10.1.1.1)に転送するようにします。

ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880

ドメイン名を発信プロキシ サーバへの転送対象から除外します。

ContentEngine(config)# proxy-protocols outgoing-proxy exclude cruzio.com

ContentEngine(config)# proxy-protocols transparent default-server

ローカル Content Engine に常駐しているすべての HTTPS 関連情報を表示します。

ContentEngine# show https all
Incoming HTTPS proxy:
Incoming Proxy-Mode:
Not servicing incoming proxy mode connections.
Outgoing HTTPS proxy:
Not using outgoing proxy mode.
Destination port restrictions:
Allow 443 563
HTTPS caching certificate information:
HTTPS caching certificate group information:
HTTPS caching private key information:
Display all https server caching information:
ContentEngine#

拡張透過キャッシング機能

透過ネットワーク キャッシングの基本原則の 1 つは、Content Engine がエンド ユーザに対して常に透過的でなければならないということです。また、透過キャッシング ソリューションが原因でネットワークに何らかの障害が発生したり、副次的に障害を引き起こしたりしないようにする必要があります。

ACNS ソフトウェアでは、Web ブラウザが動作しない場合や、Web サーバが HTTP に準拠していない場合でも、WCCP 対応ルータと各種の先進技術を使用して Content Engine の透過性を確保します。

次の機能は、「拡張透過キャッシング機能」と呼ばれ、ユーザが Cisco キャッシング ソリューションを配置する際、予期しない問題が発生しないようにします。

認証トラフィックのバイパス

ダイナミック トラフィック バイパス

過負荷バイパス

スタティック バイパス

マルチポート透過リダイレクション

WCCP 保護フロー

認証トラフィックのバイパス

IP 認証上の理由から、一部の Web サイトでは、Content Engine がクライアントの代理として直接接続することを許可していません。キャッシュの透過性を保ち、サービスの中断を防ぐために、Content Engine は認証トラフィックのバイパスを使用して、選択されたクライアント/サーバのペアのために、ダイナミック アクセス リストを自動的に生成できます。階層キャッシングを行っている場合は、認証バイパス トリガーは、アップストリームとダウンストリームにも伝搬されます。

bypass auth-traffic グローバル設定コマンドを使用して、次の処理を実行します。

透過エラー処理のイネーブル化

ダイナミック認証バイパスのイネーブル化

スタティック バイパス リストの設定

クライアント/サーバ ペアが認証バイパスを使用していると、そのペアは bypass timer コマンドで指定した時間内はバイパスされます(デフォルトでは 20 分)。たとえば、クライアント/サーバ ペアが認証バイパスを実行すると、設定されている時間の間、バイパスされます。この時間は、 bypass timer グローバル設定コマンドによって設定されます。

次の例では、すべての認証済み HTTP トラフィックに 24 時間の間、強制的に Content Engine をバイパスさせます。

ContentEngine(config)# bypass auth-traffic enable
ContentEngine(config)# bypass timer 1440
 

バイパス機能を使用禁止にする場合は、 no form of the bypass auth-traffic コマンドを使用します。デフォルトでは、認証トラフィック バイパス機能は使用不可です。

ダイナミック トラフィック バイパス

オリジン Web サーバに直接接続できるクライアントを選別することにより、ソース IP の認証問題を防止します。ダイナミック トラフィック バイパスの詳細は、「ダイナミック バイパスの設定例」を参照してください。

過負荷バイパス

Content Engine に過大なトラフィックが生じた場合、Content Engine は、過負荷バイパス機能を使用して、過負荷のトラフィックを転送できます。ダイナミック トラフィック バイパスの設定の詳細は、「過負荷バイパスの設定例」を参照してください。

スタティック バイパス

指定したソースからのトラフィックを許可し、Content Engine をバイパスします。 bypass static グローバル設定コマンドを使用して、スタティック バイパスを設定します。スタティック バイパスの設定の詳細は、「スタティック バイパスの設定例」を参照してください。

マルチポート透過リダイレクション

マルチポート透過リダイレクションの概要は、次のとおりです。

プロキシ プロトコル(FTP、HTTP、HTTPS、MMS、および RTSP)ごとに、最高 8 つの着信プロキシ ポートがサポートされる。

HTTP、FTP、HTTPS、MMS、および RTSP 内のプロキシ スタイル要求は、同じ着信プロキシ ポートで受信できる。

透過要求とプロキシ スタイル要求の両方が、同一ポートで処理できる。

無効なポート上では、透過トラフィックが許可されない。

サポートされないプロトコルは、着信ポート上で許可されない。

http https ftp 、および rtsp のグローバル設定コマンドの proxy incoming オプションは、プロトコルごとに最高 8 つのポートをサポートするようになりました。

WCCP フロー保護

WCCP フロー保護とは、新しい Content Engine をオンラインにする際、既存のフローがとぎれないようにするメカニズムです。

透過トラフィックの代行受信またはリダイレクションが最初に始まる際に、WCCP フロー保護は、既存の接続済みの HTTP フローを継続させることによって、これらの HTTP フローがとぎれないようにします。

また WCCP フロー保護は、新しい Content Engine が既存の Content Engine クラスタに加わる際、クラスタ内の既存の Content Engine により提供されているフローが確実に継続するようにします。

WCCP フロー保護が使用するメカニズムは、フローごとのステータス情報を中央で保持することにより、多くの利点をもたらします。オーバーヘッド、スケーリングの問題、スイッチング レイヤにおいてフローごとにステータス情報を保持することによる冗長性や復元力などの問題(たとえば、非対称トラフィック フロー)もありません。

WCCP フロー保護を設定するには、 wccp flow-redirect グローバル設定コマンドを使用します。このコマンドは、WCCP Version 2 でのみ作動します。フロー保護は、TCP フローに影響を与えず、Content Engine の導入時や新規トラフィックの再割り当て時に、Content Engine が過負荷にならないように設計されています。また、この機能は、スロー スタート メカニズムも備えています。このメカニズムにより、Content Engine は自身の容量に適した負荷を引き受けようとします。

次の例は、Content Engine で WCCP フロー保護をイネーブルにする方法を示しています。

ContentEngine(config)# wccp flow-redirect enable

) バイパスがイネーブルである場合、クライアント自体から、オリジン Web サーバに到達しようとします。すべてのバイパス オプションを無効にして、ネットワークに不要な負荷をかけないようにしてください。


拡張キャッシング サービスの設定例

この項では、ダイナミック バイパス、過負荷バイパスなどの拡張キャッシング サービスの実装方法について、簡単なシナリオをいくつか説明します。


) ローカル側に配置する Content Engine 上でバイパス機能を設定する方法については、「WCCP バイパスのパラメータ設定」を参照してください。


ダイナミック バイパスの設定例

次の 2 つのシナリオでは、一般的なダイナミック トラフィック バイパスの状況を説明します。

このシナリオでは、WCCP リターン パス機能が実装されます。この機能は、Content Engine が WCCP 対応ルータまたはスイッチにトラフィックを戻し、このルータまたはスイッチに指示して、Content Engine が存在しないかのようにパケットを転送させるメカニズムです。

一般に、HTTP トラフィック フローの内、全体の約 3 パーセントが損失します。こうした損失したフローは、認証バイパスまたはダイナミック クライアント バイパスを使用して自動的に再試行されます。これにより、障害条件が以前から存在しており、透過キャッシングの配置が原因で発生したのではないことが証明されます。

シナリオ 1 ― Web サーバ エラー受信時のダイナミック バイパス

ユーザは、Web ブラウザに HTTP 要求を出します。この要求は透過的に代行受信され、Content Engine にリダイレクトされます。Content Engine は、Web ブラウザから着信 TCP 接続を受け入れ、この要求がストレージ内に存在しないオブジェクトに対する要求である(キャッシュ ミスである)ことを判別し、オブジェクト要求をオリジン Web サーバに送信します。しかし、Web サーバから何らかのエラー メッセージ(たとえば、プロトコル エラーや認証エラー)を受け取ります。

Content Engine は、Web ブラウザからの TCP 接続をすでに受け入れているので、3 方向の TCP ハンドシェイクが行われています。Content Engine は、Web サーバとのトランザクションが失敗したことは認知できますが、その原因までを特定することはできません。原因には、オリジン Web サーバがユーザの送信元 IP アドレスに基づく認証を実行している場合や、TCP スタック間で互換性がない場合などがあります。

この場合のダイナミック クライアント バイパスは、Content Engine が、正確に同じ URL をもつブラウザに、もう一度 HTTP 応答コード 200 (200 Temporarily Moved) を戻すことを意味しています。Content Engine は、「Connection: close」 HTTP 応答ヘッダーを Web ブラウザに送ることによって、Web ブラウザと Content Engine 間の TCP 接続を終了します。ここでブラウザは、自動的に接続を再試行します。

接続の再試行時には、Content Engine は接続を受け入れません。Content Engine は、要求を代行受信しないまま WCCP 対応ルータ、またはスイッチに戻します。ルータは、次に Web ブラウザから直接、オリジン Web サーバにフローを送信し、Content Engine をバイパスします(図 4-4 を参照)。

図 4-4 ダイナミック トラフィック バイパス

 

シナリオ 2:サポートされないプロトコル受信時のダイナミック バイパス

Content Engine が TCP ポート 80 を介して非 HTTP 要求を受信したとき、Content Engine は、「retry」応答を出し、接続を解除し、以後の接続は、シナリオ 1 と同じように受け入れません。「retry」応答は、リフレッシュまたは再試行を要求していることを伝える通常の HTTP 応答です。


) 非 HTTP には、非準拠 HTTP や、Secure Shell(SSH)、シンプル メール転送プロトコル(SMTP)、または Network News Transport Protocol(NNTP)などのさまざまなプロトコルがあります。非準拠 HTTP とは、たとえば Web サーバが、HTTP ヘッダー セクションの末尾でキャリッジ リターンと改行を 2 回送信できない場合などです。


過負荷バイパスの設定例

Content Engine が過負荷状態になったときに bypass load コマンドが使用可能になっていると、Content Engine は以後の要求を拒否し、オリジン サーバに要求を転送します。それでも負荷が大きすぎる場合は、サーバにバイパスされるトラフィックの量が増え、Content Engine が負荷を処理できるようになるまで増え続けます。あるバケットがバイパスされてから次のバケットがバイパスされるまでの時間間隔は、 out-interval オプションで設定します。デフォルト値は 4 秒です(図 4-5 を参照)。

図 4-5 過負荷バイパス

 

最初のバケットがバイパスされてから、設定された時間が経過した後、Content Engine がバイパスされるバケットを再度処理し始めます。この間隔の期間は、 time-interval オプションによって設定します。デフォルトは 10 分です。

バイパスされるトラフィックのサービスを Content Engine が再度開始する際に、最初は 1 つのバイパス バケットからサービスを開始します。それ以上の負荷がサービス可能ならば、Content Engine はバイパス バケットをもう 1 つ引き取り、以後も同様に行います。あるバケットを引き取ってから次のバケットを引き取るまでの時間間隔は、 in-interval オプションによって設定します。デフォルト値は 60 秒です。

スタティック バイパスの設定例

bypass static コマンドは、指定された送信元からのトラフィックが Content Engine をバイパスできるようにします。トラフィック ソースのタイプは、次のとおりです。

特定の Web クライアントから特定の Web サーバへのトラフィック ソース

特定の Web クライアントから任意の Web サーバへのトラフィック ソース

任意の Web クライアントから特定の Web サーバへのトラフィック ソース

送信元フィールドまたは宛先フィールドには、ワイルドカードを使用できません。

すべてのスタティック設定リストをクリアするには、このコマンドの no 形式を使用します。


ヒント また、スタティック バイパスのパフォーマンスを上げるために、アクセス コントロール リスト(ACL)をもつルータを設定することもできます。


表 4-4 では、いくつかのスタティック バイパスの設定例を示しています。

表 4-4 スタティック バイパスの設定例

目的
コマンド

指定したクライアントから指定したサーバに HTTP トラフィックを転送して、Content Engine をバイパスします。

ContentEngine (config)# bypass static 10.1.17.1 172.16.7.52

指定したサーバ宛てのすべての HTTP トラフィックが、Content Engine をバイパスするように強制します。

ContentEngine (config)# bypass static any-client 172.16.7.52

指定したクライアントから任意の Web サーバへのすべての HTTP トラフィックが、Content Engine をバイパスするように強制します。

ContentEngine (config)# bypass static 10.1.17.1 any-server

すべての認証済み HTTP トラフィックが 24 時間、Content Engine をバイパスするように強制します。

ContentEngine(config)# bypass auth-traffic enable
ContentEngine(config)# bypass timer 1440

スタティック設定リストの項目を表示します。送信元アドレスと宛先アドレスのスタティック リストは、問題を起こしているクライアントとサーバのインスタンスを特定するのに役立ちます。

ContentEngine# show bypass list

バイパス リストのエントリの合計数を表示します。

ContentEngine# show bypass summary

マルチポート透過リダイレクション

マルチポート透過リダイレクションの要約は、次のとおりです。

プロキシ プロトコル(FTP、HTTP、HTTPS、MMS、および RTSP)ごとに、最高 8 つの着信プロキシ ポートがサポートされる。

HTTP、FTP、HTTPS、MMS、および RTSP のプロトコルを使用するプロキシ スタイル要求は、同じ着信プロキシ ポートで受信できる。

透過要求とプロキシ スタイル要求の両方が、同一ポートで処理できる。

無効なポート上では、透過トラフィックが許可されない。

サポートされないプロトコルは、着信ポート上で許可されない。

http https ftp 、および rtsp のグローバル設定コマンドの proxy incoming オプションは、プロトコルごとに最高 8 つのポートをサポートするようになりました。

マルチポート透過リダイレクションの設定例

マルチポート機能には、WCCP Version 2 が必要であり、 wccp port-list 、および wccp service-number のグローバル設定コマンドの設定も必要です。 wccp service-number グローバル設定コマンドの application cache オプションは、ACNS ソフトウェアの従来のキャッシング プロセスにトラフィックをリダイレクトします。一方、 application streaming オプションは、Content Engine のメディア キャッシング プロセスにトラフィックをリダイレクトします。

HTTP、HTTPS、FTP、RTSP、および MMS の着信プロキシ サービスを使用不可にするには、
no protocol proxy incoming コマンド(たとえば、 no wmt proxy incoming コマンド)を使用します。プロキシ モードでポートを追加または除去するには、新しいコマンドを実行して、すべてのポートの使用を指定してください。

透過モードで WCCP サービス用のポートを追加または除去するには、ポート リストを変更するか、WCCP サービス用の新しいポート リストを作成します。 no wccp service-number コマンドは、指定されたサービスを使用不可にします。


) すべての着信プロキシ要求をサポートするには、ドメイン ネーム システム(DNS)の設定が必要です。


マルチポート透過リダイレクションの例

次の例では、ポート 200、3000、110、220、330、440、および 40000 をポート リスト 3、ポート番号 10 に追加しています。

ContentEngine(config)# wccp port-list 3 10 200 3000 110 220 330 440 40000
 

次の例では、FTP、HTTP、および HTTPS のプロキシ要求をポート 81、8080、および 8081 上で受け入れるように、Content Engine を設定します。

ContentEngine(config)# http proxy incoming 81 8080 8081
ContentEngine(config)# https proxy incoming 81 8080 8081
ContentEngine(config)# ftp proxy incoming 8080 8081 9090
 

WCCP 対応ルータを経由した透過キャッシングの設定

この項は、WCCP 対応ルータを使用して透過モードで Content Engine を設定する方法を説明します。


) レイヤ 4 スイッチを使用した透過キャッシングの設定については、「CSS スイッチを経由した透過キャッシングの設定」を参照してください。


前提条件

WCCP 対応ルータを使用するには、インターネットに接続されているインターフェイス上で IP アドレスが設定されている必要があります。またインターフェイスが、ネットワーク上の Content Engine から見えなければなりません。

透過キャッシング用の Content Engine の設定

透過キャッシング用に WCCP を使用するには、Content Engine を適切に設定する必要があります。次の重要事項に注意してください。

WCCP 対応ルータは、Content Engine のホーム ルータとして設定する必要があります。このシナリオでは、このルータが、Content Engine に対してすべての IP パケットのリダイレクションを実行する装置になります。

Content Engine 上のソフトウェアのバージョンは、WCCP 対応ルータ上にインストールされているバージョンとの両立性が必要です。

Content Engine 上のパケットは、暗号化も圧縮もされていないことが必要です。また、ネットワーク アドレス変換(NAT)ファイアーウォールがある場合は、Content Engine はその「内部」にあることが必要です。

Web キャッシュ リダイレクト対応インターフェイスを超えて、サーバへのルート上に Content Engine を配置すると、IP ルート キャッシュにエントリが読み込まれません。

ルータ上での WCCP のイネーブル化

インターフェイスが WCCP Version 2 を使用して Web トラフィックを Content Engine に転送できるようにするには、ルータ上で、グローバル設定モードから次のタスクを実行してください。

 

 
目的
コマンド

ステップ 1

ルータが WCCP を使用できるようにします。

Router(config)# ip wccp enable

ステップ 2

(オプション)。リダイレクト アクセス リストを指定します。このアクセス リストと一致するパケットだけが、転送されます。このコマンドを設定しない場合、すべてのパケットが転送されます。

Router(config)# ip wccp redirect-list [ number | name ]

 

ステップ 3

インターフェイス設定モードに入ります。

Router(config)# interface type number

ステップ 4

Web トラフィックを Content Engine に転送するように、インターネットに接続されているインターフェイスを設定します。

Router(config-if)# ip web-cache redirect

ステップ 5

(オプション) クライアントと Content Engine が同じネットワーク上にある場合、インターフェイス上でファースト スイッチング パスを使用するように、ルータを設定します。

Router(config-if)# ip route-cache same-interface

ステップ 6

設定モードを終了します。

Router(config-if)# end

ステップ 7

実行設定を始動設定に保存します。始動設定は、不揮発性メモリに格納されます。

Router # copy running-config startup-config

) WCCP 対応ルータを透過キャッシング用に設定する方法の詳細は、付録 B 「Web Cache Communication Protocol Version 1」 および付録 C「Web Cache Communication Protocol Version 2」 を参照してください。


透過キャッシング サービスの設定

ルータ上で WCCP を使用可能にした後、そのルータおよび Content Engine を透過キャッシング サービス用に設定する必要があります。

透過キャッシング サービス用の WCCP ルータの設定

透過キャッシング サービスには、適正に設定されているルータが必要です。ルータ は、WCCP Version 1 または Version 2 をサポートする Cisco IOS ソフトウェアのバージョンを実行している必要があります。この項の設定例では、WCCP Version 2 を使用した Web キャッシュ サービス、透過キャッシング サービスを設定する方法を説明します。

ルータ上でキャッシング サポートが使用可能になり、Content Engine 上で WCCP サポートが使用可能になっているときに、各装置は、設定済みのサービスを使用して通信し、サービスを配信します。


ヒント キャッシング サービスを中断するには、個々の Content Engine の電源を切断したり、その他の方法で使用禁止にするのではなく、ルータ上でキャッシング サポートを使用禁止にできます(たとえば、キャッシングを使用禁止にするには、no ip wccp ルータ コマンドを使用します)。


また、多くの WCCP Version 2 サービスには、 wccp グローバル設定コマンドの設定も必要です。 wccp グローバル設定コマンドの詳細は、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。

ルータまたはスイッチの設定方法が不明な場合は、それらの装置に付属のソフトウェア資料を参照してください。WCCP Version 2 コマンドおよびルータ設定例の詳細は、Cisco IOS ソフトウェアのオンライン資料、および 付録 C「Web Cache Communication Protocol Version 2」 を参照してください。

クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

このシナリオでは、Content Engine と要求側クライアントは同一サブネット上にあります(図 4-6 を参照)。

WCCP Version 2 を実行するルータは、ルータ インターフェイス s0/0 宛てのクライアント HTTP トラフィックを Content Engine に透過的に転送します。Web キャッシュ サービスは、ポート 80 上だけで HTTP トラフィックを転送します。

図 4-6 クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス

 

クライアントと Content Engine が同一サブネット上にある場合、Web キャッシュ サービス用に ルータおよび Content Engine をローカル側に設定する手順は、次のとおりです。

 

 
目的
コマンド

ステップ 1

WCCP がルータ上で使用可能になっていることを確認します。

ルータ上で WCCP を使用可能にする詳細は、「ルータ上での WCCP のイネーブル化」を参照してください。

ステップ 2

ルータ上で Web キャッシュ サービスを設定します。

Router(config)# ip wccp web-cache

ステップ 3

設定するルータ インターフェイスを指定します。このシナリオでは、Ethernet0 が、Content Engine とクライアントが接続されるルータインターフェイスです。

Router(config)# interface Ethernet0

ステップ 4

パケットを受信した同じインターフェイスを通じてパケットをリダイレクトするファースト スイッチングをイネーブルにします。このコマンドを使用しない場合、ルータは、高速スイッチング キャッシュを使用しません。パケットはプロセス交換され、速度はかなり遅くなります。

Router(config-if)# ip route-cache same-interface

ステップ 5

設定するルータ インターフェイスを指定します。このシナリオでは、Serial0 が、インターネットとのルータ インターフェイスです。

Router(config)# interface Serial0

ステップ 6

指定されたインターフェイス宛ての Web キャッシュ トラフィックを、Web キャッシュ サービスを受け入れる Content Engine に転送するように、ルータに指示します。このシナリオの場合、ルータは 1 つです。Web キャッシュ トラフィックは、TCP ポート 80 トラフィックとして定義されます。

Router(config-if)# ip wccp web-cache redirect out

ステップ 7

ルータ上でグローバル設定モードを終了します。

Router(config-if)# exit

ステップ 8

ルータ上でその設定を保存します。

Router# copy running-config startup-config

ステップ 9

Content Engine 上で WCCP 2 を使用可能にします。

ContentEngine(config)# wccp version 2

ステップ 10

Content Engine 上で Web キャッシュ サービスを設定します。

a. Web キャッシュ サービスにルータ リストを設定します。

b. Content Engine 上で Web キャッシュ サービスを設定し、作成したばかりのルータ リスト(この場合、router-list 1)にそのサービスを関連付けます。また、このコマンドを使用すると、Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに知らせます。


 

ContentEngine(config)# wccp router-list 1 10.10.10.1
ContentEngine(config)# wccp web-cache router-list-num 1

ステップ 11

Web キャッシュ サービスを設定し、そのサービスをステップ 2 で作成したルータ リストに関連付けて、レイヤ 2 リダイレクト オプションを割り当てます。マスク アサイメント方式が未指定の場合は、負荷分散方式のデフォルトはハッシュアサイメントです。

ContentEngine(config)# wccp web-cache router-list-num 1 l2-redirect

ステップ 12

グローバル設定モードを終了します。

ContentEngine(config)# exit

ステップ 13

実行コンフィギュレーションを不揮発性メモリに書き込みます。

ContentEngine# write memory

設定例:クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス

この例では、図 4-6 で示されているトポロジを使用して、Content Engine とルータを Web キャッシュ サービス用に設定する例を示します。

Content Engine

hostname Content_engine_5.0
!
clock timezone pst -8 0
!
ip domain-name cu.net
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
. . .

WCCP 対応ルータ

Building configuration...
 
Current configuration:
!
version 12.0
!
hostname WCCP-Router
!
!
ip wccp web-cache
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
ip route-cache same-interface
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
!
end

クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

このシナリオでは、Content Engine と要求側クライアントが異なるサブネット上に配置されています(図 4-7 を参照)。

WCCP Version 2 を実行するルータは、ルータ インターフェイス s0/0 宛てのクライアント HTTP トラフィックを Content Engine に透過的に転送します。Web キャッシュ サービスは、ポート 80 上だけで HTTP トラフィックを転送します。

図 4-7 Content Engine とクライアントが異なるサブネット上にある場合の Web キャッシュ サービス

 

クライアントと Content Engine が異なるサブネット上にある場合、Web キャッシュ サービス用に ルータおよび Content Engine をローカル側で設定する手順は、次のとおりです。

 

 
目的
コマンド

ステップ 1

Web キャッシュ サービスを実行するようにルータに指示します。

Router(config)# ip wccp web-cache

ステップ 2

設定するルータ インターフェイスを指定します。このシナリオでは、Serial0 が、インターネットとのルータ インターフェイスです。

Router(config)# interface Serial0

ステップ 3

指定されたインターフェイス宛ての Web キャッシュ トラフィックを、Web キャッシュ サービスを受け入れる Content Engine に転送するように、ルータに指示します。このシナリオの場合、ルータは 1 つです。Web キャッシュ トラフィックは、TCP ポート 80 トラフィックとして定義されます。

Router(config-if)# ip wccp web-cache redirect out

ステップ 4

Content Engine で WCCP Version 2 を使用可能にします。

ContentEngine(config)# wccp version 2

ステップ 5

ルータ リストを設定します。

ContentEngine(config)# wccp router-list 1 10.10.20.1

ステップ 6

Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに知らせます。

ContentEngine(config)# wccp web-cache router-list-num 1

ステップ 7

グローバル設定モードを終了します。

ContentEngine(config)# exit

ステップ 8

実行設定を不揮発性メモリに書き込みます。

ContentEngine# write memory

設定例:クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス

この例では、図 4-7 で示されているトポロジを使用して、Content Engine とルータを Web キャッシュ サービス用に設定する例を示します。

Content Engine の設定

. . .
hostname Content_engine_5.0
!
clock timezone pst -8 0
!
ip domain-name cisco.com
!
exec-timeout 20
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
...

WCCP 対応ルータの設定

Building configuration...
 
Current configuration:
!
hostname WCCP-Router
!
!
ip subnet-zero
!
ip wccp web-cache
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
!
interface Ethernet1
ip address 10.10.20.1 255.255.255.0
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
!
end
 

Content Engine 上の透過キャッシング サービスのディセーブル化

WCCP 環境の Content Engine 上で電源をオフにせずに透過キャッシングをディセーブルにするには、no wccp version グローバル設定コマンド(たとえば、 no wccp version 2 コマンドを使用して、WCCP Version 2をディセーブルにする)を発行して、Content Engine で実行している WCCP バージョンをディセーブルにします。WCCP の実行バージョンを無効にしても、Content Engine は、プロキシ スタイルの要求を処理し(そのように設定されている場合)、その設定値を保存します。


) この章の配置シナリオで説明している Content Engine を設定する際に使用される CLI コマンドの詳細は、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


ソフトウェア設定の確認

Content Engine の設置と設定を行い、ルータ上で WCCP キャッシング サービスを使用可能にした後、Web キャッシュ サービスが正常に動作しているかどうかを次の手順で確認します。


ステップ 1 Web ブラウザを始動し、インターネットまたはイントラネット上のさまざまな Web ページを開きます。WCCP の Version 1 または Version 2 を実行しているホーム ルータ、または WCCP Version 2 を実行しているルータのクラスタのいずれかを要求が通過するには、ユーザが接続する Web サーバは、別のサブネット上にある必要があります。同じページを複数回要求して、要求するページがキャッシュ内にあることを確認してください。WCCP の詳細については、 付録 B 「Web Cache Communication Protocol Version 1」 、および 付録 C「Web Cache Communication Protocol Version 2」 を参照してください。

ステップ 2 CLI で次のコマンドを入力して、統計情報を保存する Content Engine HTTP キャッシングを表示します。

ContentEngine# show statistics http savings

ヒント それらの統計情報を表示するには、Content Engine GUI から Reporting > Savings の順に選択します。

ステップ 3 ホーム ルータ上でコンソール セッションまたは Telnet セッションを開き、 show ip wccp コマンドを入力して、Content Engine についての統計情報と状況情報を表示します。

統計情報では、リダイレクトされたパケットについて、0 より大きい数値が表示されているはずです。また、ハッシュ割り当てもチェックします。これは、少なくとも Content Engine が登録され、ルータと通信していることを示します。

ルータが Content Engine にリダイレクトされるパケットを示さない場合は、セットアップのトラブルシューティングを行う必要があります。


 

IP スプーフィングの設定

一般的な透過キャッシングでは、ユーザは Web ブラウザに HTTP 要求を出します。この要求は、透過的に代行受信され、その後 WCCP 対応ルータにより Content Engine にリダイレクトされます。Content Engine は、ルータからの着信 TCP 接続を受け入れ、要求がストレージに存在しないオブジェクトを求める要求(キャッシュ ミス)であると判断した場合、このオブジェクトに対する要求をオリジン Web サーバに送ります。Content Engine がオリジン Web サーバと通信するとき、Content Engine は、クライアントの IP アドレスではなく、クライアントの代行として自身の IP アドレスを使用します。

一方 IP スプーフィングの、透過リダイレクト プロセスで、Content Engine は認証を得るために、クライアントの IP アドレスをオリジン Web サーバへ送信できるようにします。IP スプーフィングを有効にするには、 wccp spoof-client-ip enable グローバル設定コマンドを使用します。IP スプーフィング機能を無効にするには、 no wccp spoof-client-ip enable コマンドを使用します。


) Content Engine で IP スプーフィングを有効にするには、クライアント、オリジン サーバ、および Content Engine をサービスするルータ インターフェイスを事前に設定しておく必要があります。詳細は、「設定例:IP スプーフィング」および「IP スプーフィング用の Content Engine および WCCP 対応ルータの設定」を参照してください。


IP スプーフィングは、次のようなシナリオで推奨されます。

ユーザ IP アドレスのログ記録

ユーザ IP アドレスに基づくフィルタリング

ある種のユーザに他のユーザよりよいサービスを提供するための、ポリシーベースのルーティング


ヒント Content Engine は、認証トラフィック バイパスを使用して、動的なアクセス リストを自動的に生成し、選択されたクライアント/サーバのペアに対するユーザ IP アドレスを使用して、サーバに接続することもできます。

ユーザは、要求をサービスしている Content Engine 上でhttp append x-forwarded-for-header コマンドを使用して、IP スプーフィングをオンにすることなく、クライアントの IP アドレスを転送することもできます。


WCCP 対応ルータを使用する通常の透過リダイレクションでは、ルータは、クライアントによって送信されたパケットだけを代行受信します。その後、このルータは要求を Content Engine に転送します。また、IP スプーフィングでは、ルータはクライアントの IP アドレスに送信されるサーバからのパケットを代行受信し、それらのパケットを Content Engine にリダイレクトします。


ヒント IP スプーフィングを使用可能にするには、Web クライアント、Content Engine およびオリジン Web サーバを WCCP 対応ルータの 3 つのインターフェイス上に設定する必要があります(図 4-8 を参照)。


ループバックを回避するために、 ip wccp redirect exclude in コマンドを使用して、Content Engine に接続されているルータ インターフェイス上のトラフィックのリダイレクトを無効にする必要があります。これは、ルータが送信元の IP アドレスを使用してパケットを Content Engine に送信しようとするからです。クライアントに接続されているルータ インターフェイス上で、トラフィックのリダイレクトを有効にする必要もあります。

IP スプーフィングの設定に必要な手順の詳細は、「IP スプーフィング用の Content Engine および WCCP 対応ルータの設定」、および「設定例:IP スプーフィング」を参照してください。

このシナリオでは、Content Engine と要求側クライアントが異なるサブネット上に配置されています(図 4-8 を参照)。このシナリオでは、Web キャッシュ サービスおよびユーザーが設定可能なサービス グループ番号(この場合は 95)が使用されています。


ユーザが設定可能なサービスグループ番号の範囲は、90 ~ 97 です。Content Engine 上で設定可能なサービスのリストについては、表 4-1 を参照してください。


図 4-8 IP スプーフィングに対応する、異なるサブネットワーク上にある Content Engine とクライアント

 

透過プロキシ スタイル要求の IP アドレス スプーフィング

ACNS ソフトウェア リリース 5.0.x では、透過的に代行受信されたプロキシ スタイル要求に対して IP アドレス スプーフィングを実行しません。ただし、オリジナル要求でプロキシ サーバを使用してコンテンツを取得するように、Content Engine が設定されている場合、ACNS ソフトウェア(リリース 5.0.7 以降)を使用すると、透過的に代行受信されたプロキシ スタイル要求に対して、IP アドレス スプーフィングが実行されます。

オリジナル要求からプロキシ サーバを使用できるように Content Engine を設定するには、 proxy-protocols transparent original-proxy グローバル設定コマンドを使用します。

プロキシ スタイルおよび サーバ スタイルの HTTP 要求

クライアントが、プロキシ サーバまたは自動プロキシ設定ファイル(PAC ファイル)を使用し、プロキシ転送サーバを経由して要求を送信するように設定されている場合、クライアントはプロキシ スタイルの HTTP 要求を送信します。また、クライアントは HTTP 方式のオリジン サーバ名を含む完全な宛先を使用して、プロキシ サーバの IP アドレスに要求を送信します。サーバ スタイルの HTTP 要求の場合、クライアントは、HTTP ホスト名、オリジン サーバのドメイン名を含むヘッダー、およびクライアントが要求するファイルまたはスクリプトへのパスを含む HTTP 方式(たとえば、GET)を使用して、その要求を宛先サーバに直接送信します。

ドメイン myserver.com mydirectory にある myfile.html に対するプロキシ スタイルの要求は、透過的に代行受信されるとき、次の初期 HTTP ラインになっています。

GET http://myserver.com/mydirectory/myfile.html HTTP/1.1

ドメイン myserver.com mydirectory にある myfile.html に対するサーバ スタイルの要求は、透過的に代行受信されるとき、次の初期 HTTP ラインになっています。

GET /mydirectory/myfile.html HTTP/1.1

IP スプーフィング用の Content Engine および WCCP 対応ルータの設定

IP スプーフィング用に Content Engine および WCCP 対応ルータを設定する手順は、次のとおりです。

 

 
目的
コマンド
 

IP スプーフィング用の Content Engine の設定

 

ステップ 1

Content Engine 上で WCCP Version 2 を使用可能にします。

ContentEngine(config)# wccp version 2
 

ステップ 2

ルータ リストを設定します。

ContentEngine(config)# wccp router-list 1 10.10.20.1

ステップ 3

ポート リスト 1 をポート 80 を通じて WCCP サービス グループに関連付けるように設定します。

ContentEngine(config)# wccp port-list 1 80
 

ステップ 4

サービス グループ番号 95、関連ルート リスト、ポート リスト 1、およびハッシュ パラメータを送信元 IP アドレス、および送信元ポートを使用して設定します。

ContentEngine(config)# wccp service-number 95 router-list-num 1 port-list-num 1 application cache hash-source-ip match-source-port

ステップ 5

Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに通知します。

ContentEngine(config)# wccp web-cache router-list-num 1

ステップ 6

クライアント IP スプーフィングを使用可能にします。

ContentEngine(config)# wccp spoof-client-ip enable

ステップ 7

Content Engine 上でグローバル設定モードを終了します。

ContentEngine(config)# exit

ステップ 8

実行設定を不揮発性メモリに書き込みます。

ContentEngine# write memory

 

IP スプーフィング用に WCCP 対応ルータを設定するには、グローバル設定モードで WCCP 対応ルータにログインし、次の手順を実行します。

 

ステップ 9

Web キャッシュ サービスを実行するようにルータに指示します。

Router(config)# ip wccp web-cache

ステップ 10

ルータ上で WCCP サービス グループ 95 を使用可能にします。

Router(config)# ip wccp 95

ステップ 11

設定するインターフェイスを指定し、インターフェイス設定モードに入ります。

Router(config)# interface type number

 

ステップ 12

宛先 IP アドレス上でハッシュを行うサービスを使用して、オリジン Web サーバに向かうインターフェイス上で、WCCP リダイレクションをイネーブルにします(図 4-8 を参照)。

Router(config-if)# ip wccp web-cache redirect out

ステップ 13

発信元 IP アドレス上でハッシュを行うサービスを使用して、クライアントに向かうインターフェイス上で、WCCP リダイレクションをイネーブルにします(図 4-8 を参照)。

Router(config-if)# ip wccp 95 redirect out

ステップ 14

Content Engine に接続されているインターフェイス上で、WCCP リダイレクションをディセーブルにします(図 4-8 を参照)。

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

ステップ 15

グローバル設定モードを終了します。

Router(config-if)# exit

ステップ 16

ルータ上に設定を保存します。

Router# copy running-config startup-config

) ユーザが Content Engine ファームを使用しており、このファーム内に重み付け割り当てを使用している場合は、送信パケットと受信パケットの双方に対して、IP スプーフィングに割り当てられたサービス グループに対するこれらの重み付け割り当てが、すべての Content Engines 上で同じであり、TCP 接続が中断されないことを確認する必要があります。必要に応じて、これらのサービス グループに対して重み付けを割り当てるには、wccp service-number servnumber router-list-num num port-list-num port application cache weight percentage グローバル設定コマンドを使用します。デフォルトでは、Content Engine ファームは、IP スプーフィングが使用可能な状態で、適切なハッシュを行っており、サービス グループに対する重み付けの割り当ては不要です。


設定例:IP スプーフィング

この例では、IP スプーフィング用に設定された Content Engine とルータを示しています。

Content Engine の設定

:
ContentEngine# show running-config
hostname ContentEngine
!
http proxy incoming 8080
!
ip domain-name cisco.com
!
primary-interface FastEthernet 0/0
!
interface FastEthernet 0/0
ip address 10.20.0.2 255.255.0.0
exit
interface FastEthernet 0/1
shutdown
exit
!
!
ip default-gateway 10.20.0.1
!
logging console priority debug
!
wccp router-list 1 10.20.0.1
wccp port-list 1 80
wccp web-cache router-list-num 1
wccp service-number 95 router-list-num 1 port-list-num 1 application cache hash-source-ip match-source-port
wccp version 2
wccp spoof-client-ip enable
!
username admin password 1 XTPu6hUoZVYxQ
username admin privilege 15
!
authentication login local enable primary
authentication configuration local enable primary
 

WCCP 対応ルータ上で必要なコマンドの設定例は、次のとおりです。

Router# show running-config
Building configuration...
 
Current configuration:1240 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname rtr
!
boot system flash:flash-is-mz.122-6
enable password xxxxxx
!
ip subnet-zero
ip wccp 95
ip wccp web-cache
no ip domain-lookup
ip domain-name cisco.com
!
interface Ethernet0
no ip address
media-type 10BaseT
!
interface Ethernet1
<<<*** Interface connected to the external gateway.
ip address 10.1.1.203 255.255.255.0
ip wccp web-cache redirect out
media-type 10BaseT
 
!
interface Ethernet2
<<<*** Interface connected to the clients.
ip address 10.20.210.1 255.255.255.0
ip wccp 95 redirect out
media-type 10BaseT
!
interface Ethernet3
no ip address
media-type 10BaseT
!
interface Ethernet4
no ip address
shutdown
media-type 10BaseT
!
interface Ethernet5
no ip address
shutdown
media-type 10BaseT
!
interface FastEthernet0
<<<*** Interface connected to the Content Engines.
ip address 10.20.0.1 255.255.255.0
ip wccp redirect exclude in
full-duplex
!
ip default-gateway 10.1.1.1
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip http server
ip pim bidir-enable
!
!
line con 0
exec-timeout 0 0
line aux 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password xxxxxx
no login
line vty 5 7
login
!
end
 
Router#
 

高速 WCCP レイヤ 2 のサポートの設定

高速 WCCP とは、ルータまたはスイッチ上の WCCP が、レイヤ 2 のハードウェアで WCCP のトラフィック代行受信機能、およびリダイレクション機能を部分的または完全に実装する、スイッチング ハードウェアを利用できる配置の一般的な呼び方です。この高速 WCCP により、Content Engine は、Cisco 互換スイッチに直接接続されている場合、レイヤ 2 または MAC アドレス リライトのリダイレクションを実行します。このリダイレクト プロセスはスイッチング ハードウェアで加速されるので、この方式はレイヤ 3 GRE カプセル化よりも効率的に実行されます。


) 現在、加速 WCCP をサポートしているのは、Cisco Catalyst 6000 および 6500 シリーズ スイッチだけです。


Content Engine には、スイッチとのレイヤ 2 接続が必要です。GRE トンネルは、スイッチと Content Engine 間に何も必要としないので、スイッチは、CLI から l2-redirect オプションを指定して、カプセル化パケットを転送するカットスルー方式を使用できます。

カプセル化に Layer 2 転送を選択する場合、ルータまたはスイッチと Content Engines 間の負荷分散には次の 2 つの方式があります。

ハッシュ アサイメント

Catalyst 6000 および 6500 シリーズ スイッチの場合、この負荷分散方式は、WCCP Layer 2 Policy Feature Card(PFC)リダイレクションと呼ばれます。この方式は、Supervisor Engine 1A と Multilayer Switch Feature Card 2(MSFC2)を組み合せて使用し、最高 3 ギガビット/秒の転送パフォーマンスを実現します。

マスク アサイメント

この不可分散方式は、WCCP レイヤ 2 Policy Feature Card 2(PFC2)リダイレクションと呼ばれています。この方式では、Supervisor Engine 2 と MSFC2 を組み合せて使用しています。

Content Engine がサポートしているすべての WCCP サービス グループは、次のコマンドを使用して、ハッシュ アサイメントまたはマスク アサイメントの負荷分散方式を Layer 2 転送と連携してサポートします。使用するコマンドは、 wccp custom-web-cache wccp media-cache wccp reverse-proxy wccp service-number wccp web-cache wccp wmt 、および wccp rtsp to です。


) Content Engine 1 ファームにつき、使用できる負荷分散方式は、1 方式だけです。



ヒント マスク アサイメント負荷分散方式を使用する Layer 2 リダイレクション カプセル化を有効にできるのは、CLI コマンドだけです。


ハッシュ負荷分散方式を使用する Layer 2 転送の設定

負荷分散方式にハッシュ アサイメントを使用して Catalyst 6500 シリーズ スイッチから Layer 2 リダイレクト トラフィックを受信するように Content Engine を設定する手順は、次のとおりです。

 

 
目的
コマンド

ステップ 1

Content Engine で WCCP Version 2 を使用可能にします。

ContentEngine(config)# wccp version 2

ステップ 2

ルータ リスト番号およびそれに関連する IP アドレスを設定します。

ContentEngine(config)# wccp router-list 1 172.16.55.1

ステップ 3

Web キャッシュ サービスを設定し、そのサービスをステップ 2 で作成したルータ リストに関連付けて、レイヤ 2 リダイレクト オプションを割り当てます。マスク アサイメント方式が未指定の場合は、負荷分散方式はデフォルトのハッシュアサイメントになります。

ContentEngine(config)# wccp web-cache router-list-num 1 l2-redirect
 

ステップ 4

設定内容を検証できるように、その内容を表示します。

ContentEngine# show wccp services detail

ステップ 5

実行設定を不揮発性メモリに書き込みます。

ContentEngine# copy running-config startup-config

マスク負荷分散方式を使用する Layer 2 転送の設定

次の手順では、Multilayer Switch Feature Card 2 と Supervisory Engine 2(MSFC2/SUP 2)を実装している Catalyst 6500 シリーズ スイッチから、リダイレクトされたレイヤ 2 トラフィックを受信するように、Content Engine を設定します。

 

 
目的
コマンド

ステップ 1

Content Engine で WCCP Version 2 を使用可能にします。

ContentEngine(config)# wccp version 2
 

ステップ 2

ルータ リスト番号およびそれに関連する IP アドレスを設定します。

ContentEngine(config)# wccp router-list 1 172.16.55.1

ステップ 3

Web キャッシュ サービスを手順 2 で作成したルータ リストと関連付けて、レイヤ 2 リダイレクト オプションをマスク アサイメント 負荷分散方式に割り当てます。

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

ステップ 4

設定内容を検証できるように、その内容を表示します。

ContentEngine# show wccp services detail

ステップ 5

実行設定を不揮発性メモリに書き込みます。

ContentEngine# copy running-config startup-config

CSS スイッチを経由した透過キャッシングの設定

CSS スイッチを経由した透過キャッシングを設定するには、次の重要事項に注意してください。

CSS スイッチは、透過キャッシングと従来のプロキシ キャッシングをサポートします。また、高度なリバース プロキシ キャッシングを使用した Web の高速化もサポートします。CSS スイッチは、複数の Content Engine 上にデータを配分する方法(たとえば、URL 全体、URL ストリング、ドメイン名全体、またはドメイン ストリング)に応じて、複数の負荷分散方式を備えています。また CSS スイッチは、既知のキャッシュ可能オブジェクトのリストも作成します。このリストは変更可能ですが、変更作業の大部分は、Content Engine のキャッシング機能によって軽減されます。

ユーザは CSS スイッチを設定して、スイッチがコンテンツを動的に分析し、そのコンテンツがキャッシング可能かどうかを判別するようにできます。コンテンツがキャッシング可能である場合、CSS スイッチはそのコンテンツをキャッシュ サービスに送信します。キャッシングができない場合、CSS スイッチは直接、オリジン Web サーバにそのコンテンツを送信します。

すべてのキャッシュ サーバで透過キャッシングが設定できない場合、CSS スイッチは、すべてのクライアント要求をオリジン Web サーバに送信します。

CSS スイッチを経由した透過キャッシングを設定するには、次の作業が必要です。

CSS スイッチ上で透過キャッシングをイネーブルにします。

Content Engine 上で、CSS スイッチから転送されたトラフィックを受け入れ可能にします。

Content Engine 上で透過キャッシングをイネーブルにします。

CSS スイッチを使用した透過キャッシングのイネーブル化

CSS スイッチを使用した透過キャッシング サービスとして serv1 を設定するには、次のコマンドを使用します。CSS スイッチを使用したキャッシングを設定する前に、インターフェイス、サービス、所有者、VLAN、およびコンテンツ ルールを必ず設定しておいてください。


) CSS スイッチでこれらの属性を設定する方法の詳細は、『Content Services Switch Basic Configuration Guide』を参照してください。各コマンドの詳細については、『Content Services Switch Command Reference』を参照してください。


CSS スイッチを使用した透過キャッシングをイネーブルにするには、次の作業を実行します。

 

 
目的
コマンド

ステップ 1

透過キャッシング用に予約されたサービス serv1 を追加します。

CS150(config)# add service serv1
CS150(config-service[serv1])#

ステップ 2

serv1 に対する透過キャッシングのサービス タイプを指定します。

CS150(config-service[serv1])# type transparent cache

ステップ 3

CSS スイッチがキャッシングを行うコンテンツのタイプを指定する、EQL(Extension Qualifier List)を作成します。

CS150(config)# eql graphics
CS150(config-eql[graphics]#

ステップ 4

引用符で囲んだ最長 64 文字以内のテキストで、EQL の説明を入力します。

CS150(config-eql[graphics]# description “This EQL specifies cacheable graphic files”

ステップ 5

CSS スイッチにキャッシングするコンテンツの拡張子を指定します。1 ~ 8 文字のテキスト文字列を入力します。

CS150(config-eql[graphics]# extension jpeg

拡張子のタイプについてもここで記述できます。引用符付きのテキスト文字列で、最長 64 文字まで使用できます。

CS150(config-eql[graphics]# extension jpeg “This is a graphics file”
CS150(config-eql[graphics]# exit

CS150(config)#

ステップ 6

コンテンツ ルールに EQL を指定して、すべてのコンテンツ要求が所定の拡張子と一致するようにします。

CS150(config-owner-content[cisco.com-rule1])# url “/*” eql graphics

ステップ 7

キャッシュ コンテンツ ルールに対して負荷分散方式を設定します。デフォルトは、ラウンドロビンです。

CS150(config-owner-content[cisco.com-rule1])# balance domain

ステップ 8

フェールオーバー タイプ(バイパス、リニア、ネクスト)を指定して、サービスに障害が起きた場合、CSS スイッチがコンテンツ要求を処理する方式を指定します。デフォルトはリニアです。

CS150(config-owner-content[cisco.com-rule1])# failover bypass

ステップ 9

EQL 設定を表示します。

CS150(config-owner-content[cisco.com-rule1])# show eql

ステップ 10

キャッシュ設定を示すコンテンツ ルールを表示します。

CS150(config-owner-content[cisco.com-rule1])# show rule

ステップ 11

CSS スイッチで設定モードを終了します。

CS150(config-owner-content[cisco.com-rule1])# end

ステップ 12

設定を保存します。これで、透過キャッシング サービス用に CSS スイッチが設定されます。

CS150(config-owner-content[cisco.com-rule1])# copy running-config startup-config

ステップ 13

Content Engine を設定して、CSS スイッチなどのレイヤ 4 対応スイッチから転送されたレイヤ 4 トラフィックを透過的に受信します。

ContentEngine(config)# http l4-switch enable

ステップ 14

Content Engine 上で設定モードを終了します。

ContentEngine(config)# exit

ステップ 15

実行設定を不揮発性メモリに書き込みます。

ContentEngine# write memory

透過キャッシングの設定出力例

次の例は、CLI コマンドを使用した透過キャッシングを行う CSS スイッチの、最も基本的な設定出力です。CSS スイッチのプロビジョニング後にスイッチ設定パラメータを表示するには、 show running-config CLI コマンドを使用します。

!Generated MAY 19 15:36:34
!Active version:ap0310029s
prompt TransCache
configure
!************************* INTERFACE *************************
interface ethernet-12
bridge vlan 2
!************************** CIRCUIT **************************
circuit VLAN1
ip address 10.1.1.254 255.255.255.0
circuit VLAN2
ip address 192.168.1.254 255.255.255.0
!************************** SERVICE **************************
service Origin1
ip address 10.1.1.1
keepalive frequency 60
service TCacheServer1
ip address 10.1.1.11
type transparent-cache
port 80
active
service TCacheServer2
ip address 10.1.1.12
type transparent-cache
port 80
active
!**************************** EQL ****************************
eql Cacheable
description "This EQL contains extensions of cacheable content"
extension pdf "Acrobat"
extension fdf "Acrobat Forms Document"
extension au "Sound audio/basic"
extension bmp "Bitmap Image"
extension z "Compressed data application/x-compress"
extension gif "GIF Image image/gif"
extension html "Hypertext Markup Language text/html"
extension js "Java script application/x-javascript"
extension mocha
extension jpeg "JPEG image image/jpeg"
extension jpg
extension jpe
extension jfif
extension pjpeg
extension pjp
extension mp2 "MPEG Audio audio/x-mpeg"
extension mpa
extension abs
extension mpeg "MPEG Video video/mpeg"
extension mpg
extension mpe
extension mpv
extension vbs
extension m1v
extension pcx "PCX Image"
extension txt "Plain text text/plain"
extension text
extension mov "QuickTime video/quicktime"
extension tiff "TIFF Image image/tiff"
extension tar "Unix Tape Archive application/x-tar"
extension pcx "PCX Image"
extension txt "Plain text text/plain"
extension text
extension mov "QuickTime video/quicktime"
extension tiff "TIFF Image image/tiff"
extension tar "Unix Tape Archive application/x-tar"
extension avi "Video for Windows video/x-msvideo"
extension wav "Wave File audio/x-wav"
extension gz "application/x-gzip"
extension zip "ZIP file application/x-zip-compressed"
 
!*************************** OWNER ***************************
owner cisco.com
content L5_Transparent
protocol tcp
port 80
url "/*" eql Cacheable
balance urlhash
add service TCacheServer1
add service TCacheServer2
active

) スイッチはクライアントから見えない透過型の装置のため、仮想 IP アドレスはありません。



) キャッシング可能なものはすべて、URL に基づいて負荷分散され、キャッシュ サーバに送られます。


Content Engine 上での転送レイヤ 4 トラフィックの受信イネーブル化

透過キャッシング サービス用に CSS スイッチを設定した後、Content Engine を CSS スイッチなどのレイヤ 4 対応スイッチから転送されたレイヤ 4 トラフィックを透過的に受信するように設定する必要があります。 http l4-switch enable コマンドを使用すると、Content Engine は、レイヤ 4 対応スイッチ(たとえば、CSS スイッチ)から転送されたレイヤ 4 トラフィックを透過的に受信するようになります。