Table Of Contents

Configuring the Rules Template

Rules Template Overview

Understanding Actions and Patterns

List of Rule Patterns

List of Rule Actions

Rules Template Processing Considerations

Execution Order of Rule Actions

Execution Order of Rule Patterns

Configuring the Rules Template

Enabling Rules Processing

Configuring Rules for a Locally Deployed Content Engine

Configuring a Pattern List

Adding a Pattern to an Existing Pattern List

Associating an Action with an Existing Pattern List

Verifying an Action Performed on a Pattern List

Configuration Examples

Configuring the Rules Template

---

This chapter describes how to configure the Rules Template for a locally deployed Content Engine. The Rules Template specifies the rules by which the Content Engine filters HTTP, HTTPS, MMS, and RTSP traffic. These configured rules might rewrite certain headers, redirect the request, or otherwise manipulate the request.

This chapter contains the following sections:

•Rules Template Overview

•Understanding Actions and Patterns

---

Note For complete syntax and usage information for the CLI commands used in this chapter, refer to the Cisco ACNS Software Command Reference, Release 5.1.

---

Rules Template Overview

The Rules Template feature allows you to specify a set of rules, each clearly identified by an action and a pattern. This feature allows you to configure a locally deployed Content Engine to use specific rules to filter HTTP, HTTPS, MMS, and RTSP traffic.

If you have enabled rules processing on a Content Engine (enabled the Rules Template feature on the Content Engine and configured rules for the Content Engine), the Content Engine checks every incoming request to determine if a rule pattern matches the requested content. If a rule pattern matches the given request, the Content Engine uses the specified action (policy) to handle this incoming traffic.

The Content Engine can match incoming requests against the following:

•Regular expressions symbolizing domain names

•Source IP addresses and network masks

•Destination IP addresses and network masks

•Destination port numbers

•MIME types

•Regular expressions symbolizing a URL

Policies (actions) that the Content Engine can apply to incoming requests include:

•Allow a request to be completed

•Append the username to the request headers

•Block the request (MMS and RTSP)

•Override the HTTP response header and caching the object

•Cache the object depending on the HTTP response header

•Bypass authentication for the request (MMS and RTSP)

•Reset the request

•Use a specific object freshness calculation factor

•Do not caching an object

•Bypass an upstream proxy for the request

•Redirect the request to a different URL (RTSP also)

•Revalidate the object with the origin server

•Rewrite the URL (MMS, RTSP also)

•Use a specific ICAP server

•Use a specific upstream proxy

•Use a specific server for the request

•Set ToS or DSCP in the response sent to the client

•Set ToS or DSCP in the response sent to the server

---

Note The Rules Template feature is mostly applicable to the HTTP, FTP, and HTTPS protocols. Policies that support streaming media object protocols such as MMS and RTSP, in addition to HTTP, FTP, and HTTPS, are indicated above.

---

Understanding Actions and Patterns

A rule is specified by a pattern and an action.

•A pattern defines the limits of an incoming request; for instance, a pattern may specify that the source IP address fall in the subnet range 172.16.*.*.

When defining a pattern, you specify the following information:

–The pattern type (for example, "src-ip" for source IP address)

–The pattern value (for example, "172.16.*.*" to indicate that the source IP address must fall within this subnet range)

–The number of the pattern list that this pattern is to be added to (for example, pattern list 10).

For a complete list of supported patterns, see Table 14-1.

•An action is performed on an incoming request if the request matches the specified pattern. An action is something that the Content Engine performs when processing a request, for instance, blocking the request, using an alternative proxy, and so forth. For a complete list of supported actions, see Table 14-2.

Rules can be dynamically added, displayed, or deleted from the Content Engine. The rules are preserved across reboots because they are written into persistent storage such as NVRAM using the appropriate Content Engine CLI commands or the GUI. Only the system resources limit the number of rules that the Content Engine can support. Because rules consume resources, the more rules there are defined, the more Content Engine performance may be affected.

You can use the Content Engine CLI or the GUI (as shown in Figure 14-1) to specify a pattern and the corresponding action.

Figure 14-1 Rules Template Window

---

Note To access the Rules Template window, choose System > Rules Templates from the Content Engine GUI. To view detailed information about how to use this window to configure the Rules Template, click the HELP button.

---

The rule pattern-list command allows you to create a pattern list and add specific patterns to that pattern list. After defining one or more pattern lists, you can use the rule action command to associate specific actions to a defined pattern list. The following example shows how patterns are ANDed by configuring patterns with the same pattern list number and applying that pattern list to an action.

ContentEngine(config)# rule pattern-list 1 url-regex yahoo

ContentEngine(config)# rule pattern-list 1 dst-port 80

ContentEngine(config)# rule action block pattern-list 1 

The CLI method is used throughout the rest of this chapter to illustrate how to configure the Rules Template on a locally deployed Content Engine. For more information about how to use the Content Engine CLI to configure the Rules Template, see the "Configuring the Rules Template" section.

List of Rule Patterns

Table 14-1 describes the types of rule patterns that you can add to a pattern list.

Table 14-1 Supported Types of Patterns 

Pattern	Description
domain	Matches the domain name in the URL or the Host header against a regular expression. For example, ".*ibm.*" matches any domain name that contains the "ibm" substring. "\.foo\.com$" matches any domain name that ends with the ".foo.com" substring. Note that in regular expression syntax, the dollar sign "$" metacharacter directs that a match is made only when the pattern is found at the end of a line.
dst-ip	Matches the request's destination IP address and netmask. Specify an IP address and a netmask. In proxy mode, the Content Engine does a DNS lookup to resolve the destination IP address of the HTTP request, making the response time longer, and possibly negating the benefit of setting a dst-ip rule. When an outgoing proxy is configured, cache miss requests are forwarded by the Content Engine to the outgoing proxy without examination of the destination server IP address, making the dst-ip rule unenforceable on the first Content Engine.
dst-port	Matches the request's destination port number. Specify a port number.
group-type	Specifies whether the pattern list is an AND or OR type.
ICAP-attribute	Specifies the attribute and value pair of the ICAP service.
mime-type	Matches the MIME type of the response. Specify a MIME type string, for example, "image/gif," as defined in RFC 2046 (http://www.faqs.org/rfcs/rfc2046.html). The administrator can specify a substring, for example, "java" and have it apply to all MIME types with the "java" substring, such as "application/x-javascript."
src-ip	Matches the request's source IP address and netmask. Specify an IP address and a netmask.
URL-regex	Matches the URL against a regular expression. The match is case insensitive. Specify a regular expression whose syntax can be found at the following URL: http://yenta.www.media.mit.edu/projects/Yenta/Releases/Documentation/regex-0.12/.
header-field	Requests header field pattern. Request header field patterns referer, request-line, and user-agent are supported for the block, reset, redirect, and rewrite actions. The referer pattern is matched against the Referer header in the request, the request-line pattern is matched against the first line of the request, and the user-agent pattern is matched against the User-Agent header in the request.
header-field-sub	Requests header field pattern and substitute replacement pattern.
URL-regsub	For the rewrite and redirect actions, matches the URL against a regular expression to form a new URL per pattern substitution specification. The match is case insensitive. The valid substitution index range is from 1 to 9.

For information about how to use the rule global configuration command to specify patterns for a locally deployed Content Engine, see the "Configuring Rules for a Locally Deployed Content Engine" procedure.

List of Rule Actions

Table 14-2 describes the types of actions that you can associate with a defined pattern list.

---

Note ACNS 5.1 software supports up to 520 actions to be configured.

---

Table 14-2 Supported Types of Actions 

Action	Description
allow	Allows the incoming request.
append-username-header	Appends the username-header on a cache miss.
block	Blocks the incoming request.
cache-non-cacheable	Overrides the HTTP response headers and caches the objects.
cache-only	Caches objects depending on the HTTP response headers. Caches this object only if it is a match and is allowed to be cached by HTTP. If one or more rules specify this action, an object is cached if and only if it matches at least one of the cache-only rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check. If the object does not match any of the cache-only rules, the object is not cached.
DSCP client	Configures IP Type of Service/differentiated services code point (ToS/DSCP) field responses for the client. Setting the ToS or DSCP is called packet marking, allowing you to partition network data into multiple priority levels or types of service.
DSCP server	Configures the IP ToS or DSCP code point field for requests to the origin server.
freshness-factor	Determines the Time To Live (TTL) if the request URL matches a specified regular expression. The refresh configuration takes priority over the freshness-factor configurations.
insert-no-cache	Inserts a no-cache header to the response.
no-auth	Does not authenticate.
no-cache	Does not cache this object. If both the no-cache and selective-cache actions are matched, no-cache takes precedence.
no-proxy	For a cache miss, the server is contacted directly rather than using the configured upstream proxy.
redirect-url-for-cdn	Redirects the original request to an alternative URL for ACNS network content.
redirect	Redirects the original request to the specified URL. Redirect is relevant to a RADIUS server only if a RADIUS server has been configured for redirect.
refresh	For a cache hit, forces an object freshness check with the server.
seset	Issues a TCP RST. This reset request in useful when you are resetting Code Red or Nimda virus requests.
rewrite	Rewrites the original request as a specified URL. The Content Engine searches for the rewritten URL in the cache, and then on a cache miss, fetches the rewritten URL and returns the object transparently to the client. It is preferable to use a redirect rule rather than rewrite because of possible performance impacts. The URL rewrite could change the domain name of the URL, which necessitates a DNS lookup to find the destination IP address of the new server to which the request must be sent. The original IP address derived from the WCCP redirect packet cannot be used.
selective-cache	Caches the object if permitted by HTTP.
use-dns-server	Uses the specified DNS server.
use-icap-service	Uses the specified ICAP server.
use-proxy	For a cache miss, uses the specified upstream proxy. Specify the upstream proxy IP address (or domain name) and port number.
use-proxy-failover	Supports failover capability.
use-server	Sends server-style HTTP requests from the Content Engine to the specified IP address and port on a cache miss.

For information about how to use the rule action global configuration command to associate an action with a specific pattern list, see the "Associating an Action with an Existing Pattern List" procedure.

Rules Template Processing Considerations

There is a predefined order of execution among the actions and the patterns. In other words, a group of rules with the same action will always be executed either before or after another group of rules with a different action. See the "Execution Order of Rule Actions" section for the order in which rule actions are executed. This order is not affected by the order in which the rules are entered using CLI commands.

Among rules of the same action, there is a predefined execution order among the rule patterns. This means that within a group of rules of the same action, one group of rules with the same pattern is always executed either before or after another group of rules with a different pattern. See the "Execution Order of Rule Patterns" section for the order in which rule patterns are executed. This order is not affected by the order in which the rules are entered using CLI commands.

Execution Order of Rule Actions

The order in which rule actions are executed is as follows:

1. Redirect-url-for-cdn—Before cache lookup

2. No-auth—Before authentication using RADIUS, LDAP, NTLM, or TACACS+

3. Use-icap-service—Before cache lookup using service from an ICAP server

4. Reset—Before cache lookup

5. Allow and Block—Before cache lookup (allow and block have the same priority)

6. Redirect—Before cache lookup

7. Rewrite—Before cache lookup

8. Refresh—On cache hit

9. Freshness-factor—On cache hit

10. Append-username-header—On cache miss

11. Use-server—On cache miss

12. No-proxy—On cache miss

13. Use-proxy-failover—On cache miss

14. Use-proxy—On cache miss

15. Use-dns-server—On cache miss

16. DSCP server—On cache miss

17. DSCP client—On cache hit

18. Insert-no-cache—On cache miss or cache hit (checked while variable headers are appended to the reply header)

19. No-cache—On cache miss

20. Cache-non-cacheable—For noncacheable object

21. Cache-only—On cache miss

---

Note The commands rule action no-proxy, rule action use-proxy hostname port-number failover, and rule action use-proxy commands take precedence over https proxy outgoing, http proxy outgoing, and ftp proxy outgoing commands.

---

During a request using the Rules Template CLI commands, rule actions 1 through 4 use the original URL request for pattern matches. After a URL rewrite (rule action 7), rule actions 8 through 21 use the transformed URL for rule executions.

Among the use-server, no-proxy, and use-proxy rules, the use-server rule is the first one to be checked. If it results in a rule miss, the no-proxy and use-proxy rules are executed in succession (the use-proxy rule is not checked if a no-proxy rule matches). If a rule is configured with a fully qualified domain name (FQDN) and a request is received with the partial domain name in transparent mode, the rule fails to be executed, because the FQDN is not in the request URL. In transparent mode, if a request is destined for a particular domain (for which a domain rule is configured) and does not contain the Host header, the rule pattern match fails. If both the no-proxy and use-proxy rules are matched, the no-proxy rule takes precedence.

The use-proxy-failover rule is similar to the use-proxy rule, except that if the connection attempt on the configured outgoing proxy fails, the requests fail over to the outgoing proxies configured with the HTTP proxy outgoing configuration. The rule requests use the http proxy outgoing origin-server option, if it is configured. The use-proxy-failover rule takes precedence over the use-proxy rule. If both the no-proxy and use-proxy-failover rules are matched, the no-proxy rule takes precedence. The HTTP failover does not apply if the destination is on the exclude list. When in transparent mode, the setting for the original proxy takes precedence.

The commands rule action reset, rule action block, rule action rewrite, and rule action redirect support the following additional patterns for Rules Template requests:

•Request-line—Matches the first line

•Referer—Matches the Referer header

•User-agent—Matches the User-Agent header

---

Note The Rules Template configuration takes precedence over the ip dscp command, and the url-filter command takes precedence over the rule command to the extent that even the rule no-block command is executed only if the url-filter command has not blocked the request.

---

Execution Order of Rule Patterns

The order in which rule patterns are executed is as follows:

1. Header-field.

2. Header-field-sub.

3. Other patterns: url-regsub, dst-port, src-ip, url-regex, domain, dst-ip, mime-type. However, there is no execution order based on the actions with which these patterns are executed.

---

Note Because the MIME type exists only in the response, only the actions freshness-factor, refresh, no-cache, and selective-cache apply to a rule of MIME type.

---

For example, in the following set of actions, the pattern-list 2 header-field pattern is executed first, and then the pattern-list 1 domain pattern. This order is followed because the rule action is taken only after the header information becomes available.

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

In the ANDing of patterns shown in the following example, there is no execution order based on the pattern entry.

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

In the preceding example, the destination port (dst-port) is checked first and then the header field is checked.

So the execution order is (without ANDing the rules):

1. Header-field.

2. Header-field-sub.

3. Other patterns: url-regsub, dst-port, src-ip, url-regex, domain, dst-ip, mime-type. There is no execution order based on the actions with which these are executed.

If a particular rule has a header field with a normal type of pattern, then there is no particular execution order.

A search for a rule match with the remaining pattern list is not performed if a match has already been found. For instance, if a match for the rule action block action command is found with a URL-regex request, then the remaining patterns domain, dst-ip, or MIME-type are not searched. Not all patterns are applicable for the actions rewrite and redirect. Only the URL-regex pattern search is applicable for the actions rewrite and redirect.

Rules are ORed together. Multiple rules may all match a request; then all actions are taken, with precedence set among conflicting actions based on the execution order of rule actions as defined in the "Execution Order of Rule Actions" section. A rule action command can contain more than one pattern as configured by the rule pattern-list command.

It is possible to circumvent some rules. For example, to circumvent a rule with the domain pattern, enter the web server IP address instead of the domain name in the browser. A rule may have unintended effects. For instance, a rule with the domain pattern specified as "ibm" that is intended to match "www.ibm.com" can also match domain names like "www.ribman.com."

---

Note A src-ip rule may not apply as intended to requests that are received by a Content Engine from another proxy or Content Engine, because the original client IP address is in an X-Forwarded-For header. This means that the original request's source IP address has been transparently replaced with the sending Content Engine's IP address on its way to the origin server.

---

If a rule pattern match occurs, then the rest of the patterns are not searched. If the server has already marked an object as noncacheable, the no-cache rules are not checked at all, because the server already recognizes that this object is not cached. Any no-cache rule checks are performed only for cacheable requests.

Configuring the Rules Template

When configuring rules on a locally deployed Content Engine, note the following guidelines:

•The number of actions is unlimited.

•The maximum number of pattern lists is 512.

•The maximum number of patterns per action is 128.

•A single pattern list can up to 128 patterns of a particular pattern type.

•To enter a question mark (?) character in a rule regular expression from the Content Engine CLI, use the escape character followed by a question mark (?) character. This prevents the CLI from displaying context-sensitive help.

•The Rules Template configuration takes precedence over the ip dscp command, and the url-filter command takes precedence over the rule command to the extent that even the rule no-block command is executed only if the url-filter command has not blocked the request.

•The rule action cache-non-cacheable command cannot cache objects if the objects are authenticated. That is, for authenticated objects, some origin servers do not send the Last-Modified or ETag entity headers. Revalidation of those authorized objects therefore cannot be performed by the Content Engine. Those authenticated objects are served only from the origin server. If the server does send the Last-Modified and ETag headers for authenticated objects, then they are properly revalidated and served from the cache.

•The no-auth rules result in the display of multiple authentication windows in the following scenario:

–When the main page (for example, index.htm) is excluded from proxy authentication by using no-auth rules

–When the user entry is not already included in the Content Engine authentication cache

–When the index.htm page contains objects belonging to different domains

To avoid multiple authentication windows, enter the hidden http avoid-multiple-auth-prompts command in global configuration mode. Check the configuration with the hidden show http avoid-multiple-auth-prompts command as shown the following example.

ContentEngine# show http avoid-multiple-auth-prompts

Avoiding multiple authentication prompts due to no-auth rules is enabled

The commands in the example are hidden because they are applicable only to this specific scenario.

---

Note You can configure a Rules Template through the CLI or Content Engine GUI (as shown in Figure 14-1).

---

•With ACNS 5.x software, you can set the ToS or DSCP values in IP packets based on a URL match, a file type, a domain, a destination IP address, a source IP address, or a destination port. You can set specific ToS or DSCP values for the following:

–Requests from the Content Engine to the server

–Responses to the client on a cache hit

–Responses to the client on a cache miss

The ToS or DSCP may be set based on any of the policies matching the src-ip s_ipaddress s_subnet, dst-ip d_ipaddress d_subnet, dst-port port, domain LINE, url-regex LINE, or mime-type LINE options. In addition, you can now configure global ToS or DSCP settings with the ip dscp command.

For more information about how to configure the Content Engine for rule processing, see the following sections:

•Enabling Rules Processing

•Configuring Rules for a Locally Deployed Content Engine

Enabling Rules Processing

By default, rules processing is disabled on a locally deployed Content Engine. To enable rules processing on a Content Engine, use the rule global configuration command, as follows:

ContentEngine(config)# rule enable

Configuring Rules for a Locally Deployed Content Engine

To set the rules by which the locally deployed Content Engine filters HTTP, HTTPS, MMS and RTSP traffic, use the rule global configuration command.

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

Table 14-3 describes the parameters for the rule command. If the rule command parameter is an action type or a pattern type, it is noted in Table 14-3.

---

Note Most actions do not have any parameters. Exceptions to this are the use-server, freshness-factor, and use-proxy actions.

---

Table 14-3 Parameters for the rule CLI Command 

Parameter	Action or Pattern Type	Description
action		Configures the action that the rule is to take if an incoming request matches the specified pattern.
action-type		Specifies the type of action (for example, allow) that is to be performed on an incoming request if the request matches the specified pattern.
allow	Action type	Allows the request.
pattern-list		Configures a pattern list.
list_num		Pattern list number (1-512).
protocol		Protocol for which this rule is to be matched.
all		Matches this rule with all applicable protocols for this action.
protocol-type		Specifies the protocol type (type of incoming traffic) for which this rule is to be matched.
http		Matches this rule for incoming HTTP traffic.
https		Matches this rule for incoming HTTPS traffic.
mms		Matches this rule for incoming MMS traffic.
rtsp		Matches this rule for incoming RTSP traffic.
append-username-header	Action type	Appends the username to the request headers.
block	Action type	Blocks the request.
cache-non-cacheable	Action type	Overrides HTTP response headers and caches this object.
ttl		Time To Live value of this object.
days		Time To Live units in days.
days		Time To Live value in days (1-1825).
hours		Time To Live units in hours.
hours		Time To Live value in hours (1-43800).
minutes		Time To Live units in minutes.
minutes		Time To Live value in minutes (1-2628000).
seconds		Time To Live units in seconds.
seconds		Time To Live value in seconds (1-157680000).
cache-only	Action type	Caches this object only.
dscp client	Action type	Configures IP Type of Service or differentiated services code point (ToS/DSCP) field responses for the client.
cache-hit		Sends responses to the client when a cache hit occurs.
match-server		Uses the original ToS or DSCP value of the server.
set-dscp		Configures differentiated services code point (DSCP) values.
dscpvalue: af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43		0-63—Sets DSCP values: Sets packets with AF11 DSCP (001010). Sets packets with AF12 DSCP (001100). Sets packets with AF13 DSCP (001110). Sets packets with AF21 DSCP (010010). Sets packets with AF22 DSCP (010100). Sets packets with AF23 DSCP (010110). Sets packets with AF31 DSCP (011010). Sets packets with AF32 DSCP (011100). Sets packets with AF33 DSCP (011110). Sets packets with AF41 DSCP (100010). Sets packets with AF42 DSCP (100100). Sets packets with AF43 DSCP (100110).
cs1 cs2 cs3 cs4 cs5 cs6 cs7 default ef		Sets packets with CS1 (precedence 1) DSCP (001000). Sets packets with CS2 (precedence 2) DSCP (010000). Sets packets with CS3 (precedence 3) DSCP (011000). Sets packets with CS4 (precedence 4) DSCP (100000). Sets packets with CS5 (precedence 5) DSCP (101000). Sets packets with CS6 (precedence 6) DSCP (110000). Sets packets with CS7 (precedence 7) DSCP (111000). Sets packets with default DSCP (000000). Sets packets with EF DSCP (101110).
set-tos		Configures type of service (ToS) values.
tosvalue: critical flash flash-override immediate internet max-reliability max-through- put min-delay min-monetary- cost network normal priority		0-127—Sets ToS value: Sets packets with critical precedence (80). Sets packets with flash precedence (48). Sets packets with flash override precedence (64). Sets packets with immediate precedence (32). Sets packets with internetwork control precedence (96). Sets packets with maximum reliable ToS (2). Sets packets with maximum throughput ToS (4). Sets packets with minimum delay ToS (8). Sets packets with minimum monetary cost ToS (1). Sets packets with network control precedence (112). Sets packets with normal ToS (0). Sets packets with priority precedence (16).
cache-miss		Sends responses are sent to the client when a cache miss occurs.
dscp server	Action type	Configures the TOS or DSCP services code point for outgoing responses.
match-client		Uses the original ToS or DSCP value of the client.
enable		Enables rules processing.
freshness-factor	Action type	Caches heuristic modifiers.
exp_time		Expiration time of object as a percentage of age (0-100).
insert-no-cache	Action type	Inserts a no-cache header in the response.
no-auth		Does not authenticate.
no-cache	Action type	Does not cache the object.
no-persistent-connection		Prevents the use of persistent connections.
all		Prevents the use of persistent connections to either clients or servers.
client-only		Prevents the use of persistent connections to clients.
server-only		Prevents the use of persistent connections to servers.
no-proxy	Action type	Does not use any upstream proxy.
redirect	Action type	Redirects the request to a rewritten URL.
url		Redirect URL.
redirect-url-for-cdn	Action type	Redirects the request to an alternative URL for ACNS network content.
refresh	Action type	Revalidates the object with the web server.
reset	Action type	Issues a TCP RST.
rewrite	Action type	Rewrites the original request as a specified URL and fetches the rewritten URL on a cache miss.
selective-cache	Action type	Caches this object if permitted by HTTP.
use-dns-server	Action type	Uses a specific DNS server.
hostname		Host name of the DNS server.
ip-address		IP address of the DNS server.
use-icap-service	Action type	Uses a specific ICAP server.
service-name		Service name used for handling the request through an ICAP server.
use-proxy	Action type	Makes use of a specific upstream proxy.
hostname		Host name of the specific proxy.
ip-address		IP address of the specific proxy.
port		Port number of the specific proxy (1-65535).
use-proxy-failover	Action type	Causes an outgoing proxy to fail over to outgoing HTTP proxy servers.
hostname		Host name of the specific proxy.
ip-address		IP address of the specific proxy.
port		Port number of the specific proxy (1-65535).
use-server	Action type	Makes use of a specific server.
use-xforward-clt-ip		Uses the client IP address in the x-forwarded header for filtering.
hostname		Host name of the specific server.
ip-address		IP address of the specific server.
port		Port number of the specific server (1-65535).
domain	Pattern type	Regular expression to match the domain name.
dn_regexp		Regular expression to be matched with the domain name.
dst-ip	Pattern type	Destination IP address of the request.
d_ipaddress		Destination IP address of the request.
d_subnet		Destination IP subnet mask.
dst-port	Pattern type	Destination port number.
port		Destination port number (1-65535).
group-type	Pattern type	Specifies whether the pattern list is an AND or OR type.
and		Specifies an AND pattern for the pattern list.
or		Specifies an OR pattern for the pattern list.
header-field	Pattern type	Request header field pattern.
referer		Referer request header.
ref_regexp		Regular expression to be matched with the referer request header.
request-line		Request method line.
req_regexp		Regular expression to be matched with the request method line.
user-agent		User agent request header.
ua_regexp		Regular expression to be matched with the User Agent request header.
header-field-sub	Pattern type	Requests header field pattern and substitutes replacement pattern.
referer		Referer request header.
ref_regexp		Regular expression to be matched with the referer request header.
ref_sub		Request header regular expression replacement string.
request-line		Request method line.
req_regexp		Regular expression to be matched with the request method line.
req_sub		Request method line regular expression replacement string.
user-agent		User Agent request header.
ua_regexp		Regular expression to be matched with the User Agent request header.
ua_sub		Regular expression replacement string for the User Agent request header.
icap-attribute	Pattern type	Attribute and value pair of the ICAP service.
attribute		Attribute of the ICAP service.
value		Value assigned to the ICAP service.
mime-type	Pattern type	MIME type to be matched with the Content-Type HTTP header.
mt_regexp		Regular expression to be matched with the content type.
src-ip	Pattern type	Source IP address of the request.
s_ipaddress		Source IP address of the request.
s_subnet		Source IP subnet mask.
url-regex	Pattern type	Regular expression to match a substring of the URL.
url_regexp		Regular expression to be matched with the URL string.
url-regsub	Pattern type	Sets a regular expression to match the URL and replacement pattern.
url_regexp		Regular expression to be matched with the URL string.
url_sub		URL string replacement pattern.

Configuring a Pattern List

Use the rule pattern-list global configuration command to create a pattern list on a locally deployed Content Engine, as follows:

ContentEngine(config)# rule pattern-list pattern-list list_num

where:

list_num is the pattern list number (1-512).

For example, create pattern list 10 as follows:

ContentEngine(config)# rule pattern-list 10

Adding a Pattern to an Existing Pattern List

To add a new pattern to an existing pattern list, follow these steps:

---

Step 1 Add a pattern to an existing pattern list, as follows:

ContentEngine(config)# rule pattern-list list_num pattern type pattern value

The following example shows how to add a pattern to pattern list 10. Using the dst-ip (destination IP address) pattern type, this pattern will perform an action yet to be defined on the destination IP address 172.16.25.25.

ContentEngine(config)# rule pattern-list 10 dst-ip 172.16.25.25 255.255.255.0

---

Note For a complete list of supported pattern types, see Table 14-1.

---

Step 2 Verify that the new pattern has been added to the specified pattern list.

The following example shows how to verify that the pattern created in Step 1 has been added to pattern list 10.

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

---

For information about how to associate an action with a pattern list, see the "Associating an Action with an Existing Pattern List" section.

Associating an Action with an Existing Pattern List

To associate an action with an existing pattern list, follow these steps:

---

Step 1 Associate an action with an existing pattern list:

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

Actions can be applied to specific protocols or to a set of protocols. If no protocol is configured, then the specified action will be taken for all the traffic that goes through the Content Engine. In the following example, the block action is associated with pattern list 10 for all protocols.

ContentEngine(config)# rule action block pattern-list 10 protocol all

---

Note Most actions do not have any parameters, as is the case with the block action. For more information about the parameters of the rule action command, see Table 14-3.

---

Step 2 Verify that the new action has been associated with the specified pattern list, as follows:

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

The following example shows how to verify that the block action has been associated with pattern list 10.

ContentEngine# show rule action block 

Rules Template Configuration

----------------------------

Rule Processing Enabled

Actions : 

rule action block pattern-list 10 protocol all 

ContentEngine#

---

Verifying an Action Performed on a Pattern List

To confirm that a certain action is performed on the specified pattern list, display the local Rules Template configuration statistics after an action has been performed.

ContentEngine# show statistics rule action action-type

In the following example, the rule action block command is configured and associated with an existing pattern list, which lists as its pattern the domain named "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#

In this example, the statistics ("Rule hit count") indicate that the request to yahoo.com was denied three times.

Configuration Examples

This section provides a set of configuration examples for configuring rules on a locally deployed Content Engine.

---

Note In the following examples, it is assumed that all actions and patterns apply to all protocols unless specifically stated.

---

Example 1

In the following example, the pattern type of "domain" is used to match domains that contain .foo.com. This pattern is added to pattern list 12.

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

The block action is associated with pattern list 12. This association will configure the Content Engine to block all URL requests to domains that contain .foo.com.

ContentEngine(config)# rule action block pattern-list 12 

ContentEngine(config)#

Multiple patterns can be added to the same pattern list. If any of them matches the incoming request, the corresponding action is taken. In the following example, the rule action block command (action) blocks all patterns that are specified in pattern list 12.

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

ContentEngine(config)# rule pattern-list 12 dst-ip 172.16.25.25 255.255.255.0

ContentEngine(config)# rule action block pattern-list 12

ContentEngine(config)#

Example 2

The following example configures the Content Engine to not cache any URL request that contains the *cgi-bin* string.

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

ContentEngine(config)# rule action no-cache pattern-list 13

ContentEngine(config)#

Example 3

As shown in the following examples, use no in front of a rule action command to delete rules.

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

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

Example 4

The following example sets the freshness factor for MIME-type images.

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

ContentEngine(config)# rule action freshness-factor 75 pattern-list 13

Example 5

The following example sets the ToS value to "minimum delay" for outbound requests to a specified destination IP address 10.1.1.1.

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 

Example 6

The following example sets the ToS value to "minimum delay" for all outbound requests.

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

Example 7

Using the ip command, the following example uses the ToS or DSCP value that was originally sent by the server (when the object was first fetched) for all future cache hit responses for the same object.

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>

Example 8

The following example redirects a request for old-domain-name that has been changed to new-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/

Example 9

The following example redirects requests from an IETF site to one that is locally mirrored.

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

Example 10

In the following example, if the request URL is http://www.ietf.org/rfc/rfc1111.txt, the Content Engine rewrites the URL as http://wwwin-eng.cisco.com/RFC/RFC/rfc1111.txt and sends a 302 Temporary Redirect response with the rewritten URL in the Location header to the client. The browser automatically initiates a request to the rewritten URL.

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

Example 11

The following example redirects all requests for linux.org to a local server in India that is closer to where the Content Engine is located.

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

protocol http 

Example 12

In this example, two URLs are to be matched if the pattern is url-regsub. If the URLs that are given in the action configuration are bogus, a warning is displayed during the configuration of this rule. The action URL is taken when the header field patterns are configured.

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

Example 13

The no-auth option permits specific login and content requests to bypass authentication and authorization features such as LDAP, RADIUS, SSH, or TACACS+.

In the following example, any requests from the source IP address (src-ip) of 172.16.53.88 are not authenticated.

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

In the following example, any requests to the destination IP address (dst-ip) of 172.22.73.34 are not authenticated.

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

In the following example, any requests with the destination port (dst-port) of 9090 are not authenticated.

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

ContentEngine(config)# rule pattern-list 3 dst-port 9090

In the following example, any requests with "cgi-bin" in the URL are not authenticated.

ContentEngine(config)# rule action no-auth pattern-list 4 protocol all

ContentEngine(config)# rule pattern-list 4 url-regex .*cgi-bin.*

In the following example, any requests with "cisco.com" as the domain are not authenticated. For example, requests for roti.cisco.com or badal.cisco.com are excluded from the Content Engine authentication.

ContentEngine(config)# rule action no-auth pattern-list 5 protocol all

ContentEngine(config)# rule pattern-list 5 domain cisco.com