Table Of Contents

Configuring Caching Protocols

Configuring FTP Connection Settings

Configuring FTP Connection Settings Using the Content Engine GUI

Configuring FTP Connection Settings Using CLI Commands

Examples of Configuring FTP Connections Using CLI Commands

Setting FTP Cache Freshness

Configuring FTP Cache Object Freshness Using the Content Engine GUI

Configuring FTP Cache Object Freshness Using CLI Commands

Configuring HTTP and HTTPS Settings

Configuring HTTP Connection Settings

Configuring HTTP Connections Using the Content Engine GUI

Configuring HTTP Connections Using CLI Commands

Configuring HTTP Cache Freshness Settings

Configuring HTTP Cache Object Freshness Using the Content Engine GUI

Configuring Authenticated HTTP Cache Settings

Configuring Authenticated HTTP Cache Settings Using the Content Engine GUI

Configuring Authenticated HTTP Cache Settings Using CLI Commands

Configuring Advanced HTTP Cache Settings

Configuring Caching of HTTP Range Requests

Caching Entire Objects Under Range Requests

Configuring HTTP Cache On Abort

Configuring Persistent Connections

Enabling Persistent Connections

Disabling Persistent Connections

Enabling and Configuring Healing Mode

Configuring HTTPS-Related Parameters

Usage Guidelines and Examples

Configuring HTTPS Proxy Settings Using the Content Engine GUI

Configuring HTTPS-Related Parameters Using CLI Commands

Configuring Certificates and Private Keys for HTTPS Caching

Content Engine Security

HTTPS Statistics Reporting

HTTPS Transaction Logging

HTTPS TCP Keepalives

Configuring the TFTP Server and Gateway

Using the TFTP Service and Gateway on Locally Deployed Content Engines

Enabling the TFTP Server and Gateway

Configuring the TFTP Server and Gateway

TFTP Server and Gateway Configuration Examples

Configuring ICP Settings

Configuring ICP Client Settings

Configuring ICP Client Settings Using the Content Engine GUI

Configuring ICP Client Settings Using CLI Commands

Configuring ICP Server Settings

Configuring ICP Server Settings Using the Content Engine GUI

Configuring ICP Server Settings Using CLI Commands

Configuring WCCP Settings

Enabling WCCP on a Content Engine

Enabling WCCP Version 2 Services on a Content Engine

Enabling WCCP Version 2 Services on a Content Engine Using the Content Engine GUI

Configuring WCCP Version 2 Services Using CLI Commands

Configuring Bypass Settings

Configuring Static Bypass

Configuring Load Bypass

Configuring Authentication Bypass

Configuring Authentication Bypass Using CLI Commands

Configuring Caching Protocols

---

This chapter describes how to configure caching protocols such as FTP, HTTP, HTTPS, ICP, and WCCP for a locally deployed Content Engine.

•Configuring FTP Connection Settings

•Configuring HTTP and HTTPS Settings

•Configuring the TFTP Server and Gateway

•Configuring ICP Settings

•Configuring WCCP Settings

---

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

---

Configuring FTP Connection Settings

The Content Engine has the ability to handle FTP-style requests over HTTP transport when configured in proxy mode. When the Content Engine receives an FTP request from a client, it processes the request by searching its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server if this proxy server has been configured, or it fetches the object directly from the origin FTP server.

ACNS 5.1 software also supports native FTP caching on the Content Engine. You can use the Content Engine GUI or the CLI to configure FTP connection settings on a locally deployed Content Engine.

---

Note For more details about FTP over HTTP and native FTP support, see the "FTP and Caching" section. For FTP proxy configuration examples, see the "FTP Proxy Configuration Examples" section.

---

Configuring FTP Connection Settings Using the Content Engine GUI

To configure FTP connection settings on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > FTP Proxy. The FTP Proxy window appears. (See Figure 10-1.)

Figure 10-1 FTP Proxy Window

Step 2 Click the Enable Incoming FTP Proxy On radio button to configure the Content Engine to accept FTP proxy requests on a particular port.

Step 3 In the Incoming FTP Proxy Port List field, enter the port numbers used by the FTP proxy server to receive requests.

Step 4 Click the Enable Outgoing FTP Proxy On radio button to configure the Content Engine to direct all FTP cache miss traffic to a parent cache (without using ICP or WCCP).

Step 5 In the Outgoing Proxy Address field, enter the IP address for the outgoing FTP proxy.

Step 6 In the Outgoing FTP Proxy Port field, enter a port number corresponding to the outgoing proxy address from Step 5.

Step 7 Enter the password to be used during anonymous FTP operation. Emptying this field will restore this field to the default value. The default password string is anonymous@hostname.

Step 8 Click Update to save the settings.

---

Configuring FTP Connection Settings Using CLI Commands

You can also use the ftp proxy command to configure FTP connection settings on a locally deployed Content Engine. Table 10-1 describes the FTP connection setting parameters that appear in the Content Engine GUI (Figure 10-1) and provides the corresponding CLI commands.

Table 10-1 FTP Connection Settings GUI Fields

Content Engine GUI Field	Description	CLI Command
Enable Incoming FTP Proxy	Configures the Content Engine to accept incoming FTP requests on ports in addition to port 80.	ftp proxy incoming
Incoming FTP Proxy Port List	Port numbers used by the proxy server or Content Engine to receive FTP requests. This number ranges from 1 to 65535. You can specify up to 8 ports.	ftp proxy incoming ports
Enable Outgoing FTP Proxy	Configures an outgoing proxy server or another Content Engine, without using ICP or WCCP, to receive FTP cache miss request traffic.	ftp proxy outgoing
Outgoing FTP Proxy Address	Configures multiple outgoing proxy servers. Enter the host name or IP address for the outgoing FTP proxy server.	ftp proxy outgoing host {hostname | ipaddress}
Outgoing FTP Proxy Port	Port number corresponding to the outgoing FTP proxy host names.	ftp proxy outgoing host {hostname | ipaddress} port 1-65535
Anonymous Password	Password to be used during anonymous FTP operation. The default password string is anonymous@hostname.	ftp {proxy active-mode enable | anonymous-pswd passwd | incoming ports | outgoing host {hostname | ip-address} port 1-65535}

Examples of Configuring FTP Connections Using CLI Commands

Table 10-2 provides some examples of using the CLI to configure FTP connections on a locally deployed Content Engine.

Table 10-2 CLI Examples of Configuring FTP Connections on a Local Content Engine 

Purpose	Command
Configures an incoming FTP proxy on ports 8080, 8081, and 9090 of the Content Engine. Up to 8 incoming proxy ports can be configured on the same command line.	ContentEngine(config)# ftp proxy incoming 8080 8081 9090
Removes one FTP proxy port from the list entered in the previous example. Ports 8080 and 9090 remain FTP proxy ports on the Content Engine.	ContentEngine(config)# no ftp proxy incoming 8081
Disables all the FTP proxy ports on the Content Engine.	ContentEngine(config)# no ftp proxy incoming
Configures an upstream FTP proxy with the IP address 172.31.76.76 on port 8888.	ContentEngine(config)# ftp proxy outgoing host 172.31.76.76 8888
Specifies an anonymous password string for the Content Engine to use when contacting FTP servers. The default password string is anonymous@hostname.	ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostname

Setting FTP Cache Freshness

ACNS 5.x software can be tuned to balance HTTP and FTP object freshness with the cache hit rate. ACNS software's default parameters are weighted in favor of securing fresh content over maximizing the cache hit rate (to avoid the undesirable scenario of increasing the cache hit rate by serving stale content).

When configuring the FTP cache freshness settings, note the following:

•You can specify the maximum size of an FTP or HTTP object that can be stored in the cache. The maximum size limit for both an FTP object and an HTTP object is 204,799 kilobytes. An object with a size above the configurable upper limit is not stored by the Content Engine.

•Use the age multiplier settings to control at what percentage of an object's maximum Time To Live the Content Engine will issue an if-modified-since (IMS) request to the origin web server to validate the freshness of the object. The range of values is from 0 to 100 percent. The default values are 30 percent for text files and 60 percent for binary objects.

•Use the minimum and maximum Time To Live (TTL) settings to limit the duration of HTTP and FTP objects in the cache. By default, HTTP cacheable objects are kept for 5 minutes minimum and 3 to 7 days maximum (3 days for text-type objects, 7 days for binary). If an object has an explicit expiration date, this takes precedence over the configurable TTL. The default values are 3 days for text files and 7 days for binary objects.

The following are valid values for the maximum TTL:

–Days—1 to 1825

–Hours—1 to 43800

–Minutes—1 to 2628000

–Seconds—1 to 157680000

•For HTTP and FTP objects, use the http min-ttl and ftp min-ttl global configuration commands to set the minimum TTL, and the http max-ttl and ftp max-ttl command to set the maximum TTL.

•Use the http age-multiplier global configuration command to enable the Content Engine to guess the "life" of an object by multiplying the time since the object's last-modified-date by a percentage to derive an approximate expiration date. After this, the object will be considered stale and subsequent requests result in a fresh retrieval by the Content Engine.

•Use the http cache-cookies global configuration command to enable the Content Engine to cache binary objects which are served with HTTP set-cookies headers and no explicit expiration information, but which might be cacheable.

---

Tip Text objects refer to HTML pages. Binary objects refer to all other web objects, such as GIFs, JPEGs, etc.

---

You can use the Content Engine GUI or CLI to configure FTP cache object freshness settings for locally deployed Content Engines. These parameters can be configured for either directory listings or particular objects in the cache.

Configuring FTP Cache Object Freshness Using the Content Engine GUI

To configure FTP cache object freshness settings on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > FTP Freshness. The FTP Freshness window appears. (See Figure 10-2.)

Figure 10-2 FTP Cache Object Freshness Settings Window

Step 2 Specify a percentage in the Directory Age Multiplier field.

This value enables the Content Engine to guess the life of a directory by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent requests for the object cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 30 percent.

Step 3 Specify a percentage in the File Age Multiplier field.

This value enables the Content Engine to guess the life of an object by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent results cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 60 percent.

Step 4 Choose a scale from the Maximum Time-to-Live (TTL) Scale drop-down list.

The TTL sets a ceiling on estimated expiration dates. If an object has an explicit expiration date, this takes precedence over the configured TTL.

Step 5 Specify a value for the Maximum TTL field.

See Table 10-3 for a list of maximum values depending on the scale used. Default values are 3 days for directory objects and 7 days for file objects.

Table 10-3 Time To Live Range of Values for FTP Freshness 

Scale	Range
Days	1-1825
Hours	1-43800
Minutes	1-2628000
Seconds	1-157680000

Step 6 Specify a value (in minutes) for the Minimum TTL field.

A minimum TTL is the minimum time to live for objects in the cache. The range of values is 0 to 86400 minutes. The default value is 30 minutes.

Step 7 Choose a method for handling reevaluation requests by clicking the appropriate Revalidate every request with origin server radio button. Objects with the size above the configurable limit are not stored by the Content Engine. Valid values are 1 to 1048576 kilobytes.

Step 8 Click Update to save the settings.

---

Configuring FTP Cache Object Freshness Using CLI Commands

Table 10-4 provides some CLI examples of configuring FTP cache object freshness settings on a Content Engine.

Table 10-4 CLI Examples of Configuring FTP Cache Freshness Settings on a Local Content Engine 

Purpose	Command
Configures the maximum size of HTTP and FTP objects that should be stored in the Content Engine's cache. Sets the maximum size for an HTTP object to 500 kilobytes, and the maximum FTP object size as 2 megabytes.	ContentEngine(config)# ftp object max-size 2000 ContentEngine(config)# http object max-size 500 ContentEngine(config)#
Forces the Content Engine to revalidate all objects for every FTP request.	ContentEngine(config)# ftp reval-each-request all
Configures a maximum Time To Live of 3 days in cache for directory listing objects and file objects.	ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3
Configures the HTTP age multiplier to be 55% for text files, and 45% for binary objects. Displays the result of this configuration using the show http age-mult EXEC command.	ContentEngine(config)# http age-multiplier text 55 binary 45 ContentEngine# show http age-mult HTTP heuristic age-multipliers: text 55% binary 45% ContentEngine#
Configures the ability to cache binary objects and associated cookies, which are served with HTTP set-cookies headers and no explicit expiration information, but which might be cacheable.	ContentEngine(config)# http cache-cookies ContentEngine(config)#
Configures the HTTP age multiplier to be 55% for text files, and 45% for binary objects. Displays the result of this configuration using the show http age-mult EXEC command.	ContentEngine(config)# http age-multiplier text 55 binary 45 ContentEngine# show http age-mult HTTP heuristic age-multipliers: text 55% binary 45% ContentEngine#
Configures the Content Engine to keep HTTP and FTP objects in the cache for a minimum of 10 minutes and a maximum of 24 hours (1 day).	ContentEngine(config)# http min-ttl 10 ContentEngine(config)# ftp min-ttl 10 ContentEngine(config)# http max-ttl days text 1 binary 1 ContentEngine(config)# ftp max-ttl hours directory-listing 24 file 24
Displays the configuration changes made to HTTP objects in the cache using the show http ttl EXEC command.	ContentEngine# show http ttl Maximum time to live in days: text 1 binary 1 Minimum time to live for all objects in minutes: 10 ContentEngine#
Displays the configuration changes made to FTP objects in the cache using the show ftp EXEC command.	ContentEngine# show ftp FTP heuristic age-multipliers: directory-listing 30% file 60% Maximum time to live in hours: directory-listing 24 file 24 Minimum time to live for all objects in minutes: 10 Incoming Proxy-Mode: Not servicing incoming proxy mode connections. Outgoing Proxy-Mode: Not using outgoing proxy mode. Passive mode of FTP transfer is enabled Maximum size of a FTP cacheable object is 204799 KBytes No object is revalidated on each request ContentEngine#

Configuring HTTP and HTTPS Settings

You can configure, modify, and view HTTP and HTTPS settings for locally deployed Content Engines by completing the following tasks:

•Configuring HTTP Connection Settings

•Configuring HTTP Cache Freshness Settings

•Configuring Authenticated HTTP Cache Settings

•Configuring Advanced HTTP Cache Settings

•Configuring HTTPS-Related Parameters

•Content Engine Security

Configuring HTTP Connection Settings

A proxy-style request arrives with the same destination IP address as that of the Content Engine; it has been specifically routed to the Content Engine by the client. The Content Engine supports up to eight incoming ports each for FTP, HTTP, HTTPS, Microsoft Media Server (MMS), and RTSP proxy modes. The incoming proxy ports can be the same ports that are used by transparent mode services. The incoming proxy ports can be changed without stopping any WCCP services running on the Content Engine.

---

Tip You can use the Content Engine GUI or CLI to configure HTTP connections on a locally deployed Content Engine.

---

Configuring HTTP Connections Using the Content Engine GUI

To configure HTTP connection settings on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > HTTP Proxy. The HTTP Proxy window appears. (See Figure 10-3.)

Figure 10-3 HTTP Proxy Window

Step 2 Click the Enable Incoming HTTP Proxy On radio button to accept incoming requests on ports in addition to port 80.

Step 3 In the Incoming HTTP Proxy Port List field, enter the port numbers used by the proxy server to receive requests.

Step 4 Click the Enable Outgoing HTTP Proxy On radio button to configure the Content Engine to direct all HTTP miss traffic to a parent cache (without using ICP or WCCP).

Step 5 Use the Use Origin Server Upon Proxy Failures radio buttons to specify how requests are handled in the event that all outgoing proxy servers have failed. If enabled, requests will be directed to the origin server specified in the user request. If disabled, the user will receive an error message.

Step 6 Use the Interval to Monitor Proxy Servers field to specify the interval in seconds at which to monitor a single outgoing proxy server. If multiple outgoing proxy servers are configured, they will be monitored sequentially, with a delay of this interval between monitor requests.

Step 7 Multiple outgoing proxy servers can be configured. Enter the IP address or hostname and the port number used by the outgoing proxy server to accept proxy HTTP requests. Click the Enable check box. To delete a server, uncheck the Enable check box or manually delete the IP address and port.

The purpose of configuring multiple outgoing proxy servers is to provide a backup mechanism should the primary proxy server fail. All requests will be directed to the primary outgoing proxy server. If the primary proxy server fails, requests will then be directed to the next active proxy server on the list.

---

Tip The show http proxy CLI command displays the current state of each proxy server.

---

Step 8 Click Update to save the settings.

---

Configuring HTTP Connections Using CLI Commands

You can also use the CLI to configure HTTP connections on a locally deployed Content Engine. Use the http proxy command to configure HTTP connections. Table 10-5 describes Content Engine GUI parameters and corresponding CLI commands to help you configure HTTP connection settings.

Table 10-5 HTTP Connection Settings GUI Fields and Related CLI Commands 

Content Engine GUI Field	Description	CLI Command
Enable Incoming HTTP Proxy	Configures the Content Engine to accept incoming requests on ports in addition to port 80.	http proxy incoming
Incoming HTTP Proxy Port List	Port numbers used by the proxy server or Content Engine to receive requests. This number ranges from 1 to 65535. You can specify up to 8 ports.	http proxy incoming ports 1-6553
Enable Outgoing HTTP Proxy	Configures an outgoing proxy server or another Content Engine, without using ICP or WCCP, to receive HTTP cache miss request traffic.	http proxy outgoing
Use Origin Server upon Proxy Failures	When enabled, requests are handled by the origin server if all outgoing proxy servers fail. If disabled, the user receives an error message if all outgoing proxy servers fail.	http proxy outgoing origin-server
Interval to Monitor Proxy Servers	Specifies the interval in seconds at which to monitor a single outgoing proxy server. If multiple outgoing proxy servers are configured, they are monitored sequentially. The default value is 200 seconds.	http proxy outgoing monitor
Outgoing Proxy Servers	Configures multiple outgoing proxy servers using the host name or IP address for the outgoing proxy server.	http proxy outgoing host {hostname | ipaddress}
Port	Port number corresponding to the outgoing proxy host names.	http proxy outgoing host {hostname | ipaddress} ports 1-65535

Configuring HTTP Cache Freshness Settings

You can configure HTTP cache object freshness parameters for locally deployed Content Engines through the Content Engine GUI or CLI. These parameters can be configured for either directory listings or particular objects in the cache.

Configuring HTTP Cache Object Freshness Using the Content Engine GUI

To configure HTTP cache freshness parameters on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Cache > HTTP Freshness. The HTTP Freshness window appears. (See Figure 10-4.)

Figure 10-4 HTTP Cache Freshness Settings Window

Step 2 Specify a percentage in the Text Object Age Multiplier field.

The age multiplier value enables the Content Engine to guess the life of a text object by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent results cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 30 percent.

Step 3 Specify a percentage in the Binary Object Age Multiplier field.

This value enables the Content Engine to guess the life of a binary object by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent results cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 60 percent.

Step 4 Choose a scale from the Maximum Time-to-Live (TTL) Scale drop-down list.

The TTL sets a ceiling on estimated expiration dates. If an object has an explicit expiration date, this takes precedence over the configured TTL.

Step 5 Specify a value in the Max Text Object TTL field.

The valid range of values is given in Table 10-6.

Table 10-6 Time To Live Range of Values for HTTP Freshness 

Scale	Range
Days	1-1825
Hours	1-43800
Minutes	1-2628000
Seconds	1-157680000

Step 6 Specify a value in the Max Binary Object TTL field.

See Table 10-6 for a list of maximum values depending on the scale used.

Step 7 Specify a value (in minutes) in the Minimum TTL field.

A minimum TTL is the minimum time to live for objects in the cache. The range of values is from 0 to 86400 minutes. The default value is 30 minutes.

Step 8 Choose a method for handling reevaluation requests by selecting the appropriate Revalidate every request with origin server radio button.

Step 9 Set the upper limit of object size in kilobytes (KB). The maximum object size for cached HTTP objects is 2096128 KB (2 GB).

---

Note The Content Engine does not store an object if the size of the object exceeds the specified limit.

---

Step 10 Click Update to save the settings.

---

Configuring Authenticated HTTP Cache Settings

The authenticated HTTP caching feature allows basic and NT LAN Manager (NTLM) authenticated content to be cached and served to more than one user, while maintaining security. If an authenticated object is cached, then subsequent requests for that object (from new users) require authentication. The cached object is revalidated with the origin server through the authorization header for the new user. If the user is not authorized, the server sends a 401 (Unauthorized) response. If the user is authorized and the object is not modified, the cached object is served to the client.

---

Note If the authentication cache is not large enough to accommodate all authenticated users at the same time, the Content Engine purges older entries that have not yet timed out.

---

This example enables caching of both basic and NTLM authenticated content:

Console(config)# http cache-authenticated all

Console(config)# show http cache-authenticated all

Basic authenticated objects are cached.

NTLM authenticated objects are cached.

Configuring Authenticated HTTP Cache Settings Using the Content Engine GUI

To configure authenticated HTTP caching parameters on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Auth.Cache. The Authenticated Cache window appears. (See Figure 10-5.)

Figure 10-5 Authenticated HTTP Cache Settings Window

Step 2 In the Max-entries field, enter a value for the maximum number of entries that is maintained in the cache. The default value is 32,000 entries.

Step 3 In the Timeout field, enter a value for the amount of time between last access and cache removal from the Content Engine. The range is from 1 to 1440 minutes and the default value is 480 minutes.

Step 4 Click the Header type drop-down list and choose a header type message to send to the requesting client when authorization has failed. By default, Based on URL syntax is specified as the header type. Other choices are:

•401— Sends a 401 unauthorization message to the client.

•407— Sends a 407 proxy authorization required message to the client.

Step 5 Click Update to save the settings.

---

Configuring Authenticated HTTP Cache Settings Using CLI Commands

To use the CLI to configure authenticated HTTP cache settings on a locally deployed Content Engine, use the http global configuration command.

http authentication {cache {max-entries entries | timeout minutes} | header {401 | 407} | realm line}

http cache-authenticated {all | basic | ntlm}

The max-entries option sets the maximum number of authentication cache entries retained.

The timeout option specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires a server lookup for reauthentication.

Table 10-7 describes the HTTP cache authentication parameters.

Table 10-7 HTTP Cache Authentication CLI Parameters 

Parameter	Description
timeout	Sets the timeout value of records in the authentication cache.
minutes	Time in minutes (30-1440) between the user's last Internet access and the removal of that user's entry from the authorization cache, forcing reauthentication. The default is 480 minutes; the minimum is 30 minutes; and the maximum is 1440 minutes (24 hours).
header	Determines which HTTP header to use for authentication (user ID and password) when the style of the HTTP request indicates that no proxy server is present. Headers can be either HTTP 401 (Unauthorized) or HTTP 407 (Proxy Authentication Required). The default is HTTP 401.
401	Uses HTTP 401 to query users for credentials.
407	Uses HTTP 407 to query users for credentials.
realm	Configures the realm string for basic HTTP request authentication.
line	Name of the realm string to be authenticated.
cache-authenticated	Caches and revalidates authenticated web objects.
all	Authenticates the web object cache using any authorization scheme.
basic	Authenticates the web object cache using basic authorization.
ntlm	Authenticates the web object cache using NTLM authorization.

Configuring Advanced HTTP Cache Settings

This section describes how to configure the following advanced HTTP cache settings on a locally deployed Content Engine:

•Configuring Caching of HTTP Range Requests

•Caching Entire Objects Under Range Requests

•Configuring HTTP Cache On Abort

•Configuring Persistent Connections

•Enabling and Configuring Healing Mode

Configuring Caching of HTTP Range Requests

The Content Engine serves HTTP Range requests that include a Range header requesting the specified range of the object instead of the whole object from the cache if the requested range exists in the Content Engine cache. Specifically, the Content Engine handles Range requests with the following logic:

lookup the object in the cache; 

if object in the cache 

{ 

            check whether the requested ranges are in the cache; 

            if the requested ranges are in cache then serve the request from cache; 

            else pipe through the request; 

} 

else pipe through the request; 

If a web client has a partial copy of an entity in its cache and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request header with a conditional GET request (using either or both If-Unmodified-Since and If-Match). However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity.

The If-Range header allows a client to short-circuit the second request. Informally, the meaning of this header is "If the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity."

If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

An If-Range request from the client will be handled by the cache as follows:

lookup the object in the cache; 

if (object is in the cache 

    AND requested ranges are in the cache; 

    AND entity tag given in the If-Range header 

            matches cached object's entity-tag){

        serve partial request from the cache

} else {

connect to remote server

retrieve requested range, send data to client

}

If the If-Range header has a valid HTTP date instead of an entity tag, then the HTTP date is matched with the Last-Modified date of the cached object.

If the web client has no entity tag for an entity but does have a Last-Modified date, it may use that date in an If-Range header. The If-Range header should only be used together with a Range header, and must be ignored if the request does not include a Range header, or if the server does not support subrange operation.

If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server should provide the specified subrange of the entity using a 206 (Partial content) response. If the entity tag does not match, then the server should return the entire entity using a 200 (OK) response.

---

Note The http cache-on-abort feature must be disabled for the caching of HTTP Range requests to occur. Some client applications close the server connection immediately after receiving the response header for a normal GET request (for example, to a PDF file). If the http cache-on-abort command is enabled, later Range requests to that object will not be cacheable.

---

Caching Entire Objects Under Range Requests

In ACNS 5.x software, the http smart-range command enables the Content Engine to cache an entire HTTP response even if the client issues a Range request and the object is not in the cache. Use the no version of this command, no http smart-range enable, to disable this caching.

The http smart-range max-start offset max-interval interval byte values control these Range request conditions when this feature is enabled. The offset value is the maximum offset value of the first range in the client's Range request. The range of values is from 0 to 2147483647 bytes. The default value is 16384 bytes. The interval value is the maximum interval between any consecutive ranges in the client's request. The range of values is from 0 to 2147483647 bytes. The default value is 16384 bytes.

Only if a Range request satisfies both conditions and a cache miss occurs does the proxy issue a normal request to the origin server, cache the response (if cacheable), and send a Range response to the client. If the response is not cacheable, then a full response is sent to the client.

Configuring HTTP Cache On Abort

The Content Engine GUI or the CLI can be used to configure the HTTP cache-on-abort feature on a locally deployed Content Engine.

Configuring HTTP Cache On Abort Using the Content Engine GUI

To configure the HTTP cache-on-abort feature on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Cache on Abort. The Cache on Abort window appears. (See Figure 10-6.)

Figure 10-6 Cache on Abort Window

Step 2 Click the Enable HTTP Cache On Abort On radio button to have the Content Engine to continue to cache an object if the client has aborted the request.

Step 3 Check the Use Minimum Threshold check box to cache an object if the number of kilobytes remaining to download from the server is greater than the minimum threshold value. Enter a value for the minimum threshold. The default value is 32 kilobytes.

Step 4 Check the Use Maximum Threshold check box to cache an object if the number of kilobytes remaining to download from the server is less than the maximum threshold value. Enter a value for the maximum threshold in the field. The default value is 256 kilobytes.

Step 5 Check the Use Percentage Threshold check box to cache an object if the percentage of the object already downloaded is greater than the percentage threshold value entered. Enter a value for the percentage threshold. The default value is 80 percent.

Step 6 Click Update to save the settings.

---

Configuring HTTP Cache-on-Abort Using CLI Commands

Table 10-8 describes the CLI commands for configuring the HTTP cache-on-abort feature on a locally deployed Content Engine.

Table 10-8 HTTP Cache-on-Abort Features and Related CLI Command 

Command	Purpose
http cache-on-abort	Provides user-defined thresholds to determine whether or not the Content Engine will complete the download of an object when the client has aborted the request. When the download of an object is aborted before it is completed, the object is not stored on the Content Engine or counted in the hit rate statistics. Typically, a client aborts a download by clicking the Stop icon on the browser, or by closing the browser during a download. If the http cache-on-abort command is enabled, the Content Engine will use a selective algorithm to determine whether to continue to cache an object if the client has aborted the request. If the command is disabled, the Content Engine will always continue to download an object to the cache even if a client has aborted the request.
http cache-on-abort min-threshold	Configures the Content Engine to continue to cache an object if the number of kilobytes remaining to download from the server is less than or equal to the minimum threshold value. The default value is 32 KB.
http cache-on-abort max-threshold	Configures the Content Engine to not continue to cache an object if the number of kilobytes remaining to download from the server is greater than the maximum threshold value. The default value is 256 KB.
http cache-on-abort percent	Configures the Content Engine to continue to cache an object if the percentage of the object already downloaded is greater than the percentage threshold value. The default value is 80%.

---

Note Any combination of thresholds can be specified, in the order shown in Table 10-8. If the http cache-on-abort command is enabled and all http cache-on-abort thresholds are disabled, then the Content Engine always aborts downloading an object to the cache. If the Content Engine determines that there is another client currently requesting the same object, downloading is not aborted. The Content Engine only applies those thresholds that have been enabled.

---

The following are examples of how to use the CLI to configure the HTTP cache-on-abort feature on a locally deployed Content Engine.

In this example, the Content Engine is configured to always continue downloading an object to its cache.

ContentEngine(config)# no http cache-on-abort

In this example, the Content Engine is configured to use the default minimum threshold when the 
cache-on-abort option has been enabled, and the threshold is set to 16 kilobytes.

ContentEngine(config)# http cache-on-abort min 16

In this example, the Content Engine is configured to not consider the minimum threshold.

ContentEngine(config)# no http cache-on-abort min

Configuring Persistent Connections

Content Engines by default use persistent connections to the server for improving performance. Previous releases of ACNS software provided limited options for enabling or disabling persistent connections in Content Engines. For example, you were only allowed to enable or disable persistent connections to all requests, all clients, or all servers. There were no options to disable requests for persistent connections to specific domains, IP addresses, or ports.

With the ACNS 5.0.7 software release, the rule action no-persistent-connection global configuration command was added. This command enables you to disable or enable persistent connections for specific domains, source and destination IP addresses, or ports. This is useful when a server does not support persistent connections.

The rule action no-persistent-connection global configuration command has the following options:

•all—Do not use persistent connection for all connections.

•client-only—Do not use persistent connection for client connections alone.

•server-only—Do not use persistent connection for server connections alone.

You can specify the criteria for disabling persistent connections by creating a pattern list using one or more of the following supported patterns:

•src-ip

•dst-ip

•dst-port

•url-regex

•domain

•header-field user-agent

•header-field referer

•header-field request-line

Table 10-9 describes the syntax for the rule action no-persistent-connection command.

Table 10-9 Parameters of the rule action no-persistent-connection Command 

Parameter	Description
action	Describes the action that the rule is to take.
no-persistent-connection	Sets persistent connections configuration options.
pattern-list	Configures the pattern list.
list_num	Pattern list number (1-512).
protocol	Protocol for which this rule is to be matched.
http	Matches this rule with the HTTP protocol.
https	Matches this rule with the HTTPS protocol.
ftp	Matches this rule with the MMS protocol.

The following example disables a persistent connection for the domain mywebsite.com, based on a pattern (pattern number 10) in the pattern list.

ContentEngine(config)# rule action no-persistent-connection server-only pattern-list 10

WARNING: rule action no-persistent-connection will affect end-to-end NTLM authentication 
to these servers

ContentEngine(config)#

ContentEngin590#show rule all

Rules Template Configuration

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

Rule Processing Enabled

Actions :

rule action no-persistent-connection server-only pattern-list 100 protocol all

Pattern-Lists :

rule pattern-list 100 domain mywebsite.com

ContentEngine#

---

Note For more information about using the Rules Template feature to configure rules for a locally deployed Content Engine, see "Configuring the Rules Template."

---

Enabling Persistent Connections

The Content Engine GUI or the CLI can be used to enable and disable persistent connections on a locally deployed Content Engine.

To use the CLI to enable persistent connections on a locally deployed Content Engine, use the http global configuration command. The persistent-connections option enables persistent connections on the Content Engine.

ContentEngine(config)# http persistent-connections [all|client-only|server-only|timeout 
seconds] 

To configure the number of seconds that the Content Engine should wait for a connection response before it times out, use the timeout option.

Table 10-10 describes the HTTP persistent connection parameters.

Table 10-10 HTTP Persistent Connection CLI Parameters 

Parameter	Description
persistent-connections	Sets persistent connections configuration options.
all	(Optional) Makes client and server connections persistent.
client-only	(Optional) Makes only a client connection persistent.
server-only	(Optional) Makes only a server connection persistent.
timeout	(Optional) Sets persistent connections timeout value.
seconds	Persistent connections timeout in seconds (1-86400).

To use the Content Engine GUI to enable persistent connections on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Persist. Connect. The Persistent Connections window appears. (See Figure 10-7.)

Figure 10-7 Persistent Connections Window

Step 2 Choose a persistent connection type from the Persistent Connections Type drop-down list.

Step 3 In the Connection Timeout field, enter a value for the number of seconds that the Content Engine should keep an idle persistent connection open before it closes the connection. The default value is 600 seconds.

Step 4 Click Update to save the settings.

---

Disabling Persistent Connections

Use the no form of the http persistent-connections [all | client-only | server-only | timeout seconds] global configuration command to disable all persistent connections, client-only persistent connections, or server-only persistent connections.

ContentEngine(config)# no http persistent-connections [all|client-only|server-only|timeout 
seconds] 

Use the rule no-persistent-connection global configuration command to disable specific persistent connections to specific domains, IP addresses, or ports:

ContentEngine(config)# rule action no-persistent-connection pattern-list list_num 
[protocol {http|https|ftp}]

Enabling and Configuring Healing Mode

Healing mode allows the newly added Content Engine to query and obtain cache objects from all other caches in the cluster on a cache miss event. If the object is not found in the cluster, the Content Engine processes the request through the outgoing proxy or origin server. The Content Engine in healing mode is called a healing client. The caches in the cluster that respond to healing client requests are called healing servers.

When a Content Engine is added to an existing Content Engine cluster running WCCP Version 2, it can receive requests for content that was formerly served by another Content Engine in the cluster. This event is termed a "near-miss," because if the request had been sent to the former Content Engine, it would have been a cache hit. A near-miss lowers the overall cache hit rate of the Content Engine cluster.

---

Note Healing mode is only invoked on a healing client when the request is transparently redirected to the Content Engine. Healing mode is not invoked when the request is sent to the Content Engine in proxy mode.

---

To allow a Content Engine in a Content Engine farm to query and obtain cache objects from other Content Engines in the cluster, you must enable healing mode on the Content Engine.

When enabling healing mode, note the following guidelines:

•You can use the Content Engine GUI or CLI to enable healing mode on a locally deployed Content Engine.

•After a WCCP bucket redistribution, the Content Engine will try to populate its cache from other Content Engines on every cache miss. You can configure the maximum number of seconds a Content Engine should wait for a response from its neighbors before retrieving the object itself. The default is 0 seconds.

Enabling Healing Mode Using the Content Engine GUI

To configure the clustering parameters (the parameters related to WCCP service clusters) on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose WCCP > Clustering. The Clustering window appears. (See Figure 10-8.)

Figure 10-8 Clustering Window

Step 2 In the Max delay in healing mode field, enter a value for the maximum time in seconds that a healing Content Engine waits for a healing Content Engine response.

Step 3 In the Disable healing mode after field, specify the number of times that the Content Engine should ask its neighbor Content Engines for misses before it determines that the neighbor Content Engines "know nothing" and will not ask them for any more objects. The default is 0 misses.

Step 4 In the Http port for healing mode field, enter the HTTP port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster. The default port value for the HTTP healing port is 80. The number may range from 1 to 65535.

Step 5 Click Update to save the settings.

---

Enabling Healing Mode Using CLI Commands

To use the CLI to enable healing mode on a locally deployed Content Engine use the http cluster global configuration command.

http cluster {heal-port number | http-port number | max-delay seconds | misses number}

Table 10-11 describes the http cluster command parameters.

Table 10-11 Healing Mode CLI Parameters 

Parameter	Description
cluster	Configures cache cluster options.
heal-port	Listening port number of healing server for healing requests.
number	Healing server listener port number (1-65535). The default is 14333.
http-port	HTTP port to forward HTTP requests to the healing server.
number	HTTP request forwarding port number (1-65535). The default is 80.
max-delay	Maximum wait for response.
seconds	Maximum delay in seconds (0-10).
misses	Duration of healing mode (misses).
number	Total number of misses (0-999) before healing mode is disabled.

The http cluster command modifies the healing mode parameters. The http cluster http-port command specifies the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster.

---

Note The default port number is 80. If you choose to configure a port other than 80, you must make sure that the port that is configured matches the port specified in the http proxy incoming command on healing servers in the farm. Otherwise, the healing client is not able to retrieve objects from the healing servers.

---

The http cluster heal-port command specifies the port number over which the healing client sends healing queries and the healing server sends healing responses. The default port number is 14333. If a port other than the default is configured, make sure that all Content Engines in the cluster use the same port. The http cluster misses command specifies the maximum number of misses that the healing Content Engine can receive from the cluster from the last healing mode hit response until the healing process is disabled. The default is 0 misses. The http cluster max-delay command specifies the maximum time in seconds that a healing Content Engine waits for a healing response from the cluster before considering the healing request a miss.

To enable the healing client, you should, at the least, configure the max-delay and misses options. The default port number for http-port is 80. If you use the default port, you do not have to configure http-port. The default port number for heal-port is 14333.

This example enables the healing mode feature by setting the HTTP port for forwarding HTTP requests to a healing server, setting the maximum delay to wait for a response from the cluster in seconds before considering the healing request a miss, and setting the maximum number of misses that the healing Content Engine can receive from the cluster before healing mode is disabled at the healing client.

ContentEngine(config)# http cluster http-port 8080 
ContentEngine(config)# http cluster max-delay 5

ContentEngine(config)# http cluster misses 5

To disable the healing client, you should, at the least, configure either the misses or max-delay option to 0, or you can use the no form of the http cluster misses and http cluster max-delay commands:

ContentEngine(config)# no http cluster misses

ContentEngine(config)# no http cluster max-delay

Configuring HTTPS-Related Parameters

Cisco ACNS 5.x software supports HTTPS in the following two scenarios:

•The Content Engine receives an HTTPS request sent by a web client configured to use the Content Engine as an HTTPS proxy server.

•The Content Engine in transparent mode intercepts a request sent by a web client to another HTTPS proxy server.

In both cases the Content Engine creates a connection to the origin server (directly or through another proxy server) and allows the web client and origin server to set up a Secure Socket Layer (SSL) tunnel through the Content Engine.

By configuring the Content Engine as an HTTPS server, it acts as a caching HTTPS proxy. This allows the Content Engine to cache content transmitted through the HTTPS protocol for the configured HTTPS servers.

---

Note In order to support HTTPS proxy requests, a DNS server must be configured (as described in the "Configuring DNS Servers for the DNS Caching Name Service" section).

---

Usage Guidelines and Examples

When configuring the Content Engine for HTTPS caching, note the following guidelines:

•Configuring the Content Engine to operate in HTTPS proxy mode enables the Content Engine to service HTTPS requests sent by the web clients, which have been configured to use an HTTPS proxy server.

•The HTTPS server is disabled by default. When the HTTPS server is enabled, the following default values apply:

–protocol version: sslv23-tlsv1

–serverauth: enabled

–serverauth ignore: none

–session cache size: 10000

–session cache timeout: 3600

–certgroup serverauth: many common public Certificate Authorities

•You can assign a certificate and associate a key with the HTTPS server assuming that you have configured the Content Engine with the https server global configuration command. The Content Engine presents the certificate to HTTPS clients that make requests to the HTTPS server.

•Use the https cert EXEC command to create certificates with a given name, to import a certificate from external sources, or to remove existing certificates.

•The https certgroup EXEC command allows you to create, remove, or form certificate groups. Certificate groups are formed to represent a trust relationship chain from root Certificate Authority to end entity. Each one of the certificates in a certificate group except the end entity's certificate signs and trusts the next one in the chain. An end entity's certificate can be trusted only if all certificates in the certificate group leading to this certificate can be trusted. A certificate group can be used to represent an HTTPS server just like a single certificate, but with the added benefit that the client does not need to have all certificates locally. A certificate group can also be used to verify and authenticate an HTTPS server by comparing the server's certificates to the certificate group.

•Use the https server name cert command and the https server name key command to configure a Content Engine to use a set of SSL certificates and keys that will enable the Content Engine to act as the origin HTTPS server. The Content Engine will be able to decode HTTPS traffic from a client and perform normal HTTP operations on it, such as caching and request processing. The Content Engine will be able to initiate HTTPS connections to an origin server and fetch content from origin servers upon cache miss (or cache validation).

Configuring HTTPS Proxy Settings Using the Content Engine GUI

To configure HTTPS proxy settings on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > HTTPS Proxy. The HTTPS Proxy window appears. (See Figure 10-9.)

Figure 10-9 HTTPS Proxy Window

Step 2 Click the Enable Incoming HTTPS Proxy On radio button to configure the Content Engine to accept proxy-style HTTPS requests on one or many ports.

Step 3 In the Incoming HTTPS Proxy Port list, enter the port numbers used by the proxy server to receive requests. The HTTPS proxy supports up to eight incoming ports. The port number can range from 1 to 65535.

---

Note In order to support HTTPS proxy requests, a DNS server must be configured (as described in the "Configuring DNS Servers for the DNS Caching Name Service" section).

---

Step 4 Use the Enable Outgoing HTTPS Proxy radio buttons to enable or disable the outgoing proxy option.

•To configure the Content Engine to direct all HTTPS traffic to a parent cache (without using ICP or WCCP), click the Enable Outgoing HTTPS Proxy On radio button.

•To disable the Content Engine from directing all HTTPS traffic to a parent cache, click the Enable Outgoing HTTPS Proxy Off radio button

Step 5 In the Outgoing HTTPS Proxy Address field, enter the IP address of the outgoing proxy server.

Step 6 In the Outgoing HTTPS Proxy Port field, enter the port number that the outgoing proxy server will use to accept proxy HTTPS requests.

Step 7 Specify the restrictions for an individual or all of the destination ports.

In order to prevent web clients from creating HTTPS tunnels to non-HTTPS servers, the destination ports can be restricted. The restrictions can be made for individual ports or for all ports. In case of a conflict in the restriction rules, the individual port setting takes precedence over the "all" rule, and the "allow" rule takes precedence over the "deny" rule.

---

Caution The Content Engine may not provide the desired level of security if the destination ports allow or deny policy has not been configured. Consequently, it is strongly recommended that you set restrictions that allow or deny HTTPS traffic to destination ports. Default settings may not provide the desired level of security.

---

•Use the List of Destination Ports allowed field to enter a list of individual destination ports to be allowed for HTTPS. Ports 443 and 563 are allowed by default. Enter all if all ports are to be allowed access.

•Use the List of Destination Ports denied field to specify a list of individual destination ports to be denied for HTTPS. Port numbers below port 1024 are denied by default. Enter all if all ports are to be denied access.

Step 8 Click Update to save the settings.

---

Note If specific requested content is to be cached, you must import the proper certificates and keys for these sites into the Content Engine and instruct the Content Engine to cache these sites. See the "Configuring Certificates and Private Keys for HTTPS Caching" section for information about how to use the CLI to configure the proper certificates and keys for the Content Engine.

---

---

Configuring HTTPS-Related Parameters Using CLI Commands

Table 10-12 lists the CLI commands associated with the HTTPS proxy features. The order in which the CLI commands are entered is not important.

Table 10-12 HTTPS Proxy Features and the Related CLI Command 

HTTPS Proxy Features	Related CLI Commands (Abbreviated Syntax)
Supports up to 8 incoming proxy ports.	https proxy incoming ports 1-65535, ports, . . .
Configures a WCCP service and an HTTPS incoming proxy on the same port. Shares the proxy port with transparent services.	https proxy incoming ports 1-65535 wccp custom-web-cache . . .
Denies unwanted access to any destination HTTPS port.	no https destination-port allow 443 563 https destination-port deny all
Configures an outgoing HTTPS proxy server, using global exclude option for HTTPS proxy.	proxy-protocols outgoing-proxy exclude list word https proxy outgoing host {hostname | ip_address} port 1-65535
Uses default outgoing HTTPS proxy, if available.	proxy-protocols transparent default-server
Uses outgoing HTTPS proxy server from an original request.	proxy-protocols transparent original-proxy
Returns the incoming HTTPS request to the sending client during a cache miss.	proxy-protocols transparent reset

The Content Engine acting as an HTTPS proxy server supports up to eight ports. It can share the ports with transparent-mode services and with HTTP. In proxy mode, the Content Engine accepts and services the HTTPS requests on the ports specified with the https proxy incoming command. All HTTPS requests on other proxy-mode ports are rejected in accordance with the error-handling settings on the Content Engine. In transparent mode, all HTTPS proxy-style requests intended for another HTTPS proxy server are accepted. The Content Engine acts on these transparently received requests in accordance with the proxy-protocols transparent command.

When the Content Engine is configured to use an HTTPS outgoing proxy with the https proxy outgoing host command, all incoming HTTPS requests are directed to this outgoing proxy. The proxy-protocols outgoing-proxy exclude command specifies a global proxy exclude domain effective for all proxy server protocols, including HTTPS.

The Content Engine applies the following logic when an outgoing proxy server is configured:

•If the destination server is specified by the global exclude option, then go directly to the destination server.

•If the destination server is not specified by the global exclude option and the request is HTTP, go directly to the destination server.

•If the destination server is not specified by the global exclude option, then go to the outgoing proxy server.

When a Content Engine intercepts a proxy request intended for another proxy server and there is no outgoing proxy configured for HTTPS, and the proxy-protocols transparent default-server command is invoked, the Content Engine addresses the request to the destination server directly and not to the client's intended proxy server. However, if the proxy-protocols transparent reset command is configured on the Content Engine and a cache miss occurs, all transparently intercepted requests sent by clients are returned to the client and requested objects are not delivered.

---

Tip For specific requested content is to be cached, you must import the proper certificates and keys for these sites into the Content Engine and instruct the Content Engine to cache these sites. For locally deployed Content Engines, this is performed through the CLI, as described in the "Configuring Certificates and Private Keys for HTTPS Caching" section.

---

The following shows how to configure the Content Engine as an HTTPS proxy server and have it accept HTTPS requests on port 8081. Only a single port is supported in the HTTPS protocol.

ContentEngine(config)# https proxy incoming 8081 

In the following example, the Content Engine is configured to forward HTTPS requests to an outgoing proxy server (10.1.1.1) on port 8880.

ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880 

In the following example, a domain name is excluded from being forwarded to an outgoing proxy server.

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

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

Configuring Certificates and Private Keys for HTTPS Caching

In ACNS 5.1 software, the CLI must be used to configure certificates and private keys for HTTPS caching; the Content Engine GUI does not currently support this configuration capability.

Use the https EXEC command to create, remove, and import certificates and private keys when using the Content Engine as an HTTPS server.

https {cert cert-name {add-cert | create | remove} | certgroup cert-name {create | import | remove} | key key_name {create | import | remove}}

Table 10-13 describes the parameters for the https EXEC command.

Table 10-13 Parameters for the https EXEC Command 

Parameter	Description
cert	Enables creating, removing, and importing certificates.
cert-name	Name of the certificate.
add-cert	Adds a certificate from an external source.
create	Defines the name for a certificate.
remove	Removes a certificate with a given name.
certgroup	Enables adding, creating, or removing a certificate group.
cert-name	Name of the certificate group.
import	Adds a chain of certificates to the certificate group.
create	Creates a certificate group with the specified name.
remove	Removes a certificate group with the specified name.
key	Enables creating, removing, and importing a private key.
key_name	Name of the public and private key pair.
create	Defines the name for a private key.
import	Imports a private key from an external source.
remove	Removes a key with a given name.

Content Engine Security

To prevent unwanted access to any destination HTTPS port when a request is going through the Content Engine, use the following command sequence:

no https destination-port allow 443 563

https destination-port deny all

This command sequence denies access to any port above and below 1024. Ports 443 and 563 (the standard HTTPS ports) must be explicitly denied access using the no https destination-port allow 443 563 command.

---

Tip TCP and UDP packets use port numbers defined by the application in use. Typically, the port range 0-255 is used for standard public applications such as FTP, and the port range 256-1023 is used by companies for nonstandard applications. For instance, FTP uses port 21, and Telnet uses port 23. Port numbers from 1024 through 65,536 are unregulated, so it is best to specifically deny access through any port number.

---

For example, when these commands are configured on the Content Engine and the request to access port xxx at banking.wellsfargo.com is redirected to this Content Engine, the connection to port xxx is denied. This configuration is valid either in the transparent deployment scenario, in which requests are redirected to the Content Engine, or in HTTPS proxy server mode, when the user makes the requests directly to the Content Engine.

HTTPS Statistics Reporting

Only connection statistics are reported. Because requests and responses are sent through the secure tunnel, the Content Engine is not able to identify the number of requests sent, or the number of bytes per request. Thus, the request and transaction per second (TPS) statistics are not available for HTTPS.

HTTPS Transaction Logging

The Content Engine logs HTTPS transactions in the transaction log in accordance with Squid syntax. One log entry is made for each HTTPS connection, though many transactions are performed per connection. The Content Engine is not aware of objects conveyed through the SSL tunnel, only the HTTPS server name.

HTTPS TCP Keepalives

When no keepalive messages are sent by the Content Engine to the clients and to the edge Content Engines, the connection is closed. In ACNS 5.1 software, the Content Engine can be forced to send keepalive probes by using the https tcp-rw-timeout global configuration command. When the HTTPS TCP keepalive feature is enabled, the Content Engine sends TCP keepalives on idle HTTPS TCP connections, using keepalive configuration parameters such as the TCP keepalive timeout, TCP keepalive probe count, and TCP keepalive probe interval.

Use the https tcp-rw-timeout timeout command to configure a maximum read/write timeout of 3600 seconds; that is, HTTPS keepalives are sent for the specified period. For HTTPS connections, the default timeout value is 5 minutes.

---

Note If specific requested content is to be cached, you must import the proper certificates and keys for these sites into the Content Engine and instruct the Content Engine to cache these sites.

---

Configuring the TFTP Server and Gateway

In ACSN 5.1 software, the TFTP gateway feature enables Content Engines to serve content files requested by networking devices that use native TFTP protocol. Content Engines now perform TFTP- to -HTTP or TFTP-to- FTP translation eliminating the need for the system administrator to configure and manage a dedicated TFTP server to serve TFTP requests. This feature allows the Content Engine to accept native TFTP requests from the client at the front end, and serve the request using HTTP or FTP protocol at the back end; hence, the feature is called the TFTP gateway.

Content files include router software images, router configurations, IP phone configuration files, and so forth. If the requested file is not available on the Content Engine, the Content Engine caches the file on the fly from the origin server. The ACNS caching system retrieves the file from the Internet on behalf of the device and forwards it to the device. Future requests by any devices for the same file are satisfied by forwarding the file from the Content Engine cache.

Using the TFTP Service and Gateway on Locally Deployed Content Engines

You can use the tftp-server command to configure the TFTP service and gateway on a locally deployed Content Engine to serve content in response to TFTP requests in two ways:

•Serve local content—To do this, configure local directories and enable the TFTP server on the Content Engine. For more information on this topic, see the next section ("Serving Local Content").

•Serve content from remote servers—To do this, configure the TFTP gateway feature on the Content Engine. For more information on this topic, see the "Using the TFTP Gateway to Serve Content from Remote Servers" section.

When both the TFTP server and gateway are enabled, the Content Engine responds to TFTP requests by searching for files in its default local directory if the full path name is not specified in the request. Otherwise, it looks in the local directory that matches the directory in the path name. If the file is not found, it forwards the request to the ACNS caching system using the HTTP or FTP protocol. If the file is found on a remote server, the Content Engine caches the file and sends the file to the client that issued the request. The Content Engine replies to subsequent requests for the file from its local cache. If the file is not found, the Content Engine replies to the request with a "File not found" message.

By default, the TFTP service is disabled and access to the TFTP server is denied.

The default local directory assigned to the TFTP server is /tftpboot. However, this directory must be created using the mkdir command.

The TFTP timeout value is fixed at 5 seconds and the number of retries is fixed at five retries. These values are nonconfigurable.

Serving Local Content

To serve requests for local content, follow these steps:

1. Use the inetd enable tftp global command to enable the TFTP service.

2. Configure the local TFTP directories on a locally deployed Content Engine, as follows:

a. Create the local directories using the mkdir command.

b. Identify the local directories to the TFTP server using the tftp-server dir command.

When you use the tftp-server dir command to identify one or more local directories, the first directory identified becomes the default directory. Enter the tftp-server dir command once for each directory that you want to identify.

The TFTP server searches for files without a fully qualified path name in its default directory. The TFTP server only looks for files in the other local directories if the TFTP request explicitly identifies the directory.

If you do not configure any local directories, /tftpboot is automatically assigned as the default directory. However, you would still need to create /tftpboot directory using the mkdir command before the TFTP server can serve requests.

Using the TFTP Gateway to Serve Content from Remote Servers

To serve content from remote servers, you must enable the TFTP server and also identify the remote servers to which the TFTP gateway (the locally deployed Content Engine) will direct requests. To identify the servers to which the Content Engine will direct requests when it cannot find the requested files in its local directories, use the tftp-server gw proto command. For more information on this topic, see the "Configuring the TFTP Server and Gateway" section.

---

Note For more background information about how the TFTF server and gateway operate, see the "How the TFTP Server and Gateway Work" section. For instructions on how to configure the Content Engine to operate as an TFTP server and gateway, see the "Configuring the TFTP Server and Gateway" section.

---

Enabling the TFTP Server and Gateway

To enable the TFTP server or gateway on a locally deployed Content Engine, follow these steps:

1. Use the inetd enable tftp global configuration command to enable the TFTP service.

2. Use the ip access-list global configuration command to define an access list that will permit access to the TFTP service.

3. Use the tftp-server access-list command to apply the access list to the TFTP application.

4. Use the different options of the tftp-server command to configure the TFTP server, as described in the next section.

---

Note The Content Engine does not support transparent TFTP requests. It only accepts TFTP requests that explicitly contain the Content Engine host name or IP address.

---

Configuring the TFTP Server and Gateway

The TFTP server searches for files in the default local directory when it receives a request that does not identify the full directory path to the file. If you do not configure any local directories, the default directory is /tftpboot. Although this directory is automatically assigned as the default directory, you still need to create it (or any other directories you assign to the TFTP server) using the mkdir command.

When you use the tftp-server dir command to identify one or more local directories, the first directory identified becomes the default directory. Enter the tftp-server dir command once for each directory that you want to identify.

The TFTP server only looks for files in the other directories if the TFTP request explicitly identifies the directory.

To configure the TFTP server and gateway on a locally deployed Content Engine, use the tftp-server global configuration command and follow these steps:

---

Step 1 Use the tftp-server dir command to identify one or more local directories that the Content Engine should search for requested files when the full path name is not included in the TFTP request.

tftp-server dir directory

For example, the following commands configure two local directories from which the Content Engine will try to fulfill TFTP requests:

ContentEngine(config)# mkdir /local/mydir

ContentEngine(config)# mkdir /local/clients

ContentEngine(config)# tftp-server dir /local/mydir

ContentEngine(config)# tftp-server dir /local/clients

The first directory specified, /local1/mydir, is considered the default directory.

Step 2 Use the tftp-server access-list command to identify the IP ACL that allows access to the TFTP server and gateway.

tftp-server access-list {acl-num | acl-name}

For example, configure the Content Engine to check access list 1 to determine if TFTP access should be allowed or denied.

ContentEngine(config)# tftp-server access-list 1

Step 3 Use the tftp-server gw proto global configuration command to enable the TFTP gateway feature and to identify specific servers to which TFTP requests will be directed to when the Content Engine cannot find the requested files in its local directories.

---

Note When you enter this command, you identify the protocol (FTP or HTTP), the hostname or IP address of the server, and the authentication information required to access each server. You can enter the tftp-server gw proto command twice to configure a primary and backup HTTP or FTP servers. Use the priority option to specify whether the server is primary (priority = 1) or backup (priority = 2).

---

tftp-server gw proto {ftp | http} server {hostname | ip_address} [name name passwd password] [path directory] pri priority

Table 10-14 describes the parameters for the tftp-server gw proto command.

Table 10-14 Parameters for the tftp-server gw proto Command 

Parameter	Description
gw	Configures gateway functionality for the Content Engine.
proto	Configures the protocol used to access the origin server to which the TFTP gateway will forward requests when the file cannot be found in a local directory.
ftp	Uses the FTP protocol to access the origin server.
http	Uses the HTTP protocol to access the origin server.
server	Configures the origin server.
hostname	Host name of the origin server.
ip-address	IP address of the origin server.
name	(Optional) Sets the username for authentication to the origin server.
name	(Optional) Username for authentication to the origin server.
passwd	(Optional) Sets the password for authentication to the origin server.
password	(Optional) Password for authentication to the origin server.
path	(Optional) Sets the path name to search for files on the origin server.
directory	(Optional) Path name to search for files on the origin server.
pri	Sets the priority of the origin server.
priority	Priority (1 or 2) of the origin server.

---

TFTP Server and Gateway Configuration Examples

This section provides some examples of configuring the TFTP server and gateway on a locally deployed Content Engine.

Example 1

The following command enables the TFTP server on the Content Engine.

ContentEngine(config)# inetd enable tftp

Example 2

The following commands define a standard access list that permits access to the TFTP service for FTP clients on the 192.168.1.0 subnetwork.

ContentEngine(config)# ip access-list standard 1

ContentEngine(config-std-nacl)# ip access-list permit 192.168.1.0 0.0.0.255

ContentEngine(config-std-nacl)# exit

Example 3

The following commands configure two local directories from which the Content Engine will try to fulfill TFTP requests.

ContentEngine(config)# tftp-server dir /local1/mydir

ContentEngine(config)# tftp-server dir /local1/clients

The first directory specified, /local1/mydir, is considered the default directory.

Example 4

The following command identifies the IP access list that permits access to the TFTP service.

ContentEngine(config)# tftp-server access-list 1

Example 5

The following command enables the TFTP gateway feature on the Content Engine, identifies the FTP server that the Content Engine should forward requests to when it cannot find the file in its local directories, and sets the username and password for authentication to the origin server.

ContentEngine(config)# tftp-server gw proto ftp 192.168.100.1 pri 1 path /myremotedir name 
myuser passwd mypassword

The directory name, /myremotedir, is used in the URL sent by the ACNS caching service on the Content Engine to retrieve the file from the remote server. The URL formed by using this example configuration would be as follows:

ftp://myuser:mypasswd@192.168.100.1/myremotedir/requested-file-name

Configuring ICP Settings

Internet Cache Protocol (ICP) is a lightweight message format used for communicating among Content Engines and for supporting interoperability with older proxy protocols. ICP is used to exchange hints about the existence of URLs in neighboring caches in a Content Engine farm. Content Engines exchange ICP queries and replies to gather information for use in selecting the most appropriate location from which to retrieve an object.

Although ICP has traditionally been a way to scale the overall size of a cluster of caches beyond a single unit, history has shown ICP to be a poor way of scaling a cache clustering solution. In fact, because of the way that traffic is currently directed toward a transparent network cache cluster, the requirement for ICP is all but negated for the majority of cache deployments.

The ICPv2 protocol is documented in two standards documents:

•RFC 2186: Internet Cache Protocol (ICP), Version 2

•RFC 2187: Application of Internet Cache Protocol (ICP), Version 2

---

Note The ability to act as both an ICP server (servicing requests from neighboring caches) and an ICP client (sending requests to neighboring caches) is supported.

---

You can use the Content Engine GUI or CLI to configure ICP settings on a locally deployed Content Engine. The following example shows how to use the CLI to restrict ICP parent and sibling to specific domain sets:

ContentEngine(config)# icp client add-remote-server 10.1.1.1 parent icp-port 3130 
http-port 3128 domain_x.com domain_y.com domain_z.com

ContentEngine(config)# icp client add-remote-server 10.1.1.1 sibling icp-port 3130 
http-port 3128 domain_a.com domain_b.com domain_c.com

ContentEngine(config)# icp client enable

ContentEngine(config)#

Configuring ICP Client Settings

You can configure your Content Engine farm to generate ICP queries before retrieving requested objects from the Internet using ICP client functionality. With ICP functionality, you can configure parent and sibling Content Engines in a hierarchy. ICP parents are essentially one step higher than ICP siblings in a hierarchy of Content Engines.

You can configure a Content Engine to be either a parent or a sibling.

•Parent Content Engines are able to retrieve data during a cache miss.

•Sibling Content Engines cannot retrieve data and instead forward the request to the parent Content Engines.

Configuring ICP Client Settings Using the Content Engine GUI

To configure ICP client functionality on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > ICP Client. The ICP Client window appears. (See Figure 10-10.)

Figure 10-10 ICP Client Window

Step 2 Click the Enable ICP Client On radio button to enable ICP client queries.

Step 3 In the Max wait for replies field, specify a value (in seconds) for the timeout period for ICP responses. The range is from 1 to 30 seconds, and the default value is 2 seconds.

Step 4 In the Remove from wait-list field, specify the number of failures that each Content Engine allows an unresponsive ICP server before it removes that ICP server from the list. The range is from 0 to 100, and the default value is 20 failures.

Step 5 In the Do not IPC these Domains field, enter a domain to be excluded from ICP queries. Objects requested from domains listed here will never generate ICP requests.

Step 6 Click Update to save the settings.

Step 7 You can also use this window to add an ICP server as follows:

a. Enter the IP address or host name of the ICP server in the ICP Servers field.

b. Select whether this ICP server is a parent cache (check the Parent check box) or a sibling cache (uncheck the Parent check box). Sibling caches will not retrieve data on a cache miss, whereas parent caches will.

c. Enter the ICP port number to which ICP queries will be directed at this cache. The range is from 1 to 65535, and the default port is 3130.

d. Enter the HTTP port number to which proxy-style requests will be forwarded. The range is from 1 to 65535, and the default port is 3128.

e. If you want to limit ICP requests directed toward this Content Engine to a specific set of domains, enter those domains in the Use only for these domains field. Otherwise, all ICP requests (aside from those specified as local domains) will be forwarded to this ICP server.

Step 8 When you are finished, click Update again.

When the ICP Client window refreshes, it will display the ICP servers you just added.

---

Configuring ICP Client Settings Using CLI Commands

Use the icp client global configuration commands to establish and configure the ICP client functionality on a locally deployed Content Engine. Configurations made without enabling ICP functionality are stored within the configuration until removed.

Use Table 10-15 to help you configure the ICP client using the icp client global configuration command

Table 10-15 icp client Command Summary 

Command	Purpose
icp client enable	Enables the ICP client.
icp client add-remote-server	Adds a remote ICP client server.
icp client exclude	Excludes ICP client local domains.
icp client max-fail	Sets maximum number of retries allowed.
icp client max-wait	Configures how long the Content Engine waits before retrieving the requested data directly from the Internet.
icp client modify-remote-server	Modifies the ICP client remote server parameters.

The following example restricts ICP parent and sibling to specific domain sets.

ContentEngine(config)# icp client add-remote-server 172.16.0.0 parent icp-port 3130 
http-port 3128 domain_x.com domain_y.com domain_z.com

ContentEngine(config)# icp client add-remote-server 172.16.0.0 sibling icp-port 3130 
http-port 3128 domain_a.com domain_b.com domain_c.com

ContentEngine(config)# icp client enable

Icp Client started 

Configuring ICP Server Settings

You can also configure a locally deployed Content Engine to act as an ICP server. This allows the Content Engine to probe the hierarchy of Content Engines by multicasting an ICP message to ICP parent and sibling clients in the hierarchy.

Configuring ICP Server Settings Using the Content Engine GUI

To configure a locally deployed Content Engine to act as an ICP server, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > ICP Server. The ICP Server window appears. (See Figure 10-11.)

Figure 10-11 ICP Server Window

Step 2 Click the Enable ICP Server On radio button to enable ICP server queries.

Step 3 In the ICP Port field, specify the ICP port number on which the Content Engine will listen for ICP requests. The range is from 1 to 65535, and the default is port 3130.

Step 4 In the HTTP Port field, specify the port number on which the Content Engine will listen for ICP-generated requests. The range is from 1 to 65535, and the default is port 3128.

Step 5 Click Update to save the settings.

Step 6 You can also use this window to add, delete, or modify a valid ICP client as follows:

a. Enter the IP address or host name of the ICP client in the Valid ICP Clients field.

b. To configure the Content Engine to act as a parent server to the designated ICP client, check the check box under the Fetch Misses column. If the Content Engine cannot satisfy the client's request, it forwards the request to another server or the Internet.

c. To configure the Content Engine to act as a sibling server, uncheck the check box under the Fetch Misses column. When the Content Engine cannot satisfy the client's request, it sends a failed response message back to the client.

Step 7 When you are finished, click Update again.

When the ICP Server window refreshes, it will display the ICP clients you just added.

---

Configuring ICP Server Settings Using CLI Commands

Use the icp server global configuration commands to establish and configure the ICP server functionality of the Content Engine. Configurations made without enabling ICP functionality are stored within the configuration until removed.

Use Table 10-16 to help you configure the ICP server parameters using the icp server global configuration command.

Table 10-16 icp server Command Summary 

Command	Purpose
icp server enable	Enables the ICP server.
icp server http-port	Configures the HTTP proxy port to listen for ICP-generated requests. The range is from 0 to 65535. The default port number is 3128.
icp server port	Configures the ICP server port on a Content Engine to listen for ICP requests. The range is from 0 to 65535. The default port number is 3130.

Configuring WCCP Settings

This section describes how to configure WCCP settings on a locally deployed Content Engine to enable transparent caching services on the Content Engine.

---

Note For more information about transparent caching through WCCP, see "Transparent Caching." For detailed information about WCCP Version 1 and Version 2, see "Web Cache Communication Protocol Version 1" and "Web Cache Communication Protocol Version 2."

---

Enabling WCCP on a Content Engine

To enable WCCP Version 1 or Version 2 on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose WCCP > Enable WCCP. The Enable WCCP window appears. (See Figure 10-12.)

Figure 10-12 Enable WCCP Window

Step 2 Choose the version of WCCP that you wish to enable on the Content Engine based on which WCCP services you want to run on this Content Engine:

•Click the Version 1 radio button to enable WCCP Version 1.

•Click the Version 2 radio button to enable WCCP Version 2.

The Content Engine must be running WCCP Version 2 to support the cache-related services listed in Table 10-17 other than the web cache services (service group 0) which is supported by Version 1 and Version 2.

Table 10-17 WCCP Service Groups 

Service Group Number	Description of Services
0	Web cache
80	HTTP, RTSP
81	MMST
82	MMSU
90-97	User-configurable
98	Custom
99	Reverse proxy

---

Note All service group numbers listed in Table 10-17 except for web cache service (service group 0) require WCCP Version 2. For more information about WCCP Version 1 and Version 2, respectively see "Web Cache Communication Protocol Version 1" and "Web Cache Communication Protocol Version 2."

---

Step 3 If you clicked the Version 1 radio button, follow these steps:

a. In the Home Router field, enter the IP address of the designated home router. This can also be the address of the default gateway.

b. Click Update to save the WWCP Version 1 settings on the Content Engine.

---

Tip With WCCP Version 1, only a single router services a cluster, becoming the default home router for the cluster. For more information about enabling the web caching service with WCCP Version 1, see "Web Cache Communication Protocol Version 1."

---

Step 4 If you clicked the Version 2 radio button, follow these steps:

a. In the Wait for Clean shutdown field, specify the maximum period of time (in seconds) that the Content Engine will wait while releasing all WCCP Version 2 connections. When you enter the reload command, the Content Engine will not reboot until either all connections have been serviced, or the configured wait time has elapsed. Valid values are 0 to 1 day (86,400 seconds). The default value is 2 minutes (120 seconds).

b. In the Routers List fields, create a list of routers that will support a specific WCCP service used on this Content Engine and these WCCP-enabled routers. In the Router List fields, enter the IP address or multicast address of every router that will redirect traffic to this Content Engine for a particular service. If different routers will be used for different services, it is necessary to create more than one router list. You must specify the designated router list for each service in each of the following Content Engine GUI windows: the Web Cache window (WCCP > Web Cache), the Reverse Proxy window (WCCP > Reverse Proxy), the Custom Web Cache window (WCCP > Custom Web Cache), and the WCCP Services window (WCCP > Services).

c. In the Port Lists field, create a port list for each WCCP service that will be supported.

---

Tip Version 2 provides generic WCCP services (numbered from 90 to 97) that support multiple ports (up to eight per WCCP service). In order to configure them, it is necessary to create one port list for each WCCP service that will be used. A port list can have up to eight ports.

---

d. Click Update to save the WCCP Version 2 settings.

After enabling WCCP Version 2 on the Content Engine and defining router lists, you must enable the specific WCCP services on the Content Engine and the WCCP-enabled routers that will be supporting that particular WCCP service.

WCCP Version 2 must also be enabled on the routers listed in the router lists. If WCCP Version 2 is not enabled on these routers, enable WCCP on each router by completing the steps described in the "Configuring WCCP Version 2 Services Using CLI Commands" section. You must also enable the specified WCCP service on the WCCP version 2 routers listed in a particular router list that has been associated with a specific WCCP service.

---

Enabling WCCP Version 2 Services on a Content Engine

After enabling WCCP Version 2 on the Content Engine and defining your lists of WCCP-enabled routers (as described in the "Enabling WCCP on a Content Engine" section), you must enable the specific WCCP services on the Content Engine and indicate which list of routers will be supporting that particular WCCP service.

---

Note For a list of WCCP Version 2 services, see Table C-1.

---

This section provides an example of how to enable the web caching service using WCCP 2 so that more than one router can be used to support this service. For more information about deploying the various WCCP services, see "Transparent Caching."

Enabling WCCP Version 2 Services on a Content Engine Using the Content Engine GUI

To configure the WCCP Version 2 web caching service on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose WCCP > Web Cache. The Web Cache window appears. (See Figure 10-13.)

Figure 10-13 Web Cache Window

Step 2 Click the Enable On button to enable the web cache service on this Content Engine.

Step 3 From the Router List drop-down list, choose the number of the router list that you wish to associate with this service.

Step 4 In the Password field, enter a password that allows a shared secret password to be used for authentication within the service. To enable the Content Engine with a secret password, enter the password in this field.

---

Tip Be sure that all routers and other Content Engines within the environment are configured with the same secret password.

---

Step 5 Use the Weight field to enable manual control of load balancing. Values can be between 0 to 100 percent. The value assigned to each Content Engine represents a direct percentage of load redirected (a weight of 30 will receive 30 percent of the total load). However, if the sum total of all weight values assigned within a caching cluster is greater than 100, load assignment will be based on a percentage of this total.

Step 6 Notice the information in the following read-only fields.

•The Service ID field specifies the type of WCCP service in use. In this case, the Service ID is web-cache. This same value must be enabled on the routers.

•In the Port field, the outgoing port destinations of all traffic redirected to the Content Engine. In this case, port 80.

•The Hashing field specifies how traffic should be load balanced between multiple Content Engines. In this case, it is by destination IP.

•The Protocol field specifies the type of traffic to be redirected to the cache. In this case, the protocol used for web caching is HTTP.

Step 7 Check the L2 Redirect Yes check box if you wish to enable packet forwarding by Layer 2 redirection.

Step 8 Click Update.

---

Now that you have enabled the web caching service on the Content Engine, the next step is to enable it on the designated list of routers. You must use the CLI to perform this task, as described in the next section.

Configuring WCCP Version 2 Services Using CLI Commands

You can use the CLI to enable a WCCP Version 2 service on the Content Engine as well as the router. To enable WCCP Version 2 services on a router, you must use the CLI. Use the wccp global configuration commands to enable WCCP on a Content Engine. Use the ip wccp global configuration commands to enable WCCP on a router.

The following is an example of how to use the CLI to configure the router and the Content Engine for web cache service when the clients and Content Engine are on the same subnet.

	Purpose	Command
Step 1	Ensures that WCCP Version 2 is enabled on each router in the router list.	Router(config)# ip wccp version 2
Step 2	Configures the web cache service on the router.	Router(config)# ip wccp web-cache
Step 3	Enables WCCP Version 2 on the Content Engine.	ContentEngine(config)# wccp version 2
Step 4	Configures the web cache service on the Content Engine. a. Configures a router list for the web cache service. b. Configures the web cache service on the Content Engine and associates it with the router list you just created (for example, router-list 1). This command also informs the routers in the specified router list that this Content Engine is accepting the web cache service.	ContentEngine(config)# wccp router-list 1 10.10.10.1 ContentEngine(config)# wccp web-cache router-list-num 1
Step 5	Configures the web cache service, associates it with the router list created in Step 2, and assigns the Layer 2 redirection option. If the mask assignment method is not specified, the default load-balancing method is the hash assignment method.	ContentEngine(config)# wccp web-cache router-list-num 1 l2-redirect
Step 6	Exits global configuration mode.	ContentEngine(config)# exit
Step 7	Writes running configurations to nonvolatile memory.	ContentEngine# write memory

Configuring Bypass Settings

One of the fundamental principles of transparent network request redirection and the caching solution is that the Content Engine must remain transparent to the end user at all times. A transparent caching solution in an ACNS network environment must not introduce any possible failure conditions or side effects in the network.

The Cisco ACNS transparent caching solution uses a WCCP-enabled router and various advanced techniques to ensure that the Content Engine remains transparent, even if web browsers are nonoperational or web servers are not HTTP-compliant. One of these techniques is bypass feature.

Bypass refers to a method that the Content Engine can use to handle various error responses (including authentication failure) from an origin server. When the Content Engine receives an error response from an origin server, it adds an entry for the server to its bypass list. When it receives subsequent requests for content residing on the bypassed server, it redirects packets to the bypass gateway. If no bypass gateway is configured, then the packets are returned to the redirecting Layer 4 switch.

If both WCCP Version 2 and a Layer 4 switch are configured then requests redirected to the Content Engine by WCCP are bypassed to the redirecting WCCPv2 router. Requests redirected to the Content Engine by the Layer 4 switch are redirected to the bypass gateway. Thus the Content Engine can differentiate between requests arriving due to WCCP and due to the Layer 4 switch.

Bypass features can be used with a WCCP Version 2 router or with a Layer 4 switch, such as the Cisco Content Switching Module or Cisco Content Services switch. The Content Engine cannot set up a bypass for proxy-style requests.

The Content Engine can be configured to support the following:

•Static bypass

•Load bypass

•Authentication bypass

---

Note The bypass feature is only available when WCCP Version 2 is enabled in your local network. The Content Engine can only bypass WCP-redirected traffic and not proxy-style requests.

---

Configuring Static Bypass

The static bypass feature permits traffic from specified sources to bypass the Content Engine. The types of traffic sources are as follows:

•Specific web client to a specific web server

•Specific web client to any web server

•Any web client to a specific web server

Use the bypass static global configuration command to enable and configure the static bypass feature on a locally deployed Content Engine.

bypass static {clientip | any-client} {serverip | any-server}

---

Note You must not exceed 50 bypass list entries for any one Content Engine.

---

Table 10-18 describes the bypass static command options.

Table 10-18 bypass static Command Parameters 

Parameter	Description
static	Adds a static entry to the bypass list.
clientip	IP address from which requests will bypass the Content Engine. Wildcards are not supported.
serverip	IP address to which requests will bypass the Content Engine. Wildcards are not supported.
any-server	Requests from a specified client to any server bypass the Content Engine.
any-client	Bypasses HTTP traffic from any client destined to a particular server.

---

Note To clear all static configuration lists on a Content Engine, use the no form of the bypass static command.

---

The following are some examples of how to use the bypass static command to configure the static bypass feature.

Example 1

This example forces HTTP traffic from a specified client to a specified server to bypass the Content Engine.

ContentEngine(config)# bypass static 10.1.17.1 172.16.7.52

Example 2

This example forces all HTTP traffic destined to a specified server to bypass the Content Engine.

ContentEngine(config)# bypass static any-client 172.16.7.52

Example 3

This example forces all HTTP traffic from a specified client to any web server to bypass the Content Engine.

ContentEngine(config)# bypass static 10.1.17.1 any-server

Configuring Load Bypass

When the Content Engine is overloaded and the load bypass option is enabled, the Content Engine bypasses a bucket and reroutes the overload traffic. If the load remains too high, another bucket is bypassed, and so on until the Content Engine can handle the load. (See Figure 10-14.)

Figure 10-14 Overload Bypass

---

Note A bucket is defined as a certain subsection of the allotted hash assigned to each Content Engine in a Content Engine farm. If only one Content Engine exists in this environment, it has 256 buckets assigned to it.

---

When the first bucket bypass occurs, a time interval must elapse before the Content Engine begins to again service the bypassed buckets. The duration of this interval is set to 10 minutes by default.

When the Content Engine begins to service the bypassed traffic again, it begins with a single bypassed bucket. If the load is serviceable, the Content Engine picks up another bypassed bucket, and so on. The time interval between picking up one bucket and the next is set to 60 seconds by default.

Configuring Load Bypass Using the Content Engine GUI

To configure load bypass on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Bypass. The Bypass window appears. (See Figure 10-15.)

Figure 10-15 Bypass Window

Step 2 Click the Load Bypass On radio button to enable load bypass.

Step 3 In the Time interval between bypassing buckets field, specify a value (in seconds) for the interval between bypassing buckets.

When the Content Engine is overwhelmed with traffic and the bypass option is enabled, it bypasses traffic one bucket at a time until it is no longer overloaded. This field represents the amount of time between the bypassing of one bucket and the next. The default value is 4 seconds.

Step 4 In the Time that a bucket is bypassed field, specify a value (in minutes).

Once a bucket is bypassed and the Content Engine remains in bypass mode, it does not attempt to pick up the bypassed load for the number of minutes specified in this field. The default value is 10 minutes.

Step 5 In the Time interval between buckets coming back field, specify a value (in seconds) for the time interval between buckets coming back.

Once the time interval allotted to bypass mode has been surpassed, the Content Engine begins to pick up bypassed traffic one bucket at a time. The time between the pickup of each bucket is measured in seconds. The default value is 2 seconds.

Step 6 Click Update to save the settings.

---

Configuring Load Bypass Using CLI Commands

Use the bypass load global configuration command to enable and configure the load bypass feature on a locally deployed Content Engine.

bypass load {enable | in-interval seconds | out-interval seconds | time-interval minutes}

Table 10-19 describes the bypass load command options.

Table 10-19 bypass load Command Parameters 

Parameter	Description
load	Adds a static entry to the bypass list.
enable	Enables load bypass.
in-interval	Sets time interval between buckets coming back.
seconds	Time in seconds (2-600). The default is 60 seconds.
out-interval	Sets time interval between bypassing buckets.
seconds	Time in seconds (4-600). The default is 4 seconds.
time-interval	Sets time interval between one bucket being bypassed and the next.
minutes	Time in minutes (1-1440). The default is 10 minutes.

Configuring Authentication Bypass

Because of IP authentication, some websites do not allow the Content Engine to connect directly on behalf of the client. In order to preserve cache transparency and avoid disruption of service, the Content Engine can use authentication traffic bypass to automatically generate a dynamic access list for the selected client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in the case of hierarchical caching.

Configuring Authentication Bypass Using the Content Engine GUI

To configure authentication bypass on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Bypass. The Bypass window appears. (See Figure 10-15.)

Step 2 Click the Authentication Bypass On radio button to enable authentication bypass.

---

Tip Some websites may not allow the Content Engine to connect directly on behalf of the client. In order to avoid a disruption of service when traffic is bypassed, the Content Engine can use authentication bypass to generate a dynamic access list for these client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in an ACNS network environment.

---

Step 3 In the Bypass entry Expiration Time field, specify a value (in minutes) to set the number of minutes that an idle client/server pair remains on the bypass access list. The default value is 20 minutes.

Step 4 Click Update to save the settings.

---

Configuring Authentication Bypass Using CLI Commands

Use the bypass auth-traffic and bypass gateway global configuration commands to enable and configure the authentication bypass feature on a locally deployed Content Engine.

bypass {auth-traffic enable | gateway ipaddress | timer minutes}

Table 10-20 describes the bypass auth-traffic and bypass gateway command options.

Table 10-20 Authentication Bypass Command Parameters 

Parameter	Description
auth-traffic	Sets authenticated traffic bypass configuration.
enable	Enables authenticated bypass.
gateway	Configures a router to which bypassed packets are redirected when the Content Engine receives requests redirected by a Layer 4 switch.
ipaddress	IP address of the router acting as the bypass gateway.
timer	Sets authentication bypass timer in minutes. The bypass entry is removed from the dynamic list when the timer expires.
minutes	Time in minutes (1-1440).

This example forces all authenticated HTTP traffic to bypass the Content Engine for 24 hours.

ContentEngine(config)# bypass auth-traffic enable

ContentEngine(config)# bypass timer 1440 

To identify the router to which the Content Engine will direct responses when errors are received from the origin server, use the bypass gateway command. Replace ipaddress with the IP address of a router that is a Layer 2 neighbor of the Content Engine. (To enable bypass with a Layer 4 switch, use the http l4 switch enable command.)