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

Supported Action and Pattern Combinations

Rules Template Processing Considerations

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

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, 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

•Configuring the Rules Template

•Displaying Statistics for Configured Rules

---

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 native FTP requests.

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

---

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 standalone Content Engine to use specific rules to filter HTTP, HTTPS, MMS, 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.

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 protocols such as MMS and RTSP, in addition to HTTP, FTP, and HTTPS, are indicated in Table 12-1.

Table 12-1 Rules Template Policies 

Policy (Action)	HTTP Requests	MMS Requests	RTSP Requests
Allow the request.	See Table 12-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.		*	*
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 12-2 lists the rule actions per protocol that are supported by standalone Content Engines running ACNS software, Release 5.2 or later. 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 ACNS software, Release 5.1.5 or later.

Table 12-2 Matrix of Supported Rule Actions Per Protocol (ACNS Software, Release 5.2 or Later)

Rule Actions	Protocol								Streaming Protocol
	HTTP- over- HTTP	FTP- over- HTTP	HTTPS- over- HTTP	HTTP WCCP	FTP- WCCP (Native FTP)	HTTPS-WCCP	HTTPS-WCCP (tunneled, only available Release 5.1.5 or later)	RTSP	MMSU	MMST	MMS
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	*	*		*
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 (for example, pattern list 10)

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

•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 12-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. 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 12-1) to specify a pattern and the corresponding action.

Figure 12-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. 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 ACNS 5.2 software, 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 mechanisms that involve a username for authentication).

For example, the following 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 Note that 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 12-3 describes the types of rule patterns that you can add to a pattern list.

Table 12-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. Note that 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.
dst-ip	Matches the request's destination IP address and netmask against the IP address and netmask specified in the rule. Note 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 against the port number specified in the rule.
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 255 characters. Valid characters are an underscore and alphanumeric characters. 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. For example, use to configure a regular expression-based policy on group names or to OR multiple group names in the same line of a single pattern list. For example, to OR three group names enter: ContentEngine(config)# rule pattern-list 1 groupname-regex Engingeering|Marketing|Finance\ The specified action is taken if any of the above group names matches the one in the request.
group-type	Specifies whether the pattern list is an AND or OR type. The default is OR.
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 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	Request header field pattern and substitute replacement pattern.
icap-service- name	Specifies the name of the ICAP service that should be used.
mime-type	Matches the MIME type of the response against the MIME type string (for example, "image/gif," as defined in RFC 2046 at http://www.faqs.org/rfcs/rfc2046.html) specified in the rule. You 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 against the IP address and a netmask specified in the rule.
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 255 characters for LDAP, RADIUS, or TACACS+ authentication. See below for information about the maximum length of usernames for NTLM authentication. Valid characters are an underscore and alphanumeric characters. This pattern supports exact string comparison and is case insensitive. To specify multiple usernames in the same line for the same pattern list use a delimiter. For 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. For example: ContentEngine(config)# rule pattern-list 1 username domain 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\* where 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. 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/.
URL-regsub	For the rewrite and redirect actions, matches the URL against a regular expression to form a new URL in accordance with the 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 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

  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 12-4 describes the types of actions that you can associate with a defined pattern list.

---

Note ACNS software, Release 5.1 or later supports configuration of up to 520 actions to be configured.

---

Table 12-4 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-cookie	Cache requests that contain cookies.
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 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	Use the client's ToS or DSCP value.
dscp server set-dscp	Specify the DSCP value. For a list of DSCP values, see Table 3-9.
dscp server set-tos	Specify the Type of Service (ToS) value. For a list of ToS values, see Table 3-10.
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 into 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-persistent- connection all	Does not use a persistent connection to all connections.
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	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. 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 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 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.
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.
use-xforward-clt-ip	Uses the client IP address in an X-forwarded header for filtering.

Example of use-server Action

The following is an example of how the use-server action is typically used. 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. This 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 

where 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 ad pattern combinations, see Table 12-5 and Table 12-6. For a list of the rule actions per protocol that are supported by standalone Content Engines that are running ACNS software, Release 5.2 or later, see Table 12-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. Table 12-5 and Table 12-6 provide a matrix of the supported action and pattern combinations for standalone Content Engines.

An asterisk "*"indicates that a particular action and pattern combination is supported in ACNS software, Release 5.2.1 or later. The groupname, username, and groupname-regex patterns and the cache-cookie action were added in ACNS 5.2.1 software release.

Table 12-5 Supported Action and Pattern Combinations—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 12-6 Supported Action and Pattern Combinations—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

*

*

*

*

*

redirect

*

*

*

*

refresh

*

*

*

*

*

*

reset

*

*

*

*

*

*

*

*

rewrite

*

*

*

*

selective- cache

*

*

*

*

*

*

use-dns- server

*

*

use-icap- service

*

*

*

*

*

*

*

*

use- proxy

*

*

*

*

*

use- proxy- failover

*

*

*

*

*

use- server

*

*

*

*

*

use- xforward clt-ip

*

*

*

*

*

*

*

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 has to understand these 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 and of the same rules pattern, the rules are evaluated in a Last-Entered-First-Examined fashion (the reverse of the order in which the rules were entered). For example, if you specified:

ContentEngine(config)# rule action use-proxy 1.2.3.4 abc.abc.com 

ContentEngine(config)# rule action use-proxy 2.3.4.5 *.abc.com 

then the Content Engine directs a request to abc.abc.com to the proxy server that has an IP address of 2.3.4.5 because the use-proxy 2.3.4.5 *.abc.com rule was entered last and therefore is evaluated first, and the request will hit a match with that rule.

However, if you had entered:

ContentEngine(config)# rule action use-proxy 2.3.4.5 *.abc.com

ContentEngine(config)# rule action use-proxy 1.2.3.4 abc.abc.com

then the Content Engine would direct a request to abc.abc.com to the proxy server that has an IP address of 1.2.3.4.

•When a new release of 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 release), the order of processing among existing actions and patterns does not change.

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 the Content Engine GUI or the CLI.

---

Tip In 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.

---

Execution Order of Rule Actions

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

1. 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)

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

3. Reset

4. Block

5. Redirect (before cache lookup)

6. Rewrite (before cache lookup)

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

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

9. Use-server

10. No-proxy

11. Use-proxy-failover

12. Use-proxy

13. Use-dns-server

14. TOS/DSCP server (TOS bits on the connection to the server)

15. TOS/DSCP client (TOS bits on the connection that the server uses to send response to client)

16. DSCP client cache-miss

17. DSCP client cache-hit

18. Insert-no-cache

19. No-cache

20. Cache (when the response is received from the server)

21. Selective-cache (when the response is received from the server)

22. Append-username-header

23. Use-icap-service

24. Use-xforward-clt-ip

25. No-persistent-connection

26. Cache-cookie

27. No-selective-cache

28. 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, then the Referer header is stripped. Hence, 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 commands 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. 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.

---

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.

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 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, note 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 scenario:

–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 scenario.

---

Note You can configure a Rules Template through the CLI or Content Engine GUI (as shown in Figure 12-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, 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 12-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 12-7.

---

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

---

Table 12-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.
http		Matches incoming HTTP traffic against this rule.
https		Matches this rule for incoming HTTPS traffic.
mms		Matches incoming MMS traffic against this rule.
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.
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).
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 mechanism 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 3-9.
set-tos		Configures Type of Service (ToS) values. For a list of ToS values, see Table 3-10.
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.
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		Host name 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.
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 the specified 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. 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 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.

Configuring a Pattern List

Use the rule pattern-list global configuration command to create a pattern list on a standalone Content Engine, 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, 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 12-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 12-7.

---

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.

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.

---

Use the domain pattern type to specify domains that contain .foo.com, 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 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

Use the show statistics rule EXEC command to display statistics for the rules that are configured on a standalone Content Engine.

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

For example, enter the show statistics rule all EXEC command to display the total number of rule hit counts.

ContentEngine# show statistics rule all

Rules Template Statistics

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

Rule hit count = 0   Rule: rule action no-auth pattern-list 1 protocol all

Rule hit count = 0   Rule: rule action rewrite pattern-list 2 protocol all

Use the show statistics rule http EXEC command to display statistics for all of the configured rules that apply to HTTP and HTTPS requests.

Use the show statistics rule wmt EXEC command to display statistics for all of the configured rules that apply to Windows Media Technologies (WMT) requests.