Table Of Contents

Configuring the Rules Template on Standalone Content Engines

Rules Template Overview

Supported Rule Actions per Protocol

Understanding Actions and Patterns

Supported Rule Patterns

Supported Rule Actions

Example of no-url-filtering Action

Example of use-proxy Action

Example of use-server Action

Example of no-proxy Action

Supported Action and Pattern Combinations

Rules Template Processing Considerations

Rule Command for Converting Hostnames to IP Addresses

Execution Order of Rule Actions

Execution Order of Rule Patterns

Configuring the Rules Template

Enabling Rules Processing

Configuring Rules for Standalone Content Engines

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

Examples of Configuring Rules for Standalone Content Engines

Displaying Statistics for Configured Rules

Clearing Statistics for Configured Rules

Using Regular Expressions for Rules

Special Characters in Regular Expressions

Rules Caveats and Performance Guidelines

Pattern List Group-Type Caveats

Rules Configuration Guidelines for Best Performance

Configuring the Rules Template on Standalone Content Engines

---

This chapter describes how to configure the Rules Template on standalone Content Engines. The Rules Template specifies the rules by which the Content Engine filters HTTP, HTTPS, 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

•Configuring the Rules Template

•Displaying Statistics for Configured Rules

•Clearing Statistics for Configured Rules

•Using Regular Expressions for Rules

•Rules Caveats and Performance Guidelines

---

Note The term HTTP traffic is used to refer to requests over HTTP including HTTP, FTP-over-HTTP, and HTTPS-over-HTTP. The Rules Template is not supported for FTP native requests.

For complete syntax and usage information for the CLI commands used in this chapter, see the Cisco ACNS Software Command Reference, Release 5.5 publication.

---

Rules Template Overview

The Rules Template feature allows you to specify a set of rules, each clearly identified by a pattern and an action. This feature allows you to configure a standalone Content Engine to use specific rules to filter HTTP, HTTPS, and RTSP traffic. A common use of this feature is to configure a Content Engine to block the spread of Internet worms and viruses within an organization by checking whether a requested web page matches the pattern of a known Internet worm and if so then automatically blocking the request.

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 client 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.

There are two basic types of pattern comparisons: string comparisons and regular expressions. A string comparison requires an exact match. A regular expression comparison searches within a string for a substring match. The regular expression does not have to match the whole string and matching is not case sensitive. (See the "Using Regular Expressions for Rules" section for more information about regular expressions.)

The Content Engine can match incoming requests against the following:

•Patterns in the IP address of the client requesting the content (source IP address), including IP address, network mask, and port list

•Patterns in the IP address of the origin web or media server (destination IP addresses), including IP address, network mask, and port list

•Regular expression of the URL

•Regular expression of the domain portion of the URL

•MIME types of the web object that the client is requesting

•Regular expressions symbolizing domain names

•Headers that are sent in the request, including:

–"User-agent of the request," which indicates which client software is issuing the request

–"Referer," which indicates the web page from which the browser jumped to this link

–"Request Line," which indicates the request line itself

The Rules Template feature is mostly applicable to the HTTP, FTP, and HTTPS protocols. Policies that support streaming media object protocol such as RTSP, in addition to HTTP, FTP, and HTTPS, are indicated in Table 13-1.

Table 13-1 Rules Template Policies 

Policy (Action)	HTTP Requests	WMT Requests	RTSP Requests
Allow the request.	See Table 13-2.	*	*
Append the username to request headers.
Block the request.		*	*
Override the HTTP response header and cache the object.
Cache the object depending on the HTTP response header.
Bypass authentication for the request.		*	*
Use a specific object freshness calculation factor.
Reset the request.
Do not cache an object.
Bypass an upstream proxy for the request.
Redirect the request to a different URL.			*
Revalidate the object with the origin server.
Rewrite the URL.		*	*
No URL filtering for the specified HTTP and HTTPS requests.
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.

Supported Rule Actions per Protocol

Table 13-2 lists the rule actions per protocol that are supported by standalone Content Engines running the ACNS 5.3.1 software and later releases. An asterisk (*) indicates that a rule action is supported for that particular protocol. WCCP means transparent support. A "*1" indicates that a rule action is only supported for that particular protocol in the ACNS 5.1.5 software and later releases.

For the RTSP streaming protocol, the redirect and the redirect_url_for_cdn rule actions are supported for RTSP requests from RealMedia players but are not supported for WMT. Consequently, these two rule actions are not supported for RTSP requests from Windows Media players. For example, Windows Media Services 9 (WMS 9) supports the block, reset, rewrite, and allow rule actions for RTSP requests, but does not support the redirect and redirect_url_for cdn rule actions for RTSP requests.

Table 13-2 Matrix of Supported Rule Actions Per Protocol

Rule Actions	Protocol
	HTTP- over- HTTP	FTP- over- HTTP	HTTPS- over- HTTP	HTTP WCCP	FTP- WCCP (Native FTP)	HTTPS-WCCP	HTTPS-WCCP (tunneled, only available ACNS 5.1.5 Software or later)	RTSP
allow	*	*	*	*		*	No rule shall apply here.	*
append- username- header	*			*		*
block	*	*	*	*		*		*
cache-cookie	*			*		*
cache-non- cacheable	*			*		*
cache-only	*			*		*
dscp	*	*		*		*
freshness- factor	*			*		*
insert-no-cache	*	*		*		*
no-auth	*	*		*		*
no-cache	*	*		*		*
no-persistent- connection	*					*
no-proxy	*	*		*
no-url- filtering	*		*	*		*
redirect	*	*		*		*1		*
redirect-url- for-cdn	*							*
refresh	*	*		*		*
reset	*	*		*		*		*
rewrite	*			*		*1		*
use-dns-server	*			*
use-icap- service	*
use-proxy	*	*		*
use-server	*			*		*1
use-xforward- clt-ip	*					*

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 the 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 to which this pattern should be added (A pattern list is a container list of patterns that is identified by a pattern list number, for example, pattern list 10)

For a complete list of supported patterns, see Table 13-3.

•An action is the policy that is applied to 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 13-4.

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. Because rules consume resources, the more rules there are defined, the more Content Engine performance may be affected. For information about the limitation on the number of rules that can be configured on a Content Engine, see the "Configuring the Rules Template" section.

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

Figure 13-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 global configuration command allows you to create a pattern list and add specific patterns to that pattern list. The patterns within the pattern list can be ANDed or ORed together. After defining one or more pattern lists, you can use the rule action global configuration command to associate specific actions with a defined pattern list. The following example shows how patterns are ANDed by configuring different 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 standalone 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.

Supported Rule Patterns

In the ACNS 5.1 software release, three new rule patterns were added (groupname, username, and groupname-regex). These new rule patterns support access control policies that are based on the group name and username of the authenticated NTLM and LDAP users. Group name-based rules apply to users who have been authenticated through NTLM and LDAP. Username-based rules apply to users who are authenticated through LDAP, NTLM, RADIUS, and TACACS+ (request authentication methods that involve a username for authentication).

The following example shows how to enable rule processing on the Content Engine (using the rule enable global configuration command) and then configure the Content Engine to block all end users in the Engineering group from downloading FTP URLs (FTP requests from a client browser) that contain the expression "java":

ContentEngine(config)# rule enable

ContentEngine(config)# rule pattern-list 1 group-type and

ContentEngine(config)# rule pattern-list 1 groupname Engineering

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

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

---

Note Authorization through group name-based and username-based rules occurs only after HTTP request authentication and group-based access list authorization have occurred. If the configuration in the Rules Template and the access list match, the access list takes precedence.

---

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

Table 13-3 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. In regular expression syntax, the dollar sign "$" metacharacter directs that a match be made only when the pattern is found at the end of a line. (See the "Using Regular Expressions for Rules" section for more information about regular expressions.) Tip This rule pattern can be circumvented by users entering URLs with IP addresses instead of domain names.
dst-ip	Matches the request's destination IP address and netmask against the IP address and netmask specified in the rule. For example, the following command: CE(config)# rule pattern-list 2 dst-ip 10.255.0.11 255.255.255.255 matches any transparent mode request destination IP address or the DNS-resolved IP address of the domain from the proxy mode URL. This example matches a specific host, but by modifying the mask, you can match entire subnets or groups of IP addresses. Tip To test this pattern in proxy mode requires that the Content Engine perform a DNS lookup, which can have an impact on performance.
dst-port	Matches the request's destination port number against the port number specified in the rule. For example, the following command: CE(config)# rule pattern-list 3 dst-port 8083 matches any request destined for TCP port 8083. In proxy mode, this pattern matches the port from the request URL. In transparent mode, this pattern matches the TCP destination port.
groupname	Matches the group name of the end user (the web client that is requesting content), who was authenticated through LDAP or NTLM, against the group name specified in the rule. For example, specify the group name Engineering for pattern list 1, as follows: ContentEngine(config)# rule pattern-list 1 groupname Engineering This pattern can be applied only to request authentication for users who have been authenticated through LDAP or NTLM. This pattern supports exact string comparison and is case insensitive. The maximum length of the group name is 129 characters. Valid characters are an underscore and alphanumeric characters and special characters that are accepted by Active Directory. If the groupname configuration in the Rules Template and the group name-based access list match, then the access list takes precedence. Tip If you intend to use the groupname pattern, make sure that you set the correct number of maximum group entries in the authentication group cache (the http authentication cache max-group-entries number global configuration command). This number should correspond to the maximum number of groups that could be returned during authorization queries (for example, the total number of groups defined on the AAA server.) The number can be from 500 to 12000. The number of entries in the authentication group cache is dependent on the physical resources available on the Content Engine.
groupname- regex	Matches the group name of the end user (the web client that is requesting content) against the regular expression specified in the rule. The maximum length of the group name is 255 characters. For example, the following command: ContentEngine(config)# rule pattern-list 5 groupname-regex ING matches request-authenticated users who are members of any group that contains "ING" in its name. In this example, "ACCOUNTING" and "MARKETING" will be matched, but not "CORPORATE". This rule pattern requires that NTLM or LDAP request authentication is configured and that when a user authenticates, a group name associated with that user is returned to the Content Engine. You can specify multiple groups by using the bar symbol (|) to delimit the string.
group-type	Specifies whether the pattern list is an AND or OR type. This parameter is not actually a pattern, but it defines how to handle multiple patterns in the pattern list. If the group-type is OR, then the action will be performed if any pattern in the list is matched. If the group-type is AND, then the action will be performed only if all the patterns in the list are matched. Pattern lists with multiple patterns default to the OR group-type.
header-field	Request header field pattern. Request header field patterns referer, request-line, and user-agent are supported for the block, reset, redirect, and rewrite actions. The header-field referer pattern is a regular expression comparison against the Referer HTTP header in the request. For example, the following command: CE(config)# rule pattern-list 6 header-field referer cisco matches any HTTP request that has the pattern "cisco" anywhere in the Referer header line. The header-field request-line pattern is a regular expression comparison against the request line of the request. For example, the following command: CE(config)# rule pattern-list 6 header-field request-line HEAD matches any request that contains the pattern "HEAD" in the request line. The header-field user-agent pattern is a regular expression comparison against the User-Agent header in the request. For example, the following command: CE(config)# rule pattern-list 6 header-field user-agent layer matches any request where the User-Agent header line contains the string "layer". For instance, the rule pattern in this example will match "NSPlayer".
header-field- sub	Matches the pattern in the request header and replaces the text. This pattern contains arguments for referer, request-line, and user-agent. The header-field-sub referer pattern is a regular expression comparison against the Referer HTTP header that also replaces Referer HTTP header text. For example, the following command: CE(config)# rule pattern-list 9 header-field-sub referer yahoo google matches any Referer HTTP header that contains the string "yahoo" and replaces it with "google". The header-field-sub request-line pattern is a regular expression comparison against the request line that also replaces HTTP request line text. For example, the following command: CE(config)# rule pattern-list 10 header-field-sub request-line yahoo google matches any HTTP request line that contains the string "yahoo" and replaces it with "google". The header-field-sub user-agent pattern is a regular expression comparison against the User-Agent header that also replaces User-Agent header text. For example, the following command: CE(config)# rule pattern-list 11 header-field-sub user-agent Mozilla NoZilla matches any request with a User-Agent header that contains the string "Mozilla" and replaces it with "NoZilla".
icap-service- name	Specifies the name of the ICAP service that should be used.
mime-type	Matches the MIME type of the response from the origin server against the MIME type string specified in the rule. (For an explanation of mime-type, see RFC 2046 at http://www.faqs.org/rfcs/rfc2046.html.) For example, the following command: CE(config)# rule pattern-list 12 mime-type java matches any MIME type that contains the substring "java", such as application/x-javascript.
src-ip	Matches the request's source IP address and netmask against the IP address and a netmask specified in the rule. Tip If this rule is configured on an outgoing proxy, requests will be sourced from a subordinate proxy IP address. For example, the following command: CE (config)# rule pattern-list 13 src-ip 10.255.11.128 255.255.255.192 matches requests that come from any client on the 10.255.11.128 subnet. It will not match requests from clients on the 10.255.11.64 or 10.255.11.192 subnets.
username	Matches the username of the end user (the web client that is requesting content), who was authenticated through LDAP, NTLM, RADIUS, or TACACS+, against the username or usernames specified in the rule. The maximum length of username is 129 characters for LDAP, RADIUS, or TACACS+ authentication. Valid characters for the username are alphanumeric characters (a-z, A-Z, 0-9) and the following special characters: ! @ # $ % ^ & ( ) - _ { } . ~ ` However, the username cannot contain the following special characters: \ + = : ; ? < > , This pattern supports exact string comparison and is case insensitive. Specify multiple usernames in the same line for the same pattern list by using a comma-delimited string, as shown in the following example: ContentEngine(config)# rule pattern-list 1 username jdoe8,dsmith7,jsmith50 By default, the match does not consider the domain name and matches only the username. To include the domain name as well as the username in the match, specify domainname\username,as shown in the following example: ContentEngine(config)# rule pattern-list 1 username cisco\jdoe8 For NTLM authentication, the domain\username:password:NTLM string must be 50 characters or less. If this string is greater than 50 characters, the domain name is truncated, and the rule username pattern is not matched. An error message is generated in the system log in this situation. To match all users in a particular domain, enter: ContentEngine(config)# rule pattern-list 1 username domain domainname\* domainname is the name of the domain (for example, cisco).
URL-regex	Matches the URL against the regular expression specified in the rule. The match is case insensitive. For example, the following command: CE(config)# rule pattern-list 14 url-regex cgi-bin matches any URL that contains the string "cgi-bin". Tip If the request was made in transparent mode, a proxy mode URL is constructed before the comparison is made.
URL-regsub	For the rewrite and redirect actions, matches the URL against a regular expression and forms a new URL in accordance with the pattern specified. For example, the following command: CE(config)# rule pattern-list 15 url-regsub yahoo google matches any URL that contains the string "yahoo" and replaces it with "google". 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 standalone Content Engine, see the "Configuring Rules for Standalone Content Engines" section.

Supported Rule Actions

To display a list of supported rule actions, enter the rule action ? global configuration command.

ContentEngine(config)# rule action ?

  allow                     Allow the request

  append-username-header    Append the username in the header to the request

                            sent to the server

  block                     Block

  cache-cookie              Cache request containing Cookies

  cache-non-cacheable       Cache this object (Overriding HTTP response headers)

  cache-only                Cache this object only

  dscp                      Set IP TOS/DSCP (Differentiated Services) Field

  freshness-factor          Caching heuristic modifiers

  insert-no-cache           Insert no-cache headers to the response

  no-auth                   Do not authenticate

  no-cache                  Do not cache this object

  no-persistent-connection  Dont use persistent connection to all/client/server

                            connections

  no-proxy                  Do not use any upstream proxy

  no-url-filtering          Do not use URL filtering

  redirect                  Redirect request to rewritten URL

  redirect-url-for-cdn      Redirect alternate url for cdn content

  refresh                   Revalidate the object with the web server

  reset                     Issue a TCP RST

  rewrite                   Rewrite URL and fetch

  use-dns-server            Use a specific DNS server

  use-icap-service          Use a specific ICAP service

  use-proxy                 Use a specific upstream proxy

  use-server                Use a specific server

  use-xforward-clt-ip       Client IP in x-forwarded header will be used for

                            filtering.

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

Table 13-4 Supported Types of Actions 

Action	Description
allow	Allows incoming requests that match the pattern list. This rule action can be used in combination with reset or block actions to allow selective types of requests. Allow does not carry any meaning as a stadalone action.
append-username- header	Appends a Uname HTTP header to the request sent to the server. This action facilitates single sign-on if the web server recognizes the uname HTTP header. This rule action requires that RADIUS, NTLM, or LDAP request authentication be configured.
block	Blocks incoming requests that match the pattern list and allows all others.
cache-cookie	Caches requests with pattern matches that contain cookies. To be effective, this rule action also requires a corresponding rule action refresh if cookies are user-specific. Never configure this action when dynamic content is returned based on the cookie.
cache-non- cacheable	Overrides the HTTP response headers and caches objects that would not normally be cached.
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 client cache-hit	Cache hit responses to the DSCP client.
dscp client cache-miss	Cache miss responses to the DSCP client.
dscp server	Configures the IP ToS or DSCP code point field for requests to the origin server.
dscp server match-client	Uses the client's ToS or DSCP value.
dscp server set-dscp	Specifies the DSCP value. For a list of DSCP values, see Table 11-1.
dscp server set-tos	Specifies the Type of Service (ToS) value. For a list of ToS values, see Table 11-2.
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 configuration.
insert-no-cache	Inserts a no-cache header into the response.
no-auth	Does not authenticate. (The origin server might still require authentication.)
no-cache	Returns the requested object, but does not cache this object. If both the no-cache and selective-cache actions are matched, no-cache takes precedence.
no-persistent- connection all	Does not use a persistent connection for the request if the pattern is matched.
no-persistent- connection client	Does not use a persistent connection to client connections only.
no-persistent- connection server	Does not use a persistent connection to server connections only.
no-proxy	Does not use an outgoing proxy. (This action does not preclude the request going through a transparent proxy.) For a cache miss, the server is contacted directly rather than using the configured upstream proxy. For an example of how to use this action, see the "Example of no-proxy Action" section.
no-url-filtering	Bypasses URL filtering for HTTP and HTTPS requests. This feature is supported for local list URL filtering (good and bad site lists), as well as Websense, SmartFilter, or N2H2 URL filtering in the ACNS 5.2.3 software and later releases. For an example of how to use this action, see the "Example of no-url-filtering Action" section.
redirect-url-for-cdn	Redirects the original request to an alternative URL (specified in the manifest file using the alternateURL attribute) for ACNS network content. Note This rule action is only applicable for Content Engines that are registered with a Content Distribution Manager; it is not applicable to standalone Content Engines.
redirect	Redirects the original request to the specified URL. The redirection 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.
reset	Issues a TCP RST. This reset request is useful as a security precaution to block known virus request patterns, such as 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. Note Rules that are checked after the rewrite rule will still use the original URL rather than the rewritten URL.
selective-cache	Caches the object if permitted by HTTP.
use-dns-server	Uses the specified DNS server.
use-icap-service	Uses the specified ICAP service for the specified pattern list.
use-proxy	For a cache miss, uses the specified upstream proxy. Specify the upstream proxy IP address (or domain name) and port number. For an example of how to use this action, see the "Example of use-proxy Action" section. Note If failover is specified and the proxy connection fails, uses the globally configured http proxy outgoing host. If failover is not specified and the proxy connection fails, no proxy is used.
use-server	Sends server-style HTTP requests from the Content Engine to the specified IP address and port on a cache miss. For an example of how to use this action, see the "Example of use-server Action" section. Note The request from the client can be a proxy style or server style request.
use-xforward-clt-ip	Uses the client IP address from the X-Forwarded-For HTTP header for content filtering.

Example of no-url-filtering Action

This example shows how to use the no-url-filtering action to bypass URL filtering feature with Websense URL filtering.

Specify the rule action no-url-filtering command and then associate it with a specific pattern list (pattern list 100). Add the domain pattern type to pattern list 100 in order to configure the Content Engine to match requests that have foo.com as the domain. In this example, Websense URL filtering has already been configured and enabled on the Content Engine:

ContentEngine (config)# rule action no-url-filtering pattern-list 100

ContentEngine (config)# rule pattern-list 100 domain .*foo.com

ContentEngine (config)# rule enable

---

Note The no-url-filtering action supports the following rule patterns: src-ip, dst-ip, dst-port, domain, group-name, groupname-regex, header-field, url-regex, and username. Patterns can be ANDed or ORed by using the group-type pattern (for example, rule pattern-list 1 group-type and). The default is OR.

---

When the Content Engine receives an HTTP or HTTPS request that has foo.com as the domain, the rule action no-url-filtering rule is matched. Consequently, the Content Engine bypasses URL filtering for that particular request as shown in this partial output of the debug http proxy command:

Oct 28 12:25:12 Content Engine 3: Rule action no-url-filtering match 

- Bypassing urlfiltering 

If the rule action no-url-filtering rule is matched and SmartFilter URL filtering is being used instead of Websense URL filtering, the output of the debug http proxy command would be as follows:

Oct 28 12:25:12 Content Engine 3: Rule action no-url-filtering match 

- Bypassing SmartFilter processing

When the Content Engine receives an HTTP or HTTPS request for websites other than foo.com (for requests that have www.abc.com as the domain), the rule action no-url-filtering rule is not matched. Consequently, the Content Engine proceeds with Websense URL filtering for that particular request as shown in this partial output of the debug http proxy command:

Oct 28 12:28:06 Content Engine 3: Rule action no-url-filtering not hit - Proceed with 
urlfiltering 

If the rule action no-url-filtering rule is not matched and SmartFilter URL filtering is being used instead of Websense URL filtering, the output of the debug http proxy command would be as follows:

Oct 28 12:25:12 Content Engine 3: Rule action no-url-filtering not hit- Proceed with 
SmartFilter processing

To display statistics for the no-url-filtering action, enter the show statistics rule http action no-url-filtering EXEC command.

To display information about the no-url-filtering action, enter the show run and show rule all EXEC commands.

Example of use-proxy Action

This example shows a typical use of the use-proxy action.

The rule action use-proxy proxy pattern-list number global configuration command can be used to configure only one proxy for a particular pattern list. If you attempt to configure a second proxy for the same pattern list (for example, pattern list 1), you will receive an error message that indicates the rule entry already exists.

ContentEngine12 (config)# rule action use-proxy 10.16.0.0 8080 pattern-list 1

ContentEngine12 (config)# rule action use-proxy 10.77.157.42 8080 pattern-list 1

Rule entry is duplicate

Rule use-proxy exists with IP: 10.16.0.0.Please remove it and reconfigure

When rule action use-proxy is configured with "failover" qualifier, first it would try to connect to proxy configured in use-proxy, if it fails, it would fall back to outgoing proxy, configured through the cli "http proxy outgoing host <host> <port>"

If the use-proxy feature is configured without failover (for example, you have entered the rule action use-proxy 10.16.0.0 8080 pattern-list 1 command), the Content Engine will send the request to the use-proxy (the server with the IP address of 10.16.0.0). If the Content Engine does not obtain a response from the use-proxy, then it will send an error message to the client without failing over to the HTTP outgoing proxy.

If the use-proxy feature is configured with failover (for example, you have entered the rule action use-proxy 10.16.0.0 8080 failover pattern-list 1 command), the Content Engine will send the request to the use-proxy (for example, the server with the IP address of 10.16.0.0). If the Content Engines does not obtain a response from the use-proxy, then it fails over to the specified HTTP outgoing proxy (for example, the server that has been specified as the primary outgoing host with the http proxy outgoing host 10.77.157.42 8080 primary global configuration command). The following example shows a sample configuration in which the use-proxy feature is configured with failover:

ContentEngine 12# show run

Sep 1 06:42:32 ContentEngine 12-admin-shell: %CE-PARSER-6-350232: CLI_LOG shell_parser_log: sh run

! ACNS version 5.4.0

!

!

hostname ContentEngine 12

!

http client-no-cache-request ignore

http proxy incoming 8080

http proxy outgoing host 10.77.157.42 8080 primary

!

ftp-over-http proxy incoming 8080

!

!

< output cut >

!

rule enable

rule action use-proxy 10.16.0.0 8080 failover pattern-list 1

rule pattern-list 1 domain yahoo.com

!

<output cut >

Example of use-server Action

This example shows a typical use of the use-server action. For HTTP requests that match the specified criteria, if the Content Engine needs to contact the origin server (for example, if a cache miss occurs), the Content Engine does not go to the server indicated in the request to retrieve the requested object; instead, it uses a different destination server that is specified in the rule. This feature is primarily used for on-demand requests, and is typically used in reverse proxy deployments.

In this example, the Content Engine is a reverse proxy for www.abcbigcorp.com and is a proxy to the rest of the Internet. The IP address for the company's website (www.abcbigcorp.com) is actually the IP address of the Content Engine, and not the company's web site server. When the Content Engine receives the request http://www.abcbigcorp.com/main.html, its normal processing would be to obtain the IP address of www.abcbigcorp.com and send the request to that IP address. However, in this case, because the IP address of www.abcbigcorp.com is the IP address of the Content Engine, the administrator needs to prevent the Content Engine from sending the request to itself.

Consequently, the administrator of CE1 can configure the following rule that will instruct CE1 to send such requests (for example, cache misses) to the web server for www.abcbigcorp.com:

CE1(config)# rule use-server 1.2.3.4 80 domain www.abcbigcorp.com 

1.2.3.4 is the IP address of the web server for www.abcbigcorp.com.

---

Note This rule applies to HTTP processing only.

---

Example of no-proxy Action

The no-proxy action is applicable when the administrator of the Content Engine has configured an outgoing proxy server for the Content Engine. The no-proxy action states that for requests that match the criteria, if a connection with the origin server is needed (for example, because of a cache miss), the Content Engine should not use the specified proxy server to establish the connection with the origin server. This rule is useful if a company has a Content Engine (CE1) at the Internet gateway to cache all Internet content, and a Content Engine at each branch office (CE2, CE3, CE4). In this case, the administrator can configure CE2, CE3, and CE4 at the branch offices to use CE4 as their outgoing proxy server, but set up the no-proxy rule for requests for corporate internal content.

When CE2, CE3, and CE4 receive a client request and the requested content is not already stored in their local caches, they will process the request as follows:

•If the client request is for Internet content, then CE2, CE3, and CE4 should use CE1 at the Internet gateway instead of going to the origin server directly.

•If the client request is for corporate internal content, then CE2, CE3, and CE4 should establish a connection directly with the origin server instead of going to CE1.

For information about how to use the rule action global configuration command, see the "Associating an Action with an Existing Pattern List" section. For a list of supported action and pattern combinations, see Table 13-5 and Table 13-6. For a list of the supported rule actions per protocol, see Table 13-2.

Supported Action and Pattern Combinations

Not all actions support all patterns for request matching because some patterns do not make sense for some actions. See Table 13-5 and Table 13-6 for a list of supported action and pattern combinations.

An asterisk "*"indicates that a particular action and pattern combination is supported in the ACNS 5.2.1 software and later releases.

Table 13-5 Supported Action and Pattern Combinations for Standalone Content Engines—Part 1 

Action	Pattern
	domain	dst- ip	dst- port	header- field- referrer	header- field- req- line	header- field- user- agent	header- field- sub- referrer	header- field- sub- req- line	header- field- sub- user- agent	mime- type	src- ip	url- regex	url- regsub	groupname, username, groupname regex
allow	*	*	*	*	*	*					*	*		*
append- username header	*	*	*								*	*		*
block	*	*	*	*	*	*					*	*		*
cache- cookie	*	*								*		*		*
cache- non- cacheable	*	*								*		*
cache- only	*	*								*		*
dscp client	*	*	*							*	*	*
dscp server	*	*	*								*	*
freshness- factor	*	*	*							*	*	*
insert- no-cache	*	*										*
no-auth	*	*	*								*	*
no-cache	*	*	*							*	*	*

Table 13-6 Supported Action and Pattern Combinations for Standalone Content Engines—Part 2 

Action

Pattern

domain

dst- ip

dst- port

header- field- referrer

header- field- req- line

header- field- user- agent

header- field- sub- referrer

header- field- sub- req- line

header- field- sub- user- agent

mime- type

src- ip

url- regex

url- regsub

groupname, username, groupname regex

no- persistent- connection

*

*

*

*

*

*

*

no-proxy

*

*

*

*

*

no-url- filtering

*

*

*

*

*

*

*

*

*

redirect

*

*

*

*

refresh

*

*

*

*

*

*

reset

*

*

*

*

*

*

*

*

rewrite

*

*

*

*

selective- cache

*

*

*

*

*

*

use-dns- server

*

*

use-icap- service

*

*

*

*

*

*

*

*

use- proxy

*

*

*

*

*

*1

use- server

*

*

*

*

*

use- xforward clt-ip

*

*

*

*

*

*

*

1 The CLI help does not list these supported patterns for the use-proxy rule action (CSCsb63246).

Rules Template Processing Considerations

When there are multiple rules configured on a standalone Content Engine, the rules are executed in a particular order.

To understand the processing order of rules in ACNS 5.x, you must understand the following aspects of rule processing:

•There is a predefined order of execution among the defined actions. 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. This order is predefined and is not affected by the order in which the rules were entered.

•Among rules of the same action, there is a predefined order among the rules pattern. In other words, within the same action, one group of rules with the same pattern will always be executed either before or after another group of rules with a different pattern. This order is again predefined and not affected by the order in which the rules were entered.

•Among all rules of the same action, which are configured to a pattern list that contains the same type of patterns, the individual patterns are matched in the order that they were configured.

For example, if you specified the following rules, the Content Engine will first attempt to match the URLs that end with .asf:

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

ContentEngine(config)# rule pattern-list 1 url-regex .*\.asf$

ContentEngine(config)# rule pattern-list 1 url-regex .*\.avi$

ContentEngine(config)# rule pattern-list 1 url-regex .*\.wav$

ContentEngine(config)# rule pattern-list 1 url-regex .*\.wmv$

The Content Engine will then first attempt to match the URLs that end with .avi. After attempting to match the URLs that end with .avi, the Content Engine will attempt to match the URLs that end with .wav and then .wmv.

•When a new release of the ACNS software adds more rule actions and patterns (for example, the groupname, username, and groupname-regex patterns and the cache-cookie action were added in the ACNS 5.2.1 software), the order of processing among existing actions and patterns does not change.

For the order in which rule patterns are executed, see the "Execution Order of Rule Patterns" section. This order is not affected by the order in which the rules are entered using the Content Engine GUI or the CLI.

---

Tip In the ACNS 5.x software, if you enter the show rule EXEC command on a standalone Content Engine, the rules are displayed randomly. However, if you enter the show statistics rule EXEC command, the rules are displayed in the order in which the rule actions are executed. Consequently, you can use this command to see how a standalone Content Engine will process the rules that you define for it.

---

Rule Command for Converting Hostnames to IP Addresses

In the ACNS 5.3.1 software and earlier releases, the use_proxy rule action and the failover option in the use-proxy rule action perform hostname to IP address translation at the time of the CLI configuration. If the IP address for the specified hostname changes, the service rule would no longer function.

In the ACNS 5.3.3 software and later releases, the rule dns-resolve each-request global configuration command is available. When this CLI command is enabled, the caching process on the Content Engine resolves the hostname each time that it processes the request and matches the pattern for the use-proxy rule action and the failover option in the use-proxy rule action.

For the ACNS 5.3.3 software and later releases, the caching process uses the initially resolved IP (done at the time of the CLI configuration) for processing the use-proxy rule action and the failover option in the use-proxy rule action when the rule dns-resolve each-request CLI command is disabled. For instance, the following is an example of the CLI command syntax for the yahoo and abc websites upon configuration with the ACNS 5.3.3 software and later releases:

ContentEngine(config)# rule action use-proxy www.yahoo.com 8080 failover pattern-list 10 

ContentEngine(config)# rule action use-proxy www.abc.com 8090 pattern-list 20

In contrast, the following is an example of the CLI command syntax for the yahoo and abc websites upon configuration with the ACNS 5.3.1 software and earlier releases:

ContentEngine(config)# rule action use-proxy 66.94.230.42 8080 failover pattern-list 10 

ContentEngine(config)# rule action use-proxy 199.181.132.250 8090 pattern-list 20

Execution Order of Rule Actions

In the ACNS 5.2.3 software and later releases, the order in which the rule actions are executed is as follows:

1. Reset (if the pattern list contains a header-field pattern.)

2. Redirect-url-for-cdn (this action is only applicable for Content Engines that are registered with a Content Distribution Manager and is not applicable for standalone Content Engines)

3. No-auth (before authentication using RADIUS, LDAP, or NTLM)

4. Reset

5. Block / allow¹

6. Redirect (before cache lookup)

7. Rewrite (before cache lookup)

8. No-url-filtering

9. Refresh (after cache lookup, in the case of a cache hit)

10. Freshness-factor (after cache lookup, in the case of a cache hit)

11. Use-server

12. No-proxy

13. Use-proxy

14. Use-dns-server

15. ToS/DSCP server (ToS bits on the connection to the server)

16. ToS/DSCP client (ToS bits on the connection that the server uses to send a response to the client)

17. DSCP client cache-miss

18. DSCP client cache-hit

19. Insert-no-cache

20. No-cache

21. Cache-non-cacheable (when the response is received from the server)

22. Cache-only (when the response is received from the server)

23. Append-username-header

24. Use-icap-service

25. Use-xforward-clt-ip

26. No-persistent-connection

27. Cache-cookie

28. No-selective-cache

29. Allow

The reset, block, rewrite, and redirect rule actions support the following additional patterns: request-line, referer, and user-agent regular expressions. The request-line regular expression matches the first line of the request. The user-agent regular expression matches the User-Agent header value of the request. The referer regular expression matches the referer header value of the request.

In the following example, the Content Engine is configured to replace the string internal.domain.com in a request to the server named dummy:

ContentEngine(config)# rule rewrite header-field referer internal.domain.com dummy 

In the following example, if an empty string is given as a replacement pattern, the referer header is stripped. This rule states that for all requests with a referer header that indicates a corporate internal server in ABCBigCorp, strip the referer field so that the outside web server will not see the name of the corporate internal server. This is a useful practice for network security.

ContentEngine(config)# rule rewrite header-field referer internal.abcbigcorp.com "" 

Stripping of the referer header occurs in the user-agent pattern as well.

---

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

---

Among the use-server, no-proxy, and use-proxy rules, the use-server rule is the first one to be checked. If none of these rules match, the no-proxy and use-proxy rules are executed in succession (the use-proxy rule is not checked if there is a match with the no-proxy rule). 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. 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 execution order 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.

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 pattern-list 3 group-type 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

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

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.

Rules by default 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 global configuration command can contain more than one pattern as configured by the rule pattern-list global configuration 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 standalone Content Engine, remember the following important points:

•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.

•Authorization through group name-based and username-based rules occurs only after HTTP request authentication and group-based access control list (ACL) authorization have occurred. If the configuration in the Rules Template and the ACL match, ACL takes precedence.

•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 situation:

–When the main window (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 window 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 EXEC command as shown in 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 situation.

---

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

---

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

•Enabling Rules Processing

•Configuring Rules for Standalone Content Engines

Enabling Rules Processing

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

ContentEngine(config)# rule enable

Configuring Rules for Standalone Content Engines

To set the rules by which the standalone Content Engine filters HTTP, HTTPS, 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 13-7 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 13-7.

---

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

---

Table 13-7 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.
enable		Enables rules processing.
http		Matches incoming HTTP traffic against this rule.
https		Matches this rule for incoming HTTPS traffic.
rtsp		Matches incoming RTSP traffic against this rule.
append- username- header	Action type	Appends the username to the request headers.
block	Action type	Blocks the request.
cache-cookie	Action type	Caches requests that contain cookies.
groupname		Match string with the group name (for example, Engineering). This groupname-based rules policy can be applied only to request authentication for users who are authenticated through LDAP or NTLM.
groupname		String of group name.
username		Matches string against specified username. This username-based rules policy can be applied to any of the supported request authentication method that involves a username for authentication (for example, LDAP, NTLM, RADIUS, and TACACS+).
username		Username string (for example, jdoe8).
groupname- regex		Match regular expression with the group name.
groupname- regex		Regular expression to be matched with the group name.
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. For a list of DSCP values, see Table 11-1.
set-tos		Configures Type of Service (ToS) values. For a list of ToS values, see Table 11-2.
cache-miss		Sends responses 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. For an example of how to use this rule action, see the "Example of no-proxy Action" section.
no-url- filtering	Action type	Bypasses URL filtering for certain HTTP and HTTPS requests. This feature is supported for local list URL filtering (good and bad site lists), as well as Websense, SmartFilter, or N2H2 URL filtering in the ACNS 5.2.3 software and later releases. For an example of how to use this rule action, see the "Example of no-url-filtering Action" section.
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. This is applicable only for Content Engines that are registered with a Content Distribution Manager; it is not applicable for standalone Content Engines.
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		Hostname of the DNS server.
ip-address		IP address of the DNS server.
use-icap- service	Action type	Uses a specific ICAP server.
icap-service- name	Pattern type	Uses ICAP service name.
service name		Name of the ICAP service.
use-proxy	Action type	Makes use of a specific upstream proxy. For an example of how to use this rule action, see the "Example of use-proxy Action" section.
hostname		Hostname 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. For an example of how to use this rule action, see the "Example of use-server Action" section.
use-xforward- clt-ip		Uses the client IP address in the x-forwarded header for filtering.
hostname		Hostname 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. The default is OR.
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.
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	Sets use of the source IP address of the request.
s_ipaddress		Source IP address of the request.
s_subnet		Source IP subnet mask.
url-regex	Pattern type	Sets use of a regular expression to be matched against 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.

With the 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. You can also now configure global ToS or DSCP settings with the ip dscp command.

Configuring a Pattern List

To create a pattern list on a standalone Content Engine, use the rule pattern-list global configuration command as follows:

ContentEngine(config)# rule 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 on a standalone Content Engine, follow these steps:

---

Step 1 Add a pattern to an existing pattern list.

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 13-3.

---

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 next section, "Associating an Action with an Existing Pattern List."

Associating an Action with an Existing Pattern List

To associate an action with an existing pattern list on a standalone Content Engine, 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 global configuration command, see Table 13-7.

---

Step 2 Verify that the new action has been associated with the specified pattern list.

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.

Examples of Configuring Rules for Standalone Content Engines

This section provides a set of configuration examples for configuring rules on standalone Content Engines.

---

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

---

•To specify domains that contain .foo.com, use the domain pattern type and add this pattern to pattern list 12.

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

Associate the block action with pattern list 12 to configure the Content Engine to block all URL requests to domains that contain .foo.com.

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

Configure multiple patterns in the same pattern list (pattern list 12). If any of them matches the incoming request, the corresponding action is taken. In the following example, the rule action block global configuration 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

•Configure the Content Engine not to 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

•Use no in front of a rule action global configuration 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 

•Set the Content Engine 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

•Set the ToS value on the Content Engine to minimum delay for outbound requests to the 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 

•Set the ToS value on the Content Engine to minimum delay for all outbound requests.

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

•Configure the Content Engine to use 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

•Configure the Content Engine to redirect requests for old-domain-name that has been changed to new-domain-name to the 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/

•Configure the Content Engine to redirect 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

•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 

•Configure the Content Engine to redirect 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 

•The rule action no-auth global configuration command 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) 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

•If the ACNS 5.x software is configured for authentication and SmartFilter URL filtering, requests that are allowed to bypass authentication will also bypass the SmartFilter URL filter. Configure the Content Engine not to authenticate any requests to the destination IP address (dst-ip) of 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

•Configure the Content Engine not to authenticate any requests with the destination port (dst-port) of 9090.

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

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

•Configure the Content Engine not to authenticate any requests with cgi-bin in the URL.

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

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

•Configure the Content Engine not to authenticate any requests that have cisco.com as the domain. 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

Displaying Statistics for Configured Rules

To display statistics for the rules that are configured on a standalone Content Engine, use the show statistics rule EXEC commands. This command lists the rule actions in their execution order. The output also shows the number of times each action was applied (rule hit counts).

In the ACNS 5.3.1 software release, the options of the show statistics rule command were changed to enable you to display statistics for RTSP and WMT RTSP rules.

In the ACNS 5.2.x software and earlier releases, the command options for the show statistics rule command were as follows:

ContentEngine# show statistics rule ?

  all   Display statistics of all the Rules

  http  Display statistics of http/https/all Rules

  wmt   Display statistics of wmt Rules

In ACNS 5.5.1 software and later releases, the command options for the show statistics rule command are as follows:

ContentEngine# show statistics rule ?

  all           Display statistics of all the Rules

  http          Display statistics of http/https/wmt-http Rule Actions

  pattern-list  Display statistics of Rule Pattern lists

  rtsp          Display statistics of rtsp/wmt-rtsp Rule Actions

For example, enter the show statistics rule rtsp command to display statistics for RTSP rules (rules for RTSP requests from RealMedia players [the RTSP rules] and rules for RTSP requests from Windows Media 9 players [the WMT-RTSP rules]).

To display the total number of rule hit counts, enter the show statistics rule all EXEC command. To display statistics for a specific configured rule, enter the show statistics rule http action rule action name. For example, to display statistics for the no-url-filtering rule action, enter the show statistics rule http action no-url-filtering EXEC command.

---

Tip A hit counter will not increase if there is no reason to try the rule. For example, if a request is already cacheable, then the cache-non-cacheable action will never be tested.

---

Clearing Statistics for Configured Rules

To clear the statistics for the rules that are configured on a standalone Content Engine, use the clear statistics rule EXEC commands. In the ACNS 5.5.1 software and later releases, the command options for the clear statistics rule command are as follows:

ContentEngine# clear statistics rule ?

  action   Clear statistics of all the rules with same action

  all      Clear statistics of all the rules

  pattern  Clear statistics of Pattern lists

  rtsp     Clear statistics of rtsp/wmt-rtsp rules

For example, enter the clear statistics rule rtsp command to clear the statistics for the configured RTSP rules (rules configured for RTSP requests from RealMedia players [the RTSP rules] and rules configured for RTSP requests from Windows Media 9 players [the WMT-RTSP rules]).

Using Regular Expressions for Rules

The rules facility uses the Regex libraries to perform regular expression matching. A regular expression does not have to match the whole string, but searches within the string for a substring match. Matching for regular expressions is not case sensitive.

Special Characters in Regular Expressions

Whereas ordinary characters are those that match themselves in a regular expression, special characters are those used to match other characters or that have special meaning. Table 13-8 describes the special characters used in regular expressions for rules processing.

Table 13-8 Special Characters

Operator	Description	Function
Matching Operators
.	Period	Matches any character except a newline or null character.
^	Caret	Matches the beginning of the line.
$	Dollar sign	Matches the end of a string.
Repetition Operators
*	Asterisk	Matches zero (0) or more of the preceding character (greedy).
+	Plus sign	Matches one (1) or more of the preceding character (greedy).
?	Question mark	Matches zero (0) or one (1) of the preceding character.
{}	Braces	Interval operator matches specified number of occurrences of the preceding character: {count}, {min}, {min, max}
Listing and Grouping Operators
|	Bar	Alternation. Matches union of expressions.
[]	Brackets	List of single elements. Matches any element form the list. Within a bracketed list, a hyphen (-) is a range operator, a caret (^) at the beginning of a list makes a non-matching list, and other characters within a list are ordinary.
()	Parenthesis	Used for grouping and provides indexing.
\#	Backslash and digit	Indicates the index (1-9) based on the order of the groupings. Note The grouping must be part of the match for the index to be valid. If the grouping is not part of the match, the the expression that uses the index will be invalid.

Table 13-9 Special Characters Exclusive to ACNS Software

Operator	Description	Function
!	Exclamation point	Used to NOT a string. Note The ACNS software recognizes the exclamation point (!) although it is not a regular expression operator.

Rules Caveats and Performance Guidelines

This section describes several group-type caveats and provides configuration guidelines for best performance.

Pattern List Group-Type Caveats

When configuring a rule pattern list, consider the following usage restrictions:

•A rule pattern list can be only one group type. It can be an AND group type, or it can be an OR group type; it cannot be both.

•You cannot AND a mime-type pattern with other pattern types.

•You cannot OR between groupname, groupname-regex, and username patterns.

•You cannot OR between substitution patterns and non-substitution patterns.

•You cannot OR between multiple substitution patterns.

Rules Configuration Guidelines for Best Performance

Rules impact performance and CPU utilization. Consider the following guidelines for best performance when configuring rules:

•Keep it simple.

–Remember that rules are used as the exception to override default functionality.

–Lengthy and complicated rules often lead to problems.

–A rule list that is too long quickly becomes difficult to manage and troubleshoot.

•Reduce, eliminate, or combine rule patterns where possible.

–Some rule patterns can be combined. For example, you can list multiple domains in the domain pattern by using the bar symbol (|) as a delimiter.

–Keep the number of pattern-lists below the maximum: 512.

–Keep the number of patterns per pattern-list below the maximum:128.

•Order rules so that the most commonly applied rules are tested first.

–You can use the show statistics rule EXEC command to view the rule hit count and learn how often rule actions are tested.

–When ordering rules, keep in mind that rules of the same action, and rule patterns in the same pattern-list generally execute in the order in which they were configured.

•Regular expression rules have the greatest impact on performance.

–Avoid the use of wild cards. Regular expression wild cards are greedy; they attempt to match 0 to 1 or more of the preceding character. Because "or more" is stated, the rule tries to match as large a string as possible.

–Do not use wild cards at the beginning or end of an expression. You want to match a pattern within a string rather than match the entire string.

•The dst-ip pattern in a proxy mode environment requires DNS lookups that impact performance.

¹ Allow and block carry the same precedence. The order of execution depends on the order of configuration between allow and block actions. Other actions always take precedence over allow. For example, a reset action always takes precedence over allow regardless of the order of configuration.