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

目次

Rules Template の設定

Rules Template の概要

アクションとパターンの概要

アクション

パターン

Rules Template 処理の考慮事項

ルール アクションの実行順序

ルール パターンの実行順序

Rules Template の設定

ローカルに配置された Content Engine での CLI コマンドを使用したルール設定

CLI コマンドを使用したパターン リストの設定

CLI コマンドを使用した既存パターン リストへのパターンの追加

CLI コマンドを使用した既存パターン リストへのアクションの関連付け

CLI コマンドを使用したパターン リストで実行されるアクションの確認

CLI 設定例

Rules Template の設定

この章では、Rules Template(ルール テンプレート)を使用して、さまざまな要求パラメータを使用した要求を指定する方法を説明します。この章の構成は、次のとおりです。

「Rules Template の概要」

「アクションとパターンの概要」


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


Rules Template の概要

Rules Template 機能は、設定可能なキャッシング要求を指定するための柔軟なメカニズムを備えています。この機能を使用すると、キャッシング要求を任意の数のパラメータと一致させ、これらの一致に対して任意の数のポリシー を適用できます。ユーザは一連のルールを指定でき、それぞれのルールは、アクションとパターン リストにより明確に識別できます。以降、着信要求ごとに、ルールのパターン リストがその要求と一致すれば、そのルールに対応するアクションが実行されます。

要求を照合できる対象は、ドメイン名を表す正規表現、送信元 IP アドレスとネットワーク マスク、宛先 IP アドレスとネットワーク マスク、宛先ポート番号、MIME タイプ、または URL を表す正規表現です。

Rules Template 機能は、HTTP、FTP、HTTPS の各プロトコルに最も適しています。HTTP、FTP、および HTTPS のほかに、MMS や RTSP などのストリーミング メディア オブジェクト プロトコルをサポートするポリシーを次に示します。

要求の実行を可能にする

ユーザ名を要求ヘッダーに付加する

要求をブロックする(MMS、RTSP にも適用)

HTTP 応答ヘッダーを上書きし、オブジェクトをキャッシングする

HTTP 応答ヘッダーに応じてオブジェクトをキャッシングする

要求の認証をバイパスする(MMS、RTSP にも適用)

要求をリセットする

オブジェクトの新鮮度を計算する特定係数を使用する

オブジェクトをキャッシングしない

要求のアップストリーム プロキシをバイパスする

別の URL に要求をリダイレクトする(RTSP にも適用)

オリジン サーバでオブジェクトを再検証する

URL を再書き込みする(MMS、RTSP にも適用)

特定の ICAP サーバを使用する

特定のアップストリーム プロキシを使用する

要求に特定のサーバを使用する

クライアントに送信される応答の ToS または DSCP を設定する

サーバに送信される応答の ToS または DSCP を設定する


) コマンドライン インターフェイスから疑問符(?)をルールの正規表現に入力するには、エスケープ文字を使用し、その後に疑問符(?)を入力してください。これにより、コマンドライン インターフェイスにコンテキスト依存ヘルプが表示されません。


アクションとパターンの概要

ルールは、アクションとパターン リストによって指定されます。要求が rule pattern-list コマンドで指定されたパターン リストと一致する場合、この要求に対してアクションが実行されます。

アクションとは、Content Engine が要求を処理する際に実行するものです。たとえば、要求をブロックしたり、代替プロキシを使用したり、一連の処理を行います。

パターン リストは、要求の範囲を限定します。たとえば、パターンでは、送信元 IP アドレスがサブネット範囲 172.16.*.* にあることを指定できます。

Content Engine のルールは、動的に追加、表示、または削除できます。ルールは、適切な CLI コマンドまたは Content Engine GUI を使用して、NVRAM などの永続的ストレージに書き込まれるので、再起動後も保持されます。Content Engine がサポートできるルールの数を制限する要素は、システム リソースだけです。ルールはリソースを消費するので、定義するルールの数が多いほど、Content Engine のパフォーマンスに大きな影響が及びます。


) ACNS 5.1 ソフトウェアでは、最大 520 のアクションを設定できます。



ヒント Rules Template の設定は、ip dscp コマンドより優先されます。url-filter コマンドは、rule コマンドより優先されます。したがって、rule no-block コマンドが実行されるのは、url-filter コマンドが要求をブロックしなかった場合だけです。


アクション

表 13-1 では、Rules Template 機能でサポートされているアクションを説明します。

 

表 13-1 サポートされるアクションのタイプ

アクション
説明

Allow

要求を許可します。

Append-username-header

キャッシュ ミス時に username-header を追加します。

Block

この要求をブロックします。

Cache-non-cacheable

HTTP 応答ヘッダーを上書きし、オブジェクトをキャッシングします。


rule action cache-non-cacheable コマンドは、オブジェクトが認証されている場合、そのオブジェクトをキャッシングできません。つまり、認証されたオブジェクトに対しては、オリジン サーバは Last-Modified、 または ETag エンティティ ヘッダーを送信しないことがあります。その結果、これらの許可されたオブジェクトは Content Engine によって再認証されません。これらの認証されたオブジェクトは、オリジン サーバからのみ配信されます。サーバが認証されたオブジェクトに対して Last-Modified および ETag ヘッダーを送る場合は、オブジェクトは適切に再認証され、キャッシュから配信されます。


Cache-only

HTTP 応答ヘッダーに応じてオブジェクトをキャッシングします。オブジェクトが一致し、HTTP によるキャッシングが可能な場合だけ、オブジェクトをキャッシングします。1 つまたは複数のルールでこのアクションを指定する場合、オブジェクトがキャッシュに保存されるのは、オブジェクトが少なくとも 1 つの cache-only ルールに一致し、object-size チェックや no-cache-on-authenticated-object チェックなど、他のキャッシング制限をすべて通過した場合だけです。オブジェクトがどの cache-only ルールにも一致しない場合、そのオブジェクトはキャッシングされません。

DSCP client

IP の ToS または DSCP コード ポイント フィールドを設定します。

cache-hit :クライアントへの cache-hit 応答の設定値に、クライアント側の接続に対する IP の ToS または DSCP コード ポイント ビットを設定します。

cache-miss :クライアントへの cache-miss 応答の設定値に、クライアント側の接続に対する IP の ToS または DSCP コード ポイント ビットを設定します。

ToS(Type of Service)または DSCP(Differentiated Services Code Point)の設定は、パケット マーキングと呼ばれます。このパケット マーキングにより、ネットワーク データを複数の優先レベルまたはサービスのタイプに区分することができます。ACNS 5.x ソフトウェアでは、URL の一致、ファイル タイプ、ドメイン、宛先 IP アドレス、送信元 IP アドレス、または宛先ポートに基づいて、IP パケット内に ToS 値または DSCP 値を設定できます。

特定の ToS 値または DSCP 値を次の項目に設定できます。

Content Engine からサーバへの要求

キャッシュ ヒット時のクライアントへの応答

キャッシュ ミス時のクライアントへの応答

ToS または DSCP の設定は、 src-ip s_ipaddress s_subnet dst-ip d_ipaddress d_subnet dst-port port domain LINE A url-regex LINE 、または mime-type LINE のオプションと一致するポリシーのいずれかに基づいて行うことができます。さらに、 ip dscp コマンドを使用して、ToS または DSCP のグローバル設定値を指定することもできます。


) Rules Template の設定は、ip dscp コマンドより優先されます。url-filter コマンドは、rule コマンドより優先されます。したがって、rule no-block コマンドが実行されるのは、url-filter コマンドが要求をブロックしなかった場合だけです。


DSCP server

オリジン サーバへの要求に対して IP の ToS または DSCP コード ポイント フィールドを設定します。

Freshness-factor

要求 URL が指定の正規表現と一致する場合、TTL(存続可能時間)を決定します。


ヒント refresh 設定は、freshness-factor 設定より優先されます。

Insert-no-cache

no-cache ヘッダーを応答に挿入します。

No-auth

認証を行いません。

次の場合、 no-auth ルールを適用すると、複数の認証ウィンドウが表示されることに注意してください。

no-auth ルールを使用して、メイン ページ(たとえば、 index.htm )がプロキシ認証から除外される場合

ユーザのエントリが、Content Engine 認証キャッシュにまだ含まれていない場合

index.htm ページに、別のドメインに属するオブジェクトが含まれている場合

複数の認証ウィンドウが表示されないようにするには、グローバル設定モードで http avoid-multiple-auth-prompts の非表示コマンドを入力します。このコマンドが設定された後、次の例のように、 show http avoid-multiple-auth-prompts の非表示コマンドを使用して設定を確認してください。

ContentEngine# show http avoid-multiple-auth-prompts
Avoiding multiple authentication prompts due to no-auth rules is enabled

) この例のコマンドは、この特定の場合だけに適用されるので非表示になります。


No-cache

このオブジェクトをキャッシングしません。 no-cache アクションと selective-cache アクションの両方が存在する場合、 no-cache が優先します。

No-proxy

キャッシュ ミスの場合、設定されたアップストリーム プロキシを使用せずに、サーバと直接交信します。

Redirect-url-for-cdn

ACNS ネットワーク コンテンツに対する元の要求を別の URL にリダイレクトします。

Redirect

元の要求を指定の URL にリダイレクトします。リダイレクトは、RADIUS サーバの redirect が設定されている場合だけ、その RADIUS サーバに関連します。

Refresh

キャッシュ ヒットの場合、オブジェクトの新鮮度チェックをサーバに要求します。

Reset

TCP RST を実行します。


ヒント このリセット要求は、Code Red または Nimda のウィルス要求をリセットする場合に便利です。

Rewrite

オリジナルの要求を指定の URL として再書き込みします。Content Engine はキャッシュ内で再書き込みされた URL を検索します。キャッシュ ミスの場合は、再書き込みされた URL をフェッチし、透過的にそのオブジェクトをクライアントに送信します。パフォーマンスに影響を与える可能性があるので、 rewrite ではなく、 redirect ルールを使用するようにお勧めします。


ヒント URL の再書き込みは、URL のドメイン名を変更する可能性があります。これにより、要求の送信先の新しい再書き込みサーバの宛先 IP アドレスを見付けるために、DNS ルックアップが必要になります。WCCP リダイレクト パケットから得た元の IP アドレスは、使用できません。

Selective-cache

HTTP が許可したオブジェクトをキャッシングします。

Use-dns-server

指定されている DNS サーバを使用します。

Use-icap-service

指定されている ICAP サーバを使用します。

Use-proxy

キャッシュ ミスに対して特定のアップストリーム プロキシを使用します。アップストリーム プロキシの IP アドレス(またはドメイン名)とポート番号を指定してください。


no-proxyuse-proxy の両方が存在する場合、no-proxy が優先します。


Use-proxy-failover

フェールオーバー機能をサポートします。 use-proxy-failover ルールは use-proxy ルールとほぼ同じです。ただし、設定されている発信プロキシ上での接続試行が失敗した場合に、要求が HTTP プロキシ発信設定で指定された発信プロキシにフェールオーバーされる点を除きます。ルール要求は、 http proxy outgoing origin-server オプションを使用します(設定されている場合)。 use-proxy-failover ルールは、 use-proxy ルールより優先します。 no-proxy use-proxy-failover の両方が存在する場合、 no-proxy が優先します。


) 宛先が除外リストに存在する場合、HTTP フェールオーバーは適用されません。透過モードでは、オリジナル プロキシに対する設定が優先します。


Use-server

キャッシュ ミス時に、サーバ型の HTTP 要求を Content Engine から、指定された IP アドレスとポートに送信します。


use-server ルール、no-proxy ルール、および use-proxy ルールの中では、use-server ルールが最初にチェックされます。この最初のチェックの結果、ルールに一致しない場合、no-proxy ルールと use-proxy ルールが続けて実行されます(no-proxy ルールが一致する場合、use-proxy ルールはチェックされません)。ルールが完全修飾ドメイン名(FQDN)を使用して設定され、要求が透過モードで部分ドメイン名付きで受信された場合、FQDN が要求 URL 内にないのでこのルールは実行されません。透過モードでは、要求が特定のドメイン(ドメイン ルールが設定されているドメイン)を宛先とし、Host ヘッダーをもっていない場合、ルール パターンの一致は起こりません。


パターン

表 13-2 では、Rules Template 機能でサポートされているパターンのタイプを説明します。

 

表 13-2 サポートされているパターンのタイプ

パターン
説明

Domain

URL または Host ヘッダー内のドメイン名を正規表現と照合します。たとえば、「.*ibm.*」は、「ibm」サブストリングを含むすべてのドメイン名と一致します。「\.foo\.com$」は、「.foo.com」サブストリングで終わるすべてのドメイン名と一致します。


) 正規表現の構文では、メタ文字のドル記号「$」は、このパターンが行の末尾にある場合だけ一致するように指定します。


Dst-ip

要求の宛先 IP アドレスとネットマスクを照合します。IP アドレスとネットマスクを指定してください。プロキシ モードでは、Content Engine が DNS ルックアップを実行して HTTP 要求の宛先 IP アドレスを解決するので、応答時間が長くなり、 dst-ip ルールを設定する利点が生かされないことがあります。発信プロキシが設定される場合、キャッシュ ミス要求は宛先サーバの IP アドレスを調べることなく、Content Engine によって発信プロキシに転送され、最初の Content Engine 上で dst-ip ルールを実行不能にします。

Dst-port

要求の宛先ポート番号を照合します。ポート番号を指定してください。

Group-type

パターン リストを AND または OR のどちらのタイプにするかを指定します。

ICAP-attribute

ICAP サービスの属性と値のペアを指定します。

Mime-type

応答の MIME タイプを一照合します。MIME タイプのストリング、たとえば RFC 2046( http://www.faqs.org/rfcs/rfc2046.html )で定義されている「image/gif」を指定してください。システム管理者は、サブストリング(たとえば、「java」)を指定し、「java」のサブストリングをもつすべての MIME タイプ(たとえば、「application/x-javascript」)に、そのサブストリングを適用することができます。

Src-ip

要求の送信元 IP アドレスとネットマスクを照合します。IP アドレスとネットマスクを指定してください。

URL-regex

URL を正規表現と照合します。この照合には、大文字と小文字の区別はありません。次の Web サイトに示されている構文の正規表現を指定してください。

http://yenta.www.media.mit.edu/projects/Yenta/Releases/Documentation/regex-0.12/

Header-field

要求ヘッダー フィールド パターン。 referer request-line 、および user-agent の要求ヘッダー フィールド パターンが、 block reset redirect 、および rewrite の各アクションに対してサポートされます。 referer パターンは要求内の Referer ヘッダーと照合され、 request-line パターンは要求の先頭行と照合され、 user-agent パターンは要求内の User-Agent ヘッダーと照合されます。

Header-field-sub

要求ヘッダー フィールド パターンと代替の置換パターン。

URL-regsub

rewrite redirect のアクションに対して、URL を正規表現と照合し、パターンの置換指定ごとに新しい URL を作成します。


ヒント この照合には、大文字と小文字の区別はありません。有効な置換インデックスの範囲は 1 ~ 9 です。

Rules Template 処理の考慮事項

アクションとパターンの実行には、事前に定義されている順序があります。すなわち、同じアクションを行うルールのグループは、常に、別のアクションを行うルールのグループの前または後で実行されます。ルール アクションが実行される順序については、「ルール アクションの実行順序」を参照してください。この順序は、CLI コマンドを使用してルールが入力される順序によって影響を受けることはありません。

同じアクションのルールの中では、ルール パターンの実行には事前に定義されている順序があります。すなわち、同じアクションのルール グループ内で、同じパターンをもつルールのグループは、別のパターンをもつルールのグループの前または後で実行されます。ルール パターンが実行される順序については、「ルール パターンの実行順序」を参照してください。この順序は、CLI コマンドを使用してルールが入力される順序によって影響を受けることはありません。

ルール アクションの実行順序

ルール アクションが実行される順序は、次のとおりです。

1. Redirect-url-for-cdn :キャッシュ ルックアップの前

2. No-auth :RADIUS、LDAP、NTLM、または TACACS+ を使用した認証の前

3. Use-icap-service :ICAP サーバからのサービスを使用したキャッシュ ルックアップの前

4. Reset :キャッシュ ルックアップの前

5. Allow および Block :キャッシュ ルックアップの前( Allow Block の優先度は同じです)

6. Redirect :キャッシュ ルックアップの前

7. Rewrite :キャッシュ ルックアップの前

8. Refresh :キャッシュ ヒット時

9. Freshness-factor :キャッシュ ヒット時

10. Append-username-header :キャッシュ ミス時

11. Use-server :キャッシュ ミス時

12. No-proxy :キャッシュ ミス時

13. Use-proxy-failover :キャッシュ ミス時

14. Use-proxy :キャッシュ ミス時

15. Use-dns-server :キャッシュ ミス時

16. DSCP server :キャッシュ ミス時

17. DSCP client :キャッシュ ヒット時

18. Insert-no-cache :キャッシュ ミス時またはキャッシュ ヒット時(変数ヘッダーが応答ヘッダーに追加されるときにチェックされます)

19. No-cache :キャッシュ ミス時

20. Cache-non-cacheable :キャッシュ不能オブジェクトの場合

21. Cache-only キャッシュ ミス時


rule action no-proxyrule action use-proxy hostname port-number failover、および rule action use-proxy のコマンドは、https proxy outgoinghttp proxy outgoing、および ftp proxy outgoing のコマンドより優先されます。


Rules Template の CLI コマンドを使用した要求時に、ルール アクション 1 ~ 4 はパターンの照合にオリジナルの URL 要求を使用します。URL の再書き込み(ルール アクション 7 の Rewrite)の後、ルール アクション 8 ~ 21 はルールの実行に変換済みの URL を使用します。

rule action reset rule action block rule action rewrite 、および rule action redirect の各コマンドは、Rules Template の要求に次の追加パターンをサポートします。

Request-line :先頭行を一致させます。

Referer :Referer ヘッダーを一致させます。

User-agent :User-Agent ヘッダーを一致させます。

ルール パターンの実行順序

ルール パターンが実行される順序は、次のとおりです。

1. Header-field。

2. Header-field-sub。

3. その他のパターン: url-regsub dst-port src-ip url-regex domain dst-ip mime-type。 ただし、これらのパターンが実行されるアクションに基づく実行順序はありません。


) MIME タイプは応答内にのみ存在するので、freshness-factorrefreshno-cache、および selective-cache の各アクションだけが MIME タイプのルールに適用されます。


たとえば、次の一連のアクションでは、 pattern-list 2 header-field が最初に実行され、次に pattern-list 1 domain パターンが実行されます。ルール アクションはヘッダー情報が有効になった後だけ実行されるため、この順序が適用されます。

ContentEngine(config)# rule action block pattern-list 1
ContentEngine(config)# rule action block pattern-list 2
 
ContentEngine(config)# rule pattern-list 1 domain roti
ContentEngine(config)# rule pattern-list 2 header-field user-agent browser
 

次の例のパターンを AND 演算する場合、パターン エントリに基づいた実行順序はありません。

ContentEngine(config)# rule action block pattern 3
ContentEngine(config)# rule pattern-list 3 dst-port 80
ContentEngine(config)# rule pattern-list 3 header-field user-agent browser
 

上記の例では、 dst-port が最初にチェックされ、次に header-field がチェックされます。

したがって、この実行順序は次のようになります(ルールを AND 演算しない)。

1. Header-field。

2. Header-field-sub。

3. その他のパターン: url-regsub dst-port src-ip url-regex domain dst-ip mime-type これらが実行されるアクションに基づいた実行順序はありません。

特定のルールに通常のタイプのパターンをもつヘッダー フィールドがある場合、特別な実行順序はありません。

ルールと残りのパターン リストの一致の検索は、すでに一致が見付かっている場合は実行されません。たとえば、 rule action block アクション コマンドの一致が URL-regex 要求に見付かった場合、残りのパターンの domain dst-ip 、または MIME-type は検索されません。すべてのパターンが rewrite redirect のアクションに適用できるわけではありません。 URL-regex パターン検索のみが、 rewrite redirect のアクションに適用できます。

ルールは相互に OR 演算されます。複数のルールが 1 つの要求に一致する場合があります。この場合はすべてのアクションが実行されますが、「ルール アクションの実行順序」で定義したルール アクションの実行順序に基づいて、競合するアクション間で優先順位が設定されます。 rule action コマンドには、 rule pattern-list コマンドで設定される複数のパターンを指定できます。

いくつかのルールを回避することができます。たとえば、 domain パターンをもつルールを回避するには、ブラウザにドメイン名の代わりに、Web サーバの IP アドレスを入力します。ルールには、意図しない影響がある可能性があります。たとえば、「ibm」として指定された domain パターンをもつルールは「 www.ibm.com 」と一致することを意図したものですが、 www.ribman.com のようなドメイン名とも一致する場合があります。


) src-ip ルールは、Content Engine が別のプロキシまたは別の Content Engine から受信する要求に対して、意図した通りに適用されない場合があります。これは、元のクライアント IP アドレスが X-Forwarded-For ヘッダー内にあるからです。すなわち、元の要求の送信元 IP アドレスが、オリジン サーバに向かう途中で、送信 Content Engine の IP アドレスに透過的に置き換えられています。


1 つのルール パターンが一致すると、残りのパターンは検索されません。サーバがすでにオブジェクトをキャッシュ不能(noncacheable)と示している場合、サーバはこのオブジェクトがキャッシングされないことをすでに認識しているので、 no-cache ルールはチェックされません。 no-cache ルールのチェックはすべて、キャッシング可能な要求に対してのみ実行されます。

Rules Template の設定

ルールを設定する際は、次のガイドラインを使用してください。

アクションの数は無制限です。

パターンの合計の最大数は 512 です。

アクションごとのパターンの最大数は 128 です。

1 つのパターン リスト番号に対する、特定のパターン タイプのパターンの最大数は 128 です。


ヒント Rules Template は、CLI または Content Engine GUI から設定できます(図 13-1を参照)。


図 13-1 Rules Template ウィンドウ

 


ヒント Rules Template ウィンドウを表示するには、Content Engine GUI から System > Rules Templates の順に選択します。Rules Template ウィンドウの詳細を表示するには、Help ボタンをクリックします。


この章では、Rules Template を設定する方法の説明に CLI を使用しています。この項目に関する詳細は、次の「ローカルに配置された Content Engine での CLI コマンドを使用したルール設定」を参照してください。

CLI を使用してパターン リストとアクションを Rules Template に設定する方法の例については、次の項を参照してください。

「CLI コマンドを使用したパターン リストの設定」

「CLI コマンドを使用した既存パターン リストへのパターンの追加」

「CLI コマンドを使用した既存パターン リストへのアクションの関連付け」

「CLI コマンドを使用したパターン リストで実行されるアクションの確認」

ローカルに配置された Content Engine での CLI コマンドを使用したルール設定

ローカルに配置されている Content Engine で HTTP、HTTPS、MMS 、および RTSP のトラフィックをフィルタリングするルールを設定するには、 rule グローバル設定コマンドを使用します。

rule { action action-type pattern-list list_num [ protocol { all | protocol-type}] | enable | pattern-list list_num pattern-type}

表 13-3 では、 rule コマンドのパラメータを説明します。

 

表 13-3 rule CLI コマンドのパラメータ

パラメータ
説明

action

ルールに適用するアクションを記述します。

allow

アクション:要求を許可します。

pattern-list

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

list_num

パターン リスト番号(1 ~ 100)。

protocol

このルールを照合するプロトコル。

all

このルールをこのアクションに適用可能なすべてのプロトコルと照合します。

http

このルールを HTTP プロトコルと照合します。

https

このルールを HTTPS プロトコルと照合します。

mms

このルールを MMS プロトコルと照合します。

rtsp

このルールを RTSP プロトコルと照合します。

append-username-header

アクション:ユーザ名を要求ヘッダーに追加します。

block

アクション:要求をブロックします。

cache-non-cacheable

アクション:HTTP 応答ヘッダーを上書きし、このオブジェクトをキャッシングします。

ttl

このオブジェクトの Time To Live(TTL;存続可能時間)値。

days

Time To Live 単位(日数)。

days

Time To Live 日数の値(1 ~ 1825)。

hours

Time To Live 単位(時間数)。

hours

Time To Live 時間数の値(1 ~ 43800)。

minutes

Time To Live 単位(分数)。

minutes

Time To Live 分数の値(1 ~ 2628000)。

seconds

Time To Live 単位(秒数)。

seconds

Time To Live 秒数の値(1 ~ 157680000)。

cache-only

アクション:このオブジェクトのみをキャッシングします。

dscp client

アクション:IP の ToS/DSCP(Type of Service/Differentiated Services Code Point)フィールドの応答をクライアントに設定します。

cache-hit

キャッシュ ヒット時に応答をクライアントに送信します。

match-server

サーバの元の ToS/DSCP 値を使用します。

set-dscp

DSCP(Differentiated Services Code Point)値を設定します。

dscpvalue:

af11
af12
af13
af21
af22
af23
af31
af32
af33
af41
af42
af43

0 ~ 63:DSCP 値を設定します。

AF11 DSCP(001010)のパケットを設定します。
AF12 DSCP(001100)のパケットを設定します。
AF13 DSCP(001110)のパケットを設定します。
AF21 DSCP(010010)のパケットを設定します。
AF22 DSCP(010100)のパケットを設定します。
AF23 DSCP(010110)のパケットを設定します。
AF31 DSCP(011010)のパケットを設定します。
AF32 DSCP(011100)のパケットを設定します。
AF33 DSCP(011110)のパケットを設定します。
AF41 DSCP(100010)のパケットを設定します。
AF42 DSCP(100100)のパケットを設定します。
AF43 DSCP(100110)のパケットを設定します。

cs1
cs2
cs3
cs4
cs5
cs6
cs7
default
ef

CS1(優先順位 1)DSCP(001000)のパケットを設定します。
CS2(優先順位 2)DSCP(010000)のパケットを設定します。
CS3(優先順位 3)DSCP(011000)のパケットを設定します。
CS4(優先順位 4)DSCP(100000)のパケットを設定します。
CS5(優先順位 5)DSCP(101000)のパケットを設定します。
CS6(優先順位 6)DSCP(110000)のパケットを設定します。
CS7(優先順位 7)DSCP(111000)のパケットを設定します。
デフォルト DSCP(000000)のパケットを設定します。
EF DSCP(101110)のパケットを設定します。

set-tos

ToS(Type of Service)値を設定します。

tosvalue:

critical
flash
flash-override
immediate
internet
max-reliability
max-through-
put
min-delay
min-monetary-
cost
network
normal
priority

0 ~ 127:ToS 値を設定します。

重大の優先順位(80)のパケットを設定します。
フラッシュの優先順位(48)のパケットを設定します。
フラッシュ上書きの優先順位(64)のパケットを設定します。
即時の優先順位(32)のパケットを設定します。
インターネットワーク制御の優先順位(96)のパケットを設定します。
最大信頼性の ToS(2)のパケットを設定します。
最大スループットの ToS(4)のパケットを設定します。

最小遅延の ToS(8)のパケットを設定します。
最小の金銭的コストの ToS(1)のパケットを設定します。

ネットワーク制御の優先順位(112)のパケットを設定します。
通常の ToS(0)のパケットを設定します。
プライオリティの優先順位(16)のパケットを設定します。

cache-miss

キャッシュ ミス時にクライアントに送信された応答を送信します。

dscp server

アクション:IP の ToS/DSCP(Type of Service/Differentiated Services Code Point)を発信応答に設定します。

match-client

クライアントのオリジナルの ToS/DSCP 値を使用します。

enable

ルール処理を使用可能にします。

freshness-factor

アクション:ヒューリスティック モディファイアをキャッシングします。

exp_time

オブジェクトの経過時間を有効期限のパーセント値(0 ~ 100)で設定します。

insert-no-cache

アクション:no-cache ヘッダーを応答に挿入します。

no-auth

アクション:認証を行いません。

no-cache

アクション:オブジェクトをキャッシングしません。

no-proxy

アクション:アップストリーム プロキシを使用しません。

redirect

アクション:要求を再書き込み URL にリダイレクトします。

url

URL をリダイレクトします。

redirect-url-for-cdn

アクション:ACNS ネットワーク コンテンツに対する要求を別の URL にリダイレクトします。

refresh

アクション:オブジェクトを Web サーバで再検証します。

reset

アクション:TCP RST を実行します。

rewrite

アクション:オリジナルの要求を指定された URL で再書き込みし、キャッシュ ミス時にその再書き込みされた URL をフェッチします。

selective-cache

アクション:HTTP が許可したオブジェクトをキャッシングします。

use-dns-server

アクション:特定の DNS サーバを使用します。

hostname

DNS サーバのホスト名。

ip-address

DNS サーバの IP アドレス。

use-icap-service

アクション:特定の ICAP サーバを使用します。

service-name

ICAP サーバを介した要求の処理に使用するサービス名。

use-proxy

アクション:特定のアップストリーム プロキシを使用します。

hostname

特定のプロキシのホスト名。

ip-address

特定のプロキシの IP アドレス。

port

特定のプロキシのポート番号(1 ~ 65535)。

use-proxy-failover

アクション:発信プロキシを発信 HTTP プロキシ サーバにフェールオーバーさせます。

hostname

特定のプロキシのホスト名。

ip-address

特定のプロキシの IP アドレス。

port

特定のプロキシのポート番号(1 ~ 65535)。

use-server

アクション:特定のサーバを使用します。

hostname

特定のサーバのホスト名。

ip-address

特定のサーバの IP アドレス。

port

特定のサーバのポート番号(1 ~ 65535)。

domain

パターン タイプ:ドメイン名と一致する正規表現。

dn_regexp

ドメイン名と一致させる正規表現。

dst-ip

パターン タイプ:要求の宛先 IP アドレス。

d_ipaddress

要求の宛先 IP アドレス。

d_subnet

宛先 IP サブネット マスク。

dst-port

パターン タイプ:宛先ポート番号。

port

宛先ポート番号(1 ~ 65535)。

group-type

パターン タイプ:パターン リストを AND または OR のどちらのタイプにするかを指定します。

and

AND パターンをパターン リストに指定します。

or

OR パターンをパターン リストに指定します。

header-field

パターン タイプ:要求ヘッダー フィールド パターン。

referer

参照元(referer)要求ヘッダー。

ref_regexp

参照元(referer)要求ヘッダーと照合する正規表現。

request-line

要求メソッド ライン。

req_regexp

要求メソッド ラインと照合する正規表現。

user-agent

ユーザ エージェント要求ヘッダー。

ua_regexp

ユーザ エージェント(User Agent)要求ヘッダーと照合する正規表現。

header-field-sub

パターン タイプ:要求ヘッダー フィールド パターンと代替の置換パターン。

referer

参照元(referer)要求ヘッダー。

ref_regexp

参照元(referer)要求ヘッダーと照合する正規表現。

ref_sub

要求ヘッダーの正規表現の置換文字列。

request-line

要求メソッド ライン。

req_regexp

要求メソッド ラインと照合する正規表現。

req_sub

要求メソッド ラインの正規表現の置換文字列。

user-agent

ユーザ エージェント要求ヘッダー。

ua_regexp

ユーザ エージェント(User Agent)要求ヘッダーと照合する正規表現。

ua_sub

ユーザ エージェント(User Agent)要求ヘッダーの正規表現の置換文字列。

icap-attribute

パターン タイプ:ICAP サービスの属性と値のペア。

attribute

ICAP サービスの属性。

value

ICAP サービスに割り当てられる値。

mime-type

パターン タイプ:Content-Type(コンテンツ タイプ)HTTP ヘッダーと照合する MIME タイプ。

mt_regexp

コンテンツ タイプと照合する正規表現。

src-ip

パターン タイプ:要求の送信元 IP アドレス。

s_ipaddress

要求の送信元 IP アドレス。

s_subnet

送信元 IP サブネット マスク。

url-regex

パターン タイプ:URL のサブストリングと照合する正規表現。

url_regexp

URL ストリングと照合する正規表現。

url-regsub

パターン タイプ:URL および置換パターンと照合する正規表現を設定します。

url_regexp

URL ストリングと照合する正規表現。

url_sub

URL ストリング置換パターン。

CLI コマンドを使用したパターン リストの設定

パターン リストを新規に作成する手順は、次のとおりです。

 

目的
コマンド

ステップ 1

Rules Template を使用可能にします。

ContentEngine(config)# rule enable

ステップ 2

パターン リストを作成します。

ContentEngine(config)# rule pattern-list 1-100 pattern-type pattern

ステップ 3

Rules Template の設定を表示します。

ContentEngine# show rule pattern-list 1-100 pattern-type pattern

次の例では、 rule pattern-list コマンドを設定し、domain \.foo.com パターンを使用して URL 要求に .foo.com を含むドメインをすべてブロックするパターン リストを作成します。

ContentEngine(config)# rule pattern-list 10 domain foo.com
ContentEngine# show rule pattern-list 10 domain
Rules Template Configuration
----------------------------
Rule Processing Enabled
 
Pattern-Lists :
 
rule pattern-list 10 domain foo.com
ContentEngine#
 

CLI コマンドを使用した既存パターン リストへのパターンの追加

既存のパターン リストにパターンを新規に追加する手順は、次のとおりです。

 

目的
コマンド

ステップ 1

パターン リストにパターンを追加します。

ContentEngine(config)# rule pattern-list 1-100 pattern-type pattern

ステップ 2

Rules Template の設定を表示します。

ContentEngine# show rule pattern-list 1-100 pattern-type pattern

次の例では、 rule pattern-list コマンドを設定し、既存のパターン リストにパターンを追加します。これにより、dst-ip パターンを使用して宛て先 IP アドレス 172.16.25.25 上でまだ定義されていないアクションを実行できます。

ContentEngine(config)# rule pattern-list 10 dst-ip 172.16.25.25 255.255.255.0
ContentEngine# show rule pattern-list 10 all
Rules Template Configuration
----------------------------
Rule Processing Enabled
 
Pattern-Lists :
 
rule pattern-list 10 dst-ip 172.16.25.25 255.255.255.0
rule pattern-list 10 domain foo.com
ContentEngine#
 

CLI コマンドを使用した既存パターン リストへのアクションの関連付け

アクションを既存のパターン リストに関連付ける手順は、次のとおりです。

 

目的
コマンド

ステップ 1

既存パターン リストにアクションを関連付けます。

ContentEngine(config)# rule action action-type pattern-list 1-100 protocol {protocol-type | all }

ステップ 2

Rules Template の設定を表示します。

ContentEngine# show rule action action-type protocol {protocol-type | all }

次の例では、 rule action block コマンドを設定して、既存のパターン リストに関連付けます。

ContentEngine(config)# rule action block pattern-list 10 protocol all
ContentEngine# show rule action block
Rules Template Configuration
----------------------------
Rule Processing Enabled
 
Actions :
 
rule action block pattern-list 10 protocol all
ContentEngine#
 

CLI コマンドを使用したパターン リストで実行されるアクションの確認

Content Engine から送信された応答を検証して、特定のアクションがパターン リストで実行されたことを確認する手順は、次のとおりです。

 

目的
コマンド

ステップ 1

既存パターン リストにアクションを関連付けます。

ContentEngine(config)# rule action action-type pattern-list 1-100 protocol {protocol-type | all }

ステップ 2

アクションが新規に追加された後に Rules Template 設定を表示します。

ContentEngine# show rule action action-type protocol {protocol-type | all }

ステップ 3

アクションが実行された後にローカル Rules Template 設定統計情報を表示します。

ContentEngine# show statistics rule action action-type

次の例では、 rule action block コマンドを設定して、既存のパターン リストに関連付けます。ここでは、パターンとして yahoo.com ドメインをリストします。

ContentEngine(config)# rule action block pattern-list 10 protocol all
ContentEngine# show statistics rule action block
Rules Template Statistics
-------------------------
Rule hit count = 3 Rule:rule action block pattern-list 10 protocol all
ContentEngine#
 

この例では、yahoo.com への要求が 3 回拒否されています。

CLI 設定例

ここでは、ローカルに配置されている Content Engine におけるルールの設定例を記載します。


) 以降の例では、特に説明のある場合を除いて、すべてのアクションとパターンがすべてのプロトコルに適用されることを前提としています。


例 1

次の例では、 rule action block コマンドを使用して、 rule pattern-list コマンドで指定されているすべてのパターンをブロックします。

ContentEngine(config)# rule pattern-list 12 domain \.foo.com
ContentEngine(config)# rule action block pattern-list 12
ContentEngine(config)#
 

例 2

次の例では、*cgi-bin* ストリングを含む URL 要求と一致する要求をキャッシングしません。

ContentEngine(config)# rule pattern-list 13 url-regex \.*cgi-bin.*
ContentEngine(config)# rule action no-cache pattern-list 13
ContentEngine(config)#
 

例 3

上記の例のように、多くのアクションにはパラメータがありません。次の例のように、 use-server freshness-factor 、および use-proxy は例外です。

ContentEngine(config)# rule pattern-list 13 url-regex \.*cgi-bin.*
ContentEngine(config)# rule use-proxy foo.com 8080 pattern-list 13
ContentEngine(config)#
 

例 4

ルールを削除するには、ルール作成コマンドの前に no を指定します。

ContentEngine(config)# no rule use-proxy foo.com 8080 pattern-list 13
 

例 5

次の例では、MIME-type イメージの新鮮度係数を設定します。

ContentEngine(config)# rule pattern-list 13 mime-type image/.*
ContentEngine(config)# rule action freshness-factor 75 pattern-list 13
 

例 6

次の例では、既存のパターン リストへのパターン タイプの追加を拒否します。この例では、 url-regsub のパターン タイプは action freshness-factor コマンドと関連付けられません。

ContentEngine(config)# rule pattern-list 13 url-regsub http://old-domain-name http://new-domain-name
Configured Pattern type not valid for the associated action - freshness-factor
Following pattern-types are applicable for this action
src-ip
dst-ip
dst-port
mime-type
url-regex
domain
ContentEngine(config)#
 

例 7

ルールが実行するアクションは、 rule action コマンドで設定します。ユーザが指定する特定のパターンと照合するパターンは、 rule pattern コマンドで設定します。

次の例では、パターンを同じパターン リスト番号で設定し、そのパターン リストをアクションに適用することにより、どのようにパターンが AND 演算されるかを示しています。

ContentEngine(config)# rule action block pattern-list 1
 
ContentEngine(config)# rule pattern-list 1 url-regex yahoo
ContentEngine(config)# rule pattern-list 1 dst-port 80
 

例 8

アクションは特定のプロトコルまたは一連のプロトコルに適用できます。プロトコルが設定されていない場合、指定されているアクションが Content Engine を通過するすべてのトラフィックに対して実行されます。

同じ行に複数のパターンを入力できます。いずれかのパターンが着信 HTTP 要求と一致する場合、対応するアクションが実行されます。

ContentEngine(config)# rule pattern-list 1 domain \.foo.com ?
LINE <cr>
 
ContentEngine(config)# rule pattern-list 1 domain \.foo.com bar.com
 

例 9

次の例では、指定されている宛先 IP アドレス 10.1.1.1 への発信要求に対して ToS(Type of Service)値を minimize delay(最小遅延)に設定します。

ContentEngine(config)# rule action dscp server set-tos min-delay protocol all
 
ContentEngine(config)# rule pattern-list 2 dst-ip 10.1.1.1 255.255.255.255
 

例 10

次の例では、すべての発信要求に対して ToS 値を minimize delay(最小遅延)に設定します。

ContentEngine(config)# ip dscp server set-tos min-delay
 

例 11

次の例では、 ip コマンドを使用して、同じオブジェクトに対する以降のキャッシュ ヒット応答すべてに対して、オブジェクトの最初のフェッチ時にサーバが当初送信した ToS または DSCP 値を使用します。

ContentEngine(config)# ip dscp client cache-hit match-server
 
ContentEngine(config)# rule action no-cache pattern-list 3 protocol all
 
ContentEngine(config)# rule pattern-list 3 url-regex \.*cgi-bin.*
 
ContentEngine(config)# rule pattern-list 4 dst-ip 172.31.120.0 255.255.192.0
<cr>
 

例 12

上記の例のように、多くのアクションにはパラメータがありません。次の例のように、 use-proxy は例外です。

ContentEngine(config)# rule action use-proxy ?
 
Hostname or A.B.C.D. IP address of the specific proxy
 
ContentEngine(config)# rule action use-proxy CE.foo.com ?
 
<1-65535> Port number of the specific proxy
 
ContentEngine(config)# rule action use-proxy CE.foo.com 8080 ?
pattern-list Patternlist number
ContentEngine(config)# rule action use-proxy CE.foo.com 8080 pattern-list ?
<1-100> Pattern list number
ContentEngine(config)# rule action use-proxy CE.foo.com 8080 pattern-list 2 ?
protocol Protocol for which this rule should be matched
<cr>
ContentEngine(config)# rule pattern-list 2 ?
domain Regular expression to match with the domain name
dst-ip Destination IP address of the request
dst-port Destination port number
header-field Request header field pattern
header-field-sub Regular expression to match request header & replacement pattern
mime-type Regular expression to match with MIME type
src-ip Source IP address of the request
url-regex Regular expression to substring match with the URL
url-regsub Regular expression to match URL & replacement patter
ContentEngine(config)# rule pattern-list 2 url-regex ?
LINE Regular expression to substring match with the URL
ContentEngine(config)# rule pattern-list 2 url-regex .*\.jpg$ ?
LINE <cr>
ContentEngine(config)# rule pattern-list 2 url-regex .*\.jpg$ .*\.gif$ .*\.pdf$
 

例 13

rule コマンドの他のオプションは、上記の例と同様に機能します。

次の例のように、ルールを削除するには、ルール作成コマンドの前に no を指定します。

ContentEngine(config)# no rule action block pattern-list 2
 

例 14

次の例では、new-domain-nameに変更された old-domain-name に対する要求をリダイレクトします。

ContentEngine(config)# rule action redirect http://old-domain-name/ pattern-list 1 protocol http
 
ContentEngine(config)# rule pattern-list 1 url-regsub http://old-domain-name/ http://new-domain-name/
 

例 15

次の例では、要求を IETF サイトから、ローカルにミラーリングされるサイトにリダイレクトします。

ContentEngine(config)# rule action redirect http://www.ietf.org/rfc/(.*) pattern-list 2 protocol http
 

例 16

次の例では、要求 URL が http://www.ietf.org/rfc/rfc1111.txt である場合、Content Engine はその URL を http://wwwin-eng.cisco.com/RFC/RFC/rfc1111.txt として再書き込みし、Location ヘッダー内に再書き込みされた URL をもつ 302 Temporary Redirect 応答をクライアントに送ります。ブラウザは、再書き込みされた URL への要求を自動的に開始します。

ContentEngine(config)# rule pattern-list 2 url-regsub http://www.ietf.org/rfc/(.*) http://wwwin-eng.cisco.com/RFC/RFC/\1
 

例 17

次の例では、linux.org に対するすべての要求を、Content Engine が置かれている場所に近いインドにあるローカル サーバにリダイレクトします。

ContentEngine(config)# rule action redirect http://linux.org/(.*) pattern-list 3
protocol http
 

例 18

この例では、パターンが url-regsub の場合に 2 つの URL を照合します。アクションの設定に指定されている URL が正しくない場合、このルールの設定時に警告が表示されます。ヘッダー フィールド パターンが設定されている場合、アクションの URL が実行されます。

ContentEngine(config)# rule pattern-list 3 url-regsub http://linux.org/(.*) http://linux.org.in/\1
 

次の例では、要求を IETF サイトから、ローカルにミラーリングされるサイトに再書き込みします。

ContentEngine(config)# rule action rewrite pattern-list 5 protocol http
 
ContentEngine(config)# rule pattern-list 5 url-regsub http://www.ietf.org/rfc/.*
http://wwwin-eng.cisco.com/RFC/$1
 
ContentEngine(config)# rule action redirect-url-for-cdn pattern-list 1
 
ContentEngine(config)# rule pattern-list 1 url-regsub xyz abc
 
Configured Pattern type not valid for the associated action - redirect-url-for-cdn
Following pattern-types are applicable for this action
src-ip
url-regex
 
ContentEngine(config)# rule pattern-list 1 url-regex roti

URL に roti が含まれている場合、その要求は ACNS ネットワークに送信されます。要求が ACNS ネットワーク内でヒットする場合、ACNS ネットワークから配信されます。ヒットしなかった場合は、オリジン サーバからフェッチされます。

例 19

no-auth オプションは、特定のログイン、および LDAP、RADIUS、SSH、TACACS+ のような認証と許可の機能をバイパスするコンテンツ要求を許可します。

次の例では、src-ip 172.16.53.88 からの要求はすべて認証されません。

ContentEngine(config)# rule enable
 
ContentEngine(config)# rule action no-auth pattern-list 1 protocol all
ContentEngine(config)# rule pattern-list 1 src-ip 172.16.53.88 255.255.255.255
 

次の例では、dst-ip 172.22.73.34 への要求はすべて認証されません。

ContentEngine(config)# rule action no-auth pattern-list 2 protocol all
ContentEngine(config)# rule pattern-list 2 dst-ip 172.22.73.34 255.255.255.255
 

次の例では、宛先ポート 9090 をもつ要求はすべて認証されません。

ContentEngine(config)# rule action no-auth pattern-list 3 protocol all
ContentEngine(config)# rule pattern-list 3 dst-port 9090
 

次の例では、URL に「cgi-bin」をもつ要求はすべて認証されません。

ContentEngine(config)# rule action no-auth pattern-list 4 protocol all
ContentEngine(config)# rule pattern-list 4 url-regex .*cgi-bin.*
 

次の例では、ドメインに「cisco.com」をもつ要求はすべて認証されません(たとえば、 roti.cisco.com または badal.cisco.com に対する要求は、Content Engine の認証から除外されます)。

ContentEngine(config)# rule action no-auth pattern-list 5 protocol all
ContentEngine(config)# rule pattern-list 5 domain cisco.com