Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.4 - Chapter 8: Configuring Caching Services [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring Caching Services

Content Engine Proxy Caching Overview

Network Protocols and Caching

Configuring HTTP Settings

Configuring HTTP Connection Settings

Configuring HTTP Cache Settings

Configuring HTTP Cache Freshness Settings

Configuring Authenticated HTTP Cache Settings

Specifying a Reauthentication Interval

Configuring Advanced HTTP Cache Settings

Adding or Modifying Additional HTTP Request Methods for the Content Engine

Configuring HTTP Cache Vary User Agent

Configuring HTTP Destination Port Restrictions

Configuring HTTPS Settings

Configuring HTTPS Certificates

Filtering HTTPS Certificates for the Content Engine

Configuring HTTPS Certificate Groups

Filtering HTTPS Certificate Groups for the Content Engine

Configuring HTTPS Keys

Filtering HTTPS Keys for the Content Engine

Configuring HTTPS Proxy Settings

Configuring HTTPS Servers

Filtering HTTPS Servers for the Content Engine

Transparent HTTPS Caching Using SSL

Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings

Configuring FTP Settings

FTP-over-HTTP Caching

Configuring FTP-Over-HTTP Connection Settings

Configuring FTP-Over-HTTP Cache Freshness

Native FTP Caching

Configuring the Content Engine for Transparent Native FTP Caching

Configuring Native FTP Connections

Configuring the Client Side of Nontransparent Native FTP Caching

Configuring Native FTP Cache Freshness

Enabling Inetd FTP Service

Configuring Native FTP Custom Messages

About Writing FTP Custom Welcome Messages

Configuring FTP Message Download Settings

Viewing the Content Engine FTP Message Configurations

Resetting a Native FTP Custom Message

Configuring Native FTP Custom Message Upload Settings

Configuring TFTP Settings

Configuring TFTP General Settings

Configuring TFTP Proxy Server Settings

Configuring TFTP Directory Settings

Configuring DNS Caching Name Service for WCCP Transparent Caching

Configuring DNS Caching Server Settings for the Content Engine

Cacheable Resource Records in the Content Engine DNS Cache

Configuring DNS Server Bindings for the Content Engine

Configuring DNS Address Record Mappings for the Content Engine

Configuring DNS Canonical Name Record Mappings for the Content Engine

Configuring the DNS Server for HTTP Proxy Caching

Configuring ICP Settings

ICP Client Settings

ICP Remote Client Settings

ICP Server Settings

ICP Remote Server Settings

Configuring Caching Services

This chapter describes how to configure conventional caching services (HTTP, FTP [FTP-over-HTTP caching and native FTP caching], HTTPS, and DNS caching) for centrally managed Content Engines. It also describes how to configure the TFTP gateway, and the Internet Cache Protocol (ICP) for the Content Engine and device groups. This chapter includes the following sections:

•Content Engine Proxy Caching Overview

•Configuring HTTP Settings

•Configuring HTTPS Settings

•Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings

•Configuring FTP Settings

•Configuring TFTP Settings

•Configuring DNS Caching Name Service for WCCP Transparent Caching

•Configuring the DNS Server for HTTP Proxy Caching

•Configuring ICP Settings

Content Engine Proxy Caching Overview

Caching is the ability to store web objects for later retrieval. Caching services are generally associated with the type of routing method being used, such as direct proxy routing or transparent redirection.

Caching services that are associated with direct proxy routing are said to be deployed in nontransparent mode. Nontransparent mode caching is described as nontransparent forward proxy caching. Proxy caching in nontransparent mode in an ACNS network is handled by the Content Engine, which acts as a forward proxy server. In deployments that use direct proxy routing to route content requests to the Content Engine, the Content Engine acts as a network gateway device that retrieves content on behalf of web clients.

Caching services that are associated with transparent redirection routing are said to be deployed in transparent mode. Proxy caching in transparent mode in an ACNS network is handled by Content Engines that are configured for WCCP caching services in conjunction with a WCCP-enabled router or Layer 4 switch. Transparent mode caching is described as transparent forward proxy caching or transparent reverse proxy caching, depending on the placement of the Content Engine in the network. The Content Engine can serve as a transparent proxy server to web clients; in which case, the Content Engine is acting as a transparent forward proxy server. Or, the Content Engine can serve as a proxy for a web server or group of web servers (for example web servers in a server farm at a company headquarters); in which case, the Content Engine is acting as a transparent reverse proxy server.

Network Protocols and Caching

The interaction between a web browser (web client) and a web server uses the existing standard application-layer Internet protocols, such as HTTP, Hypertext Protocol Secure (HTTPS), and File Transfer Protocol (FTP). The Content Engine must support these standard protocols to receive, cache, and send web content. Support for HTTP, FTP, TFTP, and HTTPS protocols is included as part of the ACNS software product.

Note Protocols commonly used for streaming content, such as Microsoft Media Server (MMS) protocol and RealNetworks RTSP protocol, are discussed in Chapter 9, "Configuring Streaming Media Services."

The Content Engine services any protocols for which it has been configured. If the Content Engine is not configured to support a certain protocol, the Content Engine returns an error. For example, if port 8080 is configured for HTTP and HTTPS, an FTP request coming to this port is rejected.

The Content Engine supports up to eight incoming ports each for FTP, HTTPS, HTTP, MMS, and RTSP nontransparent mode caching services. 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 operating on the Content Engine or on other Content Engines in the network.

TCP ports reserved for system or network services should not be used for proxy caching services (for example, DNS or FTP). In transparent mode, if more than eight ports for a protocol are required, the administrator can configure multiple dynamic WCCP services. Intercepted FTP, HTTP, and HTTPS requests addressed to other proxy servers (received on transparent mode ports) are serviced according to the proxy-protocols transparent command parameters.

Configuring HTTP Settings

You can configure, modify, and view HTTP settings for Content Engines and device groups by completing the following tasks:

•Configuring HTTP Connection Settings

•Configuring HTTP Cache Settings

•Configuring HTTP Cache Freshness Settings

•Configuring Authenticated HTTP Cache Settings

•Configuring Advanced HTTP Cache Settings

•Adding or Modifying Additional HTTP Request Methods for the Content Engine

•Configuring HTTP Cache Vary User Agent

Configuring HTTP Connection Settings

To configure HTTP connection settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose Applications > Web > HTTP > HTTP Connections. The HTTP Connection Settings for Content Engine window appears. (See Figure 8-1.) Table 8-1 describes the fields in this window.

Figure 8-1 HTTP Connection Settings Window

Step 4 To accept incoming requests on ports in addition to port 80, check the Enable Incoming Proxy check box.

Step 5 In the List of Incoming Ports field, enter the port numbers used by the proxy server or Content Engine to receive requests. Separate port numbers with a space.

Step 6 To allow an outgoing proxy server or another Content Engine to receive HTTP cache miss request traffic, check the Enable Outgoing Proxy check box.

Step 7 To preserve HTTP authentication header 407 by sending header 407 to the client when asking the client for Internet proxy authentication credentials, check the Preserve 407 headers check box.

If you are connected to the Content Engine in transparent mode, and you preserve 407 error codes by checking this check box, your browser will not recognize the 407 error codes. By default, the Content Engine strips the hop-to-hop 407 (Proxy Authentication Required) error code sent by the Internet proxy.

Step 8 To direct requests to the origin server specified in the user request if all outgoing proxy servers fail, check the Use Origin Server check box.

Step 9 In the Outgoing Connection Timeout field, enter a value in microseconds for the timeout period to use when probing for outgoing proxy servers.

Step 10 In the Outgoing Monitor Period field, enter an interval (in seconds) for monitoring an outgoing proxy server. This is the time period over which the outgoing proxy servers are queried. If one of the outgoing proxy servers is unavailable, the polling mechanism waits for the connection timeout before polling the next server.

Step 11 Configure the outgoing proxy:

a. Enter the host name or IP address for the outgoing proxy host names in the Hostname field under the Outgoing Proxy heading.

The first host name or IP address entered designates that outgoing proxy server as the primary server. You can configure up to eight backup proxy servers for the HTTP proxy failover feature. If the primary proxy server fails to respond to the HTTP connection request, the request is redirected to the next proxy server in the list until one of the proxy servers services the request.

b. In the Port field, enter a port number that corresponds to the outgoing proxy host names from the previous step. (A port is required for the primary server entered in the Hostname field.)

Step 12 If a root Content Engine is configured to receive content through a proxy server, the acquirer operating on the root Content Engine must be authenticated by the proxy server before it can obtain content from the origin server. To configure outgoing proxy authentication for the acquirer, follow these steps:

a. In the Username field, enter the name of the user to be authenticated. This username will be used for both NTLM and basic authentication.

b. In the Password field, enter the password of the user. Reenter the same password in the Confirm Password field for confirmation. The password details will be encrypted on display.

c. In the NTLM User Domain field, enter the NTLM server domain name to be used to authenticate user access.

d. To disallow removal of NTLM headers for fallback to basic authentication, check the Disable basic authentication check box.

ACNS software supports multiple proxies; therefore, you can set the proxy authentication information for multiple proxies as well.

Step 13 To save the settings, click Submit.

A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or group settings to change the current device settings but have not yet submitted the changes.

Table 8-1 HTTP Connection Settings

GUI Parameter

Function

CLI Command or Manifest Attribute

Enable Incoming Proxy

Configures the Content Engine to accept incoming requests on ports in addition to port 80.

http proxy incoming

Space separated list of incoming HTTP ports

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

Enable Outgoing Proxy

Configures an outgoing proxy server or another Content Engine to receive HTTP cache miss request traffic without using ICP or WCCP.

http proxy outgoing

Preserve 407 headers

Preserves 407 HTTP authentication headers. These headers indicate that the client must first authenticate itself with the proxy server to request cache miss traffic.

http proxy outgoing preserve-407

Use Origin Server

When enabled, handles requests using 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

Outgoing Connection Timeout

Timeout period (in microseconds) to use when probing for outgoing proxy servers. The range is from 200 to 5000000. The default value is 300 microseconds.

http proxy outgoing connection-timeout microsecs

Outgoing Monitor Period

Specifies the interval in seconds at which to monitor one outgoing proxy server. If multiple outgoing proxy servers are configured, they are monitored sequentially. The default value is 200 seconds.

http proxy outgoing monitor seconds

Outgoing Proxy

Hostname

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} port 1-65535

Acquirer Outgoing Proxy Authentication

Note These settings can also be defined in the manifest file. (See Chapter 6, "Configuring the ACNS Network for Content Acquisition.")

Username

Configures the name of the user to be authenticated.

Manifest file attribute:

user

Password

Configures the user password.

password

Confirm Password

Confirms the user password.

NTLM User Domain

Configures the NTLM server domain name to be used to authenticate user access.

ntlmUserDomain

Disable basic authentication

Disallows the removal of NTLM headers for fallback to the basic authentication method.

disableBasicAuth

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Configuring HTTP Cache Settings

The HTTP Cache Settings window allows you to configure caching parameters for the caching of HTTP requests.

To configure HTTP caching parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 Choose Applications > Web > HTTP > HTTP Caching. The HTTP Caching for Content Engine window appears. (See Figure 8-2.) Table 8-2 describes the fields in this window.

Figure 8-2 HTTP Caching for Content Engine Window

Step 4 To enable redirection using a Layer 4 switch, such as the Cisco Content Services (CSS) switches, check the L4 Switch Support check box.

Step 5 To enable stripping of the requesting IP address, check the Anonymize Requests check box. This option sets the HTTP anonymizer feature, which hides the identity of the sender.

Step 6 To enable caching of objects that are served with cookies attached and no expiration information, check the Cache Binaries with Cookies check box. These requests are for binary content with Set-cookie headers attached.

Step 7 To disable Nagle's algorithm for HTTP requests, check the Enable Fast Response check box. Use this option only if particular server applications require an immediate, timely response to frequent, small bursts of information from the client. Disabling Nagle's algorithm results in performance degradation, because it disables buffering of data.

Step 8 To enable the Content Engine to cache responses with the Vary: User-Agent header, check the Enable Cache Vary User Agent check box. (To configure cache vary user agent settings, see the "Configuring HTTP Cache Vary User Agent" section.)

Step 9 To have the Content Engine check for required content length in HTTP requests, check the Strict Length Checking check box.

Step 10 To enable IP spoofing on the Content Engine for Layer 4 redirected traffic from Layer 4-enabled switches, check the L4 Switch Spoof Support check box.

Enabling this feature makes the Content Engine spoof the client's IP address as the source IP address for requests originating from the Content Engine to the origin server. Requests to the origin server from the Content Engine generally happen on a cache miss.

Step 11 If the request contains a host name in the HTTP request header that is not a fully qualified domain name (FQDN), and you do not want the Content Engine to rewrite the request header by using a FQDN instead of the host name, check the Do not modify request host header check box.

When a client request is intercepted by a Content Engine, the default behavior of the Content Engine is to query the DNS server for the IP address of the origin server and use the FQDN of the origin server when forwarding the HTTP request. If the origin server is configured with a modified host name and is not using a FQDN in its host header, the origin server will not be able to process the Content Engine request.

If you want the Content Engine to use a FQDN in the request host header, leave this check box unchecked.

Step 12 To have the Content Engine not cache objects that exceed the specified maximum size, check the Enforce Max Object Size check box. An object with a size above the configurable upper limit is not stored by the Content Engine.

Note When this check box is unchecked, the cache file system (cfs) size limit remains at 2096128 KB (2 GB) for all cacheable objects.

Step 13 In the Max Object Size field, specify the maximum object size in kilobytes.

Step 14 To have an object that is in the Content Engine cache validated each time the object is requested, check the URL Validation check box.

When this option is enabled, cached objects are tested with respect to the validity of the host header and the server IP address. If the host header and server IP address are still valid, the content is served from the cache. If these parameters fail the validity test, the object is not served from the cache and a cache miss occurs.

Step 15 To configure how no-cache requests should be managed, choose an option from the Client No Cache drop-down list.

•If you want the Content Engine to ignore the no-cache request, choose the ignore option.

•Choose the revalidate option if you want to revalidate the request with the origin server before serving a no-cache client request.

•If you do not want to set this option, choose the default Do not set option.

Step 16 To cache an entire HTTP response even if you issue a Range request (that is, a request for only portions of a requested content object) and the object is not in the cache, check the Enable Smart Range check box. The Max Start and Max Interval fields become available if you check this check box.

Step 17 In the Max Start field, specify the maximum starting offset (in bytes) in the client's Range request of the object to be cached. The range is 0 to 2147483647. The default is 16384.

Step 18 In the Max Interval field, specify the maximum interval (in bytes) between any two consecutive ranges in the Range request. The range is 0 to 2147483647. The default is 16384.

Only if a Range request satisfies both conditions (offset and interval), 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.

Step 19 To limit the maximum bit rate per session for large files delivered using the HTTP protocol, specify the default bit rate in kilobits per second (kbps) in the Default Bitrate field.

Step 20 To always resolve the Host header to determine the origin server IP address, check the Always Resolve Host check box.

Step 21 To save the settings, click Submit.

A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or group settings to change the current device settings but have not yet submitted the changes.

Table 8-2 HTTP Cache Settings

GUI Parameter

Function

CLI Command

L4 Switch Support

Enables redirection using a Layer 4 switch, such as the Cisco Content Services (CSS) switches.

http l4-switch enable

Anonymize Requests

Enables stripping of the requesting IP address. This option sets the HTTP anonymizer feature, which hides the identity of the sender.

http anonymizer enable

Cache Binaries with Cookies

Enables caching of objects that are served with cookies attached and no expiration information. These requests are for binary content with Set-cookie headers attached.

http cache-cookies

Enable Fast Response

Disables Nagle's algorithm for HTTP requests. Use this option only if particular server applications require an immediate, timely response to frequent, small bursts of information from the client. Disabling Nagle's algorithm results in performance degradation, because it disables buffering of data.

http fast-response enable

Enable Cache Vary User Agent

Configures parameters to enable the Content Engine to cache responses with the Vary: User-Agent header.

http cache-vary-user-agent enable

Strict Length Checking

Content Engine checks for required content length in HTTP requests.

http strict-request-content-length-checking enable

L4 Switch Spoof Support

Enables IP spoofing on the Content Engine for Layer 4 redirected traffic from Layer 4-enabled switches.

http l4-switch spoof-client-ip enable

Do not modify request host header

Stops the Content Engine from rewriting the host name if the request contains a host name in the HTTP request header that is not a fully qualified domain name (FQDN).

http request-header host unmodified

Enforce Max Object Size

Stops the Content Engine from caching objects that exceed the specified maximum size.

Note When this check box is unchecked, the cache file system (cfs) size limit remains at 2096128 KB (2 GB) for all cacheable objects.

http object max-size kbytes

Max Object size

Maximum object size in kilobytes.

URL Validation

Revalidate every object requested in the cache with the origin server.

http object url-validation enable

Client No Cache

Configures the manner in which no-cache requests should be managed.

http client-no-cache-request {ignore | revalidate}

Enable Smart Range

Caches an entire HTTP response even if you issue a Range request (that is, a request for only portions of a requested content object) and the object is not in the cache.

http smart-range enable

Max Start

Maximum starting offset (in bytes) in the client's Range request of the object to be cached. The range is 0 to 2147483647. The default is 16384.

http smart-range max-start offset

Max Interval

Maximum interval (in bytes) between any two consecutive ranges in the Range request. The range is 0 to 2147483647. The default is 16384.

http smart-range max-start offset max-interval interval

Default Bitrate

Maximum pacing bitrate (in kbps) for large pre-positioned HTTP files. The range is 0 to 2000000. The default is 1500 kbps.

bitrate http default kbps

Always Resolve Host

Resolves the Host header to determine the origin server IP address.

http always-resolve-host

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Configuring HTTP Cache Freshness Settings

You can configure HTTP cache object freshness parameters for Content Engines on the ACNS network using the HTTP Cache Freshness Settings window from the Content Distribution Manager GUI. These parameters can be configured for either directory listings (the files and subdirectories listed under a directory) or particular objects in the cache.

To configure HTTP freshness parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose Applications > Web > HTTP > HTTP Cache Freshness. The HTTP Cache Freshness Settings window appears. (See Figure 8-3.) Table 8-4 describes the fields in this window.

Figure 8-3 HTTP Cache Freshness Settings Window

Step 4 To enable the HTTP cache freshness settings, check the Enable check box. This check box is checked by default.

Step 5 Specify a value 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 6 Specify a value in the Binary Object Age Multiplier field.

The age multiplier 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 7 Choose a scale (seconds, hours, minutes, or days) 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 8 Specify a value in the Max Text Object TTL field. Table 8-3 provides valid values for the TTL field.

Table 8-3 Time To Live Range of Values for HTTP Freshness

Scale

Range

Days

1-1825

Hours

1-43800

Minutes

1-2628000

Seconds

1-157680000

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

See Table 8-3 for a list of maximum values depending on the scale used.

Step 10 Specify a value 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 11 Choose how reevaluation requests are to be handled from the Re-evaluate Request drop-down list.

•To apply these parameters to the directory listing (the files and subdirectories listed under a directory), choose text.

•To apply these parameters to both objects and directory listing, choose all.

•To ensure that a TTL is not applied and objects in the cache have no expiration dates, choose none.

Step 12 To specify text and age modifiers in the next two steps, check the Enable If-Modified-Since check box.

Step 13 Specify a percentage in the IMS Text Age Modifier (%) field. This value specifies the age percentage to serve a text object without revalidation.

Step 14 Specify a percentage in the IMS Binary Age Modifier (%) field. This value specifies the age percentage to serve a binary object without revalidation.

Step 15 To save the settings, click Submit.

A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or group settings to change the current device settings but have not yet submitted the changes.

Table 8-4 HTTP Cache Freshness Settings

GUI Parameter

Function

CLI Command

Enable

Enables the HTTP cache freshness settings.

—

Text Object Age Multiplier

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.

http age-multiplier text num

Binary Object Age Multiplier

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.

http age-multiplier text num binary num

Max TTL Scale

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

http max-ttl {days text textdays binary bindays | hours text texthours binary binhours | minutes text textminutes binary binminutes | seconds text textseconds binary binseconds}

Max Text Object TTL

Value.

Max Binary Object TTL

Value.

Minimum TTL

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.

http min-ttl minutes

Re-evaluate Request

Configures how reevaluation requests are to be handled.

http reval-each-request {all | none | text}

Enable If-Modified-Since (IMS)

Enables IMS modifiers.

http serve-ims

IMS Text Age Modifier

Age percentage to serve a text object without revalidation.

http serve-ims text percentage

IMS Binary Age Modifier

age percentage to serve a binary object without revalidation.

http serve-ims text percentage binary percentage

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons"

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.

To configure authenticated HTTP caching parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose Applications > Web > HTTP > Authenticated HTTP Caching. The Authenticated HTTP Caching for Content Engine window appears. (See Figure 8-4.) Table 8-5 describes the fields in this window.

Figure 8-4 Authenticated HTTP Caching for Content Engine Window—Top

Step 4 To enable use of authenticated HTTP cache settings for the Content Engine, check the Enable check box.

Step 5 From the Cache Authenticated Content drop-down list, choose an authentication method to cache authenticated content.

•To cache web objects authenticated with any scheme, choose all.

•To cache web objects authenticated with basic or NTLM, choose basic or ntlm from the drop-down list.

•To remove the authentication method, choose Do Not Set. This choice is the equivalent of the no http cache-authenticated basic command and the no http cache-authenticated ntlm command.

Step 6 To strip NTLM headers from the authenticated content, check the Strip NTLM Headers check box.

When checked, NTLM headers are stripped from the authenticated content being sent from the Content Engine to the client browser. This feature enables browsers to fall back to basic authentication. Browsers can authenticate against a basic-style authentication challenge posed by Microsoft Internet Information Service (IIS) servers.

When left unchecked, the NTLM header in the response is preserved, and the browser will authenticate against the NTLM challenge.

Step 7 To enable the maximum number of entries retained in the authentication cache to be configured on the Content Engine, check the Set Max Cache Authentication Entries check box.

Step 8 In the Max Cached Authenticated Entries field, enter a value for the maximum number of entries that is maintained in the cache. The default value is 32000 entries.

Step 9 To enable the maximum number of entries retained in the authentication group cache to be configured on the Content Engine, check the Set Max Group Cached Authenticated Entries check box.

Step 10 In the Max Group Cached Authenticated Entries field, specify the maximum number of entries retained in the authentication group cache on the Content Engine. The range is 500 to 12000. This maximum is subject to physical resources on the Content Engine.

Step 11 In the Time Authenticated Entries are cached field, enter the length of time (in minutes) between the last access and the removal of the entry from the cache on the Content Engine. The range is from 1 to 1440 minutes, and the default value is 480 minutes.

The authentication record entry is stored in the cache for the specified period. Once this period is exceeded, subsequent access to restricted content requires reauthentication through NTLM, RADIUS, or LDAP servers. (See the "Specifying a Reauthentication Interval" section.)

Step 12 To enable the absolute timeout for entries in the authentication cache to be configured on the Content Engine to help reduce the possibility of individuals gaining access by using previously authenticated browsers, check the Set Authentication Cache TTL check box. By default, this check box is unchecked, which means that there is no TTL timeout in effect. This means that there will be no check to time out an authentication cache entry based on its creation time relative to a TTL value.

Step 13 In the Authentication Cache TTL (max valid time) field, specify an absolute value for the maximum time an authentication cache entry is considered valid after its creation. The TTL timeout is specified in minutes. The minimum is 1 minute; the maximum is 1440 minutes (24 hours).

When the absolute TTL period has expired, the client browser is forced to re-authenticate itself and the user must enter valid credentials. This ability to specify an absolute TTL timeout, adds security to the inactivity timeout mechanism for content that is served through the Content Engine.

The timeout value in the Time Authenticated Entries are cached field is not affected by the absolute TTL; they are independent of each other. If both the Time Authenticated Entries are cached timeout and the absolute TTL timeout are configured on the Content Engine, the authentication cache entry times out depending on which timeout occurs first for that entry.

Step 14 To send an authentication message in the header, choose either the 401 (Unauthorized) or 407 (Proxy Authentication Required) header type message from the Re-Authenticate Header type drop-down list. If you do not want to send a message, choose Do not set. (See Figure 8-5.) Table 8-5 describes the fields in this window.

These authentication headers are used to query users for credentials when an entry is not found in the authentication cache, requiring server lookup.

Figure 8-5 Authenticated HTTP Caching for Content Engine Window—Bottom

Step 15 To modify the HTTP authentication realm string, enter the desired string in the Basic Realm String field.

Cisco ACNS software allows you to configure the realm that is displayed in the authentication popup window when you connect to the Content Engine. The default realm is "Cisco Content Engine." This setting allows you to reconfigure the realm to reflect the nature of the device.

Step 16 If you want HTTP headers to be appended by downstream Content Engines, check the Append Headers check box. The fields that follow are available only when you have checked the Append Headers check box.

Step 17 In the Proxy Header Server field, enter the host name or IP address of the server that is configured to receive the proxy authorization header.

When this setting is configured, the Content Engine appends the proxy authorization header to the request when it sends the request to an upstream Content Engine proxy or server that is configured to receive the proxy authorization header.

Proxy authorization headers are hop-by-hop headers, and so, the default behavior is to not append proxy authorization headers to upstream proxies or servers. Configuring this setting allows a proxy authorization header to be sent to a specific server that is configured to receive this type of header.

Step 18 To include a "Via" header in responses and replies, check the Use Via Headers check box.

Step 19 To add a custom string in the Via header description, enter up to 99 characters in the Use Custom String Via Headers field.

Step 20 In the WWW Authentication Server field, enter the host name or IP address of the server that is configured to receive the WWW authorization header.

For example, you might have the following set of conditions:

•WCCP is enabled for the Content Engine.

•Proxy authentication (RADIUS, LDAP, TACAS, or NTLM) is enabled for the Content Engine.

•You configured base2 as the host name in the WWW Authentication Server field.

When a client sends a request for http://base2/ the Content Engine authenticates the request, and while sending the request to the base2 server, the Content Engine includes the WWW authorization header received from the client. (The base2 server has been configured to receive the WWW authorization header.) If the request from the client is for a server other than base2, the Content Engine authenticates the request and sends the request to the server without including the WWW authorization header received from the client.

This setting is similar to the append proxy authorization header setting (configured in the Proxy Header Server field).

Step 21 To notify the web server of the client IP address through the X-Forwarded-For header, check the Use X-FWD-Headers check box.

Step 22 To enable support for appending multiple IP addresses to the X-Forwarded-For header, check the Use X-FWD-Headers with Multiple IP Address check box.

If you specify this command, and an X-Forwarded-For header already exists, then the Content Engine IP address is appended to the existing client IP address in the header, separated by a comma.

Step 23 To append host headers to HTTP/1.0 requests that do not possess these headers, check the Use Host Header check box.

Step 24 To save the settings, click Submit.

A "Click Submit to Save" message appears in red next to the Current Settings when there are pending changes to be saved after you have applied the default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or group settings to change the current device settings but the settings have not yet been submitted.

Table 8-5 Authenticated HTTP Cache Settings

GUI Parameter

Function

CLI Command

Enable

Enables use of authenticated HTTP cache GUI settings for the Content Engine.

—

Cache Authenticated Content

Authentication method (all, basic, ntlm, Do Not Set) to cache authenticated content.

[no] http cache-authenticated {all | basic | ntlm}

Strip NTLM Headers

Strips NTLM headers from the authenticated content.

http authenticate-strip-ntlm

Set Max Cached Authenticated Entries

Enables the maximum number of entries retained in the authentication cache to be configured on the Content Engine.

—

Max Cached Authenticated Entries

Maximum number of entries that is maintained in the cache. The default value is 32000 entries.

http authentication cache max-entries entries

Set Max Group Cached Authenticated Entries

Enables the maximum number of entries retained in the authentication group cache to be configured on the Content Engine.

—

Max Group Cached Authenticated Entries

Maximum number of entries retained in the authentication group cache on the Content Engine. The range is 500 to 12000. This value is subject to physical resources on the Content Engine.

http authentication cache max-group-entries entries

Time Authenticated Entries are cached

Length of time (in minutes) between the last access and the removal of the entry from the cache on the Content Engine. The range is 1 to 1440. The default is 480 minutes.

http authentication cache timeout minutes

Set Authentication Cache TTL

Enables the absolute timeout for entries in the authentication cache to be configured on the Content Engine.

—

Authentication Cache TTL (max valid time)

Maximum time an authentication cache entry is considered valid after its creation. The TTL timeout is specified in minutes. The minimum is 1 minute; the maximum is 1440 minutes (24 hours).

http authentication cache ttl minutes

Re-Authenticate Header type

Sends an authentication message in the header.

http authentication header {401 | 407}

Append Response Headers

Directs downstream Content Engines to append HTTP headers.

—

Proxy Header Server

Host name or IP address of the server that is configured to receive the proxy authorization header.

http append proxy-auth-header {ipaddress | hostname}

Use Via Headers

Includes a "Via" header in responses and replies.

http append via-header

Use Custom String Via Headers

Adds a custom string in the Via header description.

http append via-header custom string

WWW Authentication Server

Host name or IP address of the server that is configured to receive the WWW authorization header.

http append www-auth-header {hostname | ipaddress}

Use X-FWD-Headers

Notifies the web server of the client's IP address through the X-Forwarded-For header.

http append x-forwarded-for-header

Use X-FWD-Headers with Multiple IP Address

Appends multiple IP addresses to the X-Forwarded-For header.

http append x-forwarded-for-header multiple-ip-address

Use Host Header

Appends host headers to HTTP/1.0 requests.

http append host-header

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Specifying a Reauthentication Interval

In the ACNS 5.1 software, an inactivity timer was used to determine when the client browser was prompted to reenter authentication credentials after being initially authenticated. This inactivity timer is configured with the http authentication cache timeout global configuration command. By default, the inactivity timeout period was 8 hours. This meant that as long as someone continued to use the client browser after the legitimate authenticated user was initially authenticated, the client was not forced to reenter that person's authentication credentials.

In the ACNS 5.2.1 software and later releases, you can specify an absolute TTL for HTTP authentication cache entries for increased security in a shared workstation environment. This ability to specify an absolute TTL timeout adds security to the inactivity timeout mechanism for content that is served through the Content Engine. When the absolute TTL period has expired, the client browser is forced to reauthenticate itself, and the user must enter valid credentials.

A security vulnerability exists in a shared workstation environment that is using WCCP-enabled router redirection mode with any authentication method, or proxy redirection mode and the NTLM authentication method. In these cases, the Content Engine uses the client's IP address as the index into the authentication record kept in the authentication cache, and the Content Engine can therefore authenticate users who have not presented valid credentials of their own if a different user using the same workstation has previously presented valid credentials that are cached in the authentication cache. To provide additional security in this situation, you can configure the absolute TTL for HTTP authentication cache entries; this will specify the absolute time during which an authentication cache entry is valid in the cache. If a cache lookup occurs on an entry and its configured TTL time is exceeded, then the entry is deleted and the Content Engine will query the user for credentials.

To support this feature, the ttl option was added to the http authentication cache global configuration command.

Configuring Advanced HTTP Cache Settings

To configure advanced HTTP cache settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose Applications > Web > HTTP > Advanced HTTP Caching. The Advanced HTTP Caching for Content Engine window appears. (See Figure 8-6 and Figure 8-7.) Table 8-6 describes the fields in these windows.

Figure 8-6 Advanced HTTP Caching for Content Engine Window—Top

Step 4 Under the Advanced HTTP Caching heading, check the Enable Cache on Abort check box to continue to cache an object even though the client has aborted the request.

Step 5 To cache an object if the number of kilobytes remaining to download from the server is less than the maximum threshold value, check the Use Max Threshold check box.

Step 6 In the Abort Max Threshold field, enter a value in kilobytes for the maximum threshold. The default value is 256 kilobytes.

Step 7 To cache an object if the number of kilobytes remaining to download from the server is greater than the minimum threshold value, check the Use Min Threshold check box.

Step 8 In the Abort Min Threshold field, enter a value in kilobytes for the minimum threshold. The default value is 32 kilobytes.

Step 9 To cache an object if the percentage of the object already downloaded is greater than the percentage threshold value entered, check the Use Percent Threshold check box.

Step 10 In the Abort Percent Threshold field, enter a value for the percentage threshold. The default value is 80 percent.

Step 11 Under the Cluster Settings heading, check the Enable Clustering check box to allow a Content Engine in a Content Engine farm to query and obtain cache objects from other Content Engines in the cluster.

Step 12 In the Cluster Heal Port field, enter the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster, if you are not using the default HTTP port (14333).

The Content Engine that responds to queries from another Content Engine in a Content Engine cluster is called a healing server. The Content Engine that requests a cache object from the cluster is called a healing client.

Step 13 In the Cluster HTTP Port 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 is 80.

Step 14 In the Cluster Max Delay field, enter the maximum time in seconds that a healing Content Engine waits for a healing Content Engine response.

Step 15 In the Cluster Misses field, enter the maximum number of misses that the healing Content Engine can receive from the cluster after the last healing mode hit response.

Step 16 Under the Persistent Connections Settings heading, check the Enable Persistent Connections check box to allow persistent connections on the Content Engine. (See Figure 8-7.)

Figure 8-7 Advanced HTTP Caching for Content Engine Window—Bottom

Step 17 From the Persistent Connections Type drop-down list, choose a persistent connection type. A persistent connection can be set for client-only, server-only, or all connections on the Content Engine.

Step 18 In the Persistent Connection Timeout field, enter 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 19 Under the TCP KeepAlive Settings heading, check the Enable TCP Keepalive check box to force the Content Engine to send keepalive probes, which allows persistent connections on the Content Engine.

For HTTP connections, the default timeout value is 5 minutes. When no keepalive messages are sent by the Content Engine to the clients and to the edge Content Engines, the connection is closed. When the HTTP TCP keepalive feature is enabled, the Content Engine continues to send TCP keepalives on idle TCP connections using keepalive configuration parameters, such as TCP keepalive timeout, TCP keepalive probe count, and TCP keepalive probe interval.

Step 20 To save the settings, click Submit.

A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or group settings to change the current device settings but the settings have not yet been submitted.

Table 8-6 Advanced HTTP Cache Settings

GUI Parameter

Function

CLI Command

Advanced HTTP Caching

Enable Cache On Abort

Continues to cache an object even though the client has aborted the request.

http cache-on-abort enable

Use Max Threshold

Caches an object if the number of kilobytes remaining to download from the server is less than the maximum threshold value.

http cache-on-abort max-threshold max_thresh

Abort Max Threshold

Maximum threshold in kilobytes.

Use Min Threshold

Caches an object if the number of kilobytes remaining to download from the server is greater than the minimum threshold value.

http cache-on-abort min-threshold min_thresh

Abort Min Threshold

Minimum threshold in kilobytes.

Use Percent Threshold

Caches an object if the percentage of the object already downloaded is greater than the percentage threshold value entered.

http cache-on-abort percent percenthresh

Abort Percent Threshold

Percentage threshold value.

Cluster Settings

Enable Clustering

Allows a Content Engine in a Content Engine farm to query and obtain cache objects from other Content Engines in the cluster.

—

Cluster Heal Port

Port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster, if you are not using the default HTTP port (14333).

http cluster heal-port num

Cluster HTTP Port

HTTP port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster.

http cluster http-port num

Cluster Max Delay

Maximum time in seconds that a healing Content Engine waits for a healing Content Engine response.

http cluster max-delay seconds

Cluster Misses

Maximum number of misses that the healing Content Engine can receive from the cluster after the last healing mode hit response.

http cluster misses num

Persistent Connection Settings

Enable Persistent Connections

Allows persistent connections on the Content Engine.

—

Persistent Connection Type

Sets persistent connection type (client-only, server-only, or all) for connections on the Content Engine.

http persistent-connections {all | server-only | client-only}

Persistent Connection Timeout

Number of seconds that the Content Engine should keep an idle persistent connection open before it closes the connection.

http persistent-connections timeout seconds

TCP KeepAlive Settings

Enable TCP Keepalive

Forces the Content Engine to send keepalive probes.

http tcp-keepalive enable

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Adding or Modifying Additional HTTP Request Methods for the Content Engine

Content Engines accept or reject an HTTP request depending on whether the HTTP request method is supported. HTTP 1.1 request methods (for example, GET, HEAD, or POST) are supported by default. Nonstandard request methods, such as Web-Based Distributed Authoring and Versioning (WebDAV) are not.

When the Content Engine receives an HTTP request from a client using an unsupported method, ACNS software adds the method to the list of unsupported methods and sends an error to the client. You can use the Creating New HTTP Method for Content Engine window to add a method to the list of methods already supported by the Content Engine.

To add a new HTTP request method, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the name of the Content Engine for which you want to add an HTTP request method. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Applications > Web > HTTP > HTTP Method. The HTTP Methods for Content Engine window appears, displaying the method names and device group sources. The Device Group Source column specifies the name of the device group whose settings have been applied to the Content Engine.

Step 4 The Aggregate Settings Yes radio button is selected. This means that the HTTP methods are displayed for the Content Engine as well as for any associated device groups. Click the No radio button to apply the HTTP methods to the Content Engine only.

Note When the Aggregate Settings Yes radio button is selected, the HTTP methods that have been configured for device groups to which the Content Engine belongs cannot be modified or deleted; the settings are read-only. You can, however, modify the HTTP methods configured for the Content Engine. If the Aggregate Settings No radio button is selected, you can view or modify the HTTP methods for the Content Engine only, and not for the device groups with which it is associated.

Step 5 Click the Create New HTTP Method icon in the taskbar. The Creating new HTTP method for Content Engine window appears.

Step 6 In the Method Name field, enter the name of the HTTP request method to be added to the list of supported methods.

Step 7 To save your settings, click Submit. The HTTP Methods for Content Engine window appears, displaying the newly added HTTP method.

To add a new HTTP request method using the CLI, use the http add-method global configuration command.

Configuring HTTP Cache Vary User Agent

To configure the parameters for caching responses with the Vary header, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices (or Devices > Device Groups).

Step 2 Click the Edit icon next to the Content Engine or Device Group that you want to configure.

Step 3 In the Contents pane, choose Applications > Web > HTTP > HTTP Cache User Agent. The HTTP User Agents for Content Engine (or Device Group) window appears.

Step 4 Click the Create New HTTP User Agent icon in the task bar. The Creating New HTTP User Agent window appears. (See Figure 8-8.) Table 8-7 describes the fields in this window and provides the corresponding CLI commands.

Figure 8-8 Creating New HTTP User Agent Window

Step 5 In the SubString field, enter a string to be used to match while searching for an alternative user-agent.

The substring configuration must be unique. The Content Distribution Manager GUI returns an error message for duplicate substring configurations.

Step 6 In the CacheString field, enter a string that is to form the objects key.

The following characters are invalid: acute accent (`), double quote ("), pipe (|), question mark (?), and white space.

Step 7 To save the configuration, click Submit. The window refreshes, and the HTTP User Agents window appears with the new item listed. You can create up to 32 entries.

Step 8 Enable the Content Engine to use these settings by checking the Enable Cache Vary User Agent check box in the HTTP Caching for Content Engine window. (See the "Configuring HTTP Cache Settings" section.)

Table 8-7 HTTP Cache User Agent Settings

GUI Parameter

Function

CLI Command

SubString

Configures the string to be used to match while searching for an alternative user-agent. Maximum characters is 16.

http cache-vary-user-agent sub-string string cache-string string

CacheString

Configures the cache-string that forms the objects key. Maximum characters is 16.

Configuring HTTP Destination Port Restrictions

Cisco ACNS software allows you to configure HTTP destination port access restrictions from the Content Distribution Manager GUI.

To configure HTTP destination port restrictions, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the Content Engine for which you want to configure the destination port restrictions. The Device Home window for the chosen Content Engine appears.

Step 3 In the Contents pane, choose Web > HTTP > HTTP Destination Port Restrictions. The HTTP Destination Port Restriction Settings window appears. By default the window shows the current settings for the chosen device.

Step 4 To allow access to all ports, check the Allow All Ports check box.

Note By default, the Allow All Ports check box is checked, and this allows traffic to port range 80-87 and to any port above 1024.

Step 5 In the Allow Port Range List field, enter the port numbers or port ranges to which you want to allow traffic. You can enter a maximum of eight port numbers or port ranges separated by a space.

Step 6 To deny traffic to any of the ports, check the Deny All Ports check box.

Note Port numbers below port 1024 are denied by default, except for port range 80-87.

Step 7 To allow traffic to these ports, uncheck the Deny Port Range 1-79 check box.

Step 8 To allow traffic to these ports, uncheck the Deny Port Range 80-1024 check box.

Step 9 In the Other Deny Port Range List field, enter the port numbers or port ranges of ports to which you want to deny traffic. You can enter up to eight port numbers or port ranges separated by a space.

Note If you have both the Deny Port Range 1-79 and the Deny Port Range 80-1024 checked, you can enter only six more port numbers or port ranges in the Other Deny Port Range List field. When either the Deny Port Range 1-79 or the Deny Port Range 80-1024 is checked, the Other Deny Port Range List field accepts a maximum of seven ports instead of eight.

Step 10 To save the settings, click Submit. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.

To configure HTTP destination port restrictions from the CLI, use the http destination-port global configuration command.

Configuring HTTPS Settings

You can configure, modify, and view HTTPS settings for Content Engines and device groups by completing the following tasks:

•Configuring HTTPS Certificates

•Configuring HTTPS Certificate Groups

•Configuring HTTPS Keys

•Configuring HTTPS Proxy Settings

•Configuring HTTPS Servers

•Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings

Configuring HTTPS Certificates

A digital certificate is a credential that allows the Content Engine to be presented to an HTTPS client as the origin HTTPS server. You can create certificates, import a certificate from external sources, or remove existing certificates using the Content Distribution Manager GUI.

You can assign a certificate and associate a key with the HTTPS server assuming that you have configured the Content Engine using the Creating New HTTPS Server for Content Engine window or using the https server global configuration command. The Content Engine presents the certificate to HTTPS clients that make requests to the HTTPS server.

The Content Engine accepts certificates in Privacy-Enhanced Mail (PEM) format, which is used by Apache servers, and Public-Key Cryptography Standards (PKCS) #12 format, which is used by Microsoft Internet Information Server (IIS).

The Content Engine uses PEM format internally, and automatically converts certificates in PKCS #12 format to PEM format. If you need to use a certificate in a different format, first convert it to one of these supported formats.

To configure HTTPs certificates for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to configure HTTPS certificates. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > Certificates. The HTTPS Certificates for Content Engine window appears. The certificates created for device groups can only be viewed; they cannot be modified.

Step 4 To configure an HTTPS digital certificate, click the Create New HTTPS Certificate icon in the taskbar. Table 8-8 describes the fields that appear in this window and provides the corresponding CLI global configuration commands.

Step 5 In the Certificate Name field, specify the name of the certificate. Certificate names must consist solely of alphanumeric, underscore, and hyphen characters. Certificate names can begin with a numeric character. Certificate names can have a maximum length of 64 characters.

You need to create a certificate before importing its value from an external source associating it with an HTTPS server. Only certificate names are stored in the CMS database; the actual certificates are stored on the Content Engine.

Note Once you have created a certificate, you cannot modify the name. You need to delete the existing certificate and create a new one.

Step 6 In the Certificate URL field, specify the external location from which the certificate is to be imported. The URL must be a valid URL using HTTP, FTP, or HTTPS. The certificate value is imported after you specify the URL and submit changes.

A certificate name without imported values can be listed in the Content Distribution Manager GUI; however, only certificates with valid values can be associated with an HTTPS server or added to a certificate group. Two different certificates can be imported from the URL and two different HTTPS servers can be associated with the same certificate.

After a certificate is imported from the Content Distribution Manager GUI, a new icon (Re-import) appears in the taskbar. The Re-import icon can be used to reimport the certificates if the import operation did not succeed the first time.

Step 7 In the Username field, specify the username required to access the external source from which the certificate is being imported. An entry is required in this field only if the external source is password-protected.

Step 8 In the Password field, specify the password used to authenticate users who want to gain access to the external source from which the certificate is being imported. An entry is required in this field only if the external source is password-protected. Reenter the password in the Confirm Password field.

Step 9 To save the settings, click Submit.

Table 8-8 HTTPS Certificate Settings

GUI Parameter

Function

CLI Command

Certificate Name

Name of the certificate.

https server name cert cert_name

Certificate URL

External location from which the certificate is to be imported. The URL must be a valid URL using HTTP, FTP, or HTTPS.

https server name host ipaddress or FQDN

Username

Username required to access the external source from which the certificate is being imported.

—

Password

Password used to authenticate users who want to gain access to the external source.

—

Confirm Password

Verifies the password entry.

—

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Filtering HTTPS Certificates for the Content Engine

You can use the Content Distribution Manager GUI to filter and display a subset of HTTPS certificates by certificate name and URL.

To set the filter criteria to display selected HTTPS certificates, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to filter HTTPS certificates. The Device Home for Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > Certificates. The HTTPS Certificates for Content Engine window appears. The certificates created for device groups can only be viewed; they cannot be modified.

Step 4 Click the Filter Table icon in the taskbar. The Filtering HTTPS Certificates for Content Engine window appears.

Step 5 Choose a filter operator from the Certificate Name drop-down list and enter the name of the certificate that must be matched. Table 8-9 describes the filter operators for filtering HTTPS certificates.

Step 6 Choose a filter operator from the Certificate URL drop-down list and enter the certificate location that must be matched.

Step 7 Click Submit. The HTTPS Certificates for Content Engine window reappears, displaying a list of all certificates that match the specified filter criteria.

Table 8-9 Filtering HTTPS Certificates

Filter Operators

Description

Like

Include HTTPS certificates with a setting that is similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or ', use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS certificates with names that begin with httpscer and are followed by a single character, enter httpscer_ in the Certificate Group Name field. Any certificate with the name Httpscer is not displayed.

Not like

Includes HTTPS certificates with a setting that is not similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or ', use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS certificates except the ones with URLs that start with ftp://, enter %ftp:// in the Certificate URL field. Any certificate with the URL https://a.com or http://a.com is displayed.

In

Includes certificates with settings that are present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (`) when the specified string contains commas or parentheses.

For example, to display certificates with names CER1, CER2, and CER(3), enter (CER1,CER2,`CER(3)') or CER1,CER2,`CER(3)' in the Certificate Name field. Certificates with names such as CER4 and CER5 are not displayed.

Not in

Includes certificates with settings that are not present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (`) when the specified string contains commas or parentheses.

For example, to display certificates except the ones with names CER1, CER2, and CER(3), enter (CER1,CER2,`CER(3)') or CER1,CER2,`CER(3)' in the Certificate Name field. Certificates with names such as CER4 and CER5 are displayed

Equal to

Includes certificates with a setting that is exactly the same as the string entered.

For example, to display all certificates imported from the URL http://Location1, enter http://Location1 in the Certificate URL field. Certificates imported from http://Location^1 are not displayed. You cannot use keywords, special characters, or wildcard characters.

Not equal to

Includes certificates with a setting that is not exactly the same as the string entered.

For example, to display all certificates not imported from the URL http://Location1, enter http://Location1 in the Certificate URL field. Certificates imported from http://Location^1 are displayed. You cannot use keywords, special characters, or wildcard characters.

Configuring HTTPS Certificate Groups

Certificate groups represent a trust relationship chain from root Certificate Authority to end entity. Each certificate 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 those of the certificate group.

To configure HTTPS certificate groups for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to configure HTTPS certificate groups. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > Certificate Groups. The HTTPS Certificate Groups for Content Engine window appears. The certificate groups created for device groups can only be viewed; they cannot be modified.

Step 4 To configure an HTTPS digital certificate group, click the Create New HTTPS Certificate Group icon in the taskbar. The HTTPS Certificate Group for Content Engine window appears. You can create certificate groups with a given name, and add specified existing certificates to the current certificate group using this window.

Step 5 In the Certificate Group Name field, specify the name of the certificate group to be used for certificate chains and server certificate authentication. Certificate group names must consist solely of alphanumeric, underscore, and hyphen characters. Certificate group names can begin with a numeric character. Certificate group names can have a maximum of 64 characters.

Note Once you have created a certificate group name, you cannot it. You need to delete the existing certificate group and create a new one.

Step 6 Choose the name of the certificate to be added to the certificate group from the Certificate drop-down lists. All certificates created using the HTTPS Certificates for Content Engine window are listed here. You can add a maximum of six certificates per certificate group.

Two different certificate groups can have the same combination of HTTPS certificates. You can choose up to six certificates from the Certificate drop-down lists 1 through 6. These drop-down lists are set to an initial value of Do not set. You must choose these certificates in sequence when you add them to the certificate group and each associated certificate must be unique, or an error message is displayed when you click Submit.

Step 7 To delete a certificate group, click the Delete HTTPS Certificate Group icon in the taskbar. You cannot delete a certificate group that is referenced by an HTTPS server. You must remove the association between the certificate group and HTTPS server before deleting.

Step 8 To view a subset of the entire list of HTTPS certificate groups, click the Filter Table icon in the taskbar. See the next section "Filtering HTTPS Certificate Groups for the Content Engine," for more details.

Step 9 To revert to the display of all configured HTTPS certificate groups, click the View All HTTPS Certificate Groups icon in the taskbar.

Step 10 To save the settings, click Submit.

Table 8-10 HTTPS Certificate Group Settings

GUI Parameter

Function

CLI Command

Certificate Group Name

Name of the certificate group.

https server name certgroup chain certgroup_name

Certificate 1, 2, 3...

Certificate chain to use for the HTTPS server.

Filtering HTTPS Certificate Groups for the Content Engine

You can use the Content Distribution Manager GUI to filter and display a subset of HTTPS certificate groups by certificate group name.

To set the filter criteria to display selected HTTPS certificate groups, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to filter HTTPS certificate groups. The Device Home for Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > Certificate Groups. The HTTPS Certificate Groups for Content Engine window appears. The certificate groups created for device groups can only be viewed; they cannot be modified.

Step 4 Click the Filter Table icon in the taskbar. The Filtering HTTPS Certificate Groups for Content Engine window appears.

Step 5 Choose a filter operator from the Certificate Group Name drop-down list, and enter the name of the certificate group that must be matched.

Step 6 To revert to the display of all configured HTTPS certificate groups, click the View All HTTPS Certificate Groups icon in the taskbar. Table 8-11 describes the filter operators for filtering HTTPS certificate groups.

Step 7 Click Submit. The HTTPS Certificate Groups for Content Engine window reappears, displaying a list of all certificate groups that match the specified filter criteria.

Table 8-11 Filtering HTTPS Certificate Groups

Filter Operators

Description

Like

Includes HTTPS certificate groups with a setting that is similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or `, use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS certificate groups with a name that begins with httpscer and are followed by a single character, enter httpscer_ in the Certificate Group Name field. Any certificate with the name Httpscer is not displayed.

Not like

Includes HTTPS certificate groups with a setting that is not similar to the string entered.Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or ', use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS certificate groups except the ones with a name that begins with httpscer, enter httpscer in the Certificate Group Name field. Any certificate with the name Httpscer is displayed.

In

Includes certificate groups with settings that are present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (') when the specified string contains commas or parentheses.

For example, to display certificate groups with names CER1, CER2, and CER(3), enter (CER1,CER2,`CER(3)') or CER1,CER2,`CER(3)' in the Certificate Name field. Certificate groups with names such as CER4 and CER5 are not displayed.

Not in

Includes certificate groups with settings that are not present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (`) when the specified string contains commas or parentheses.

For example, to display certificate groups except the ones with names CER1, CER2, and CER(3), enter (CER1,CER2,`CER(3)') or CER1,CER2,`CER(3)' in the Certificate Name field. Certificate groups with names such as CER4 and CER5 are displayed.

Equal to

Includes certificate groups with a name that is exactly the same as the string entered.

For example, to display a certificate group with the name httpscer, enter httpscer in the Certificate Group Name field. A certificate group with the name Httpscer is not displayed. You cannot use keywords, special characters, or wildcard characters.

Not equal to

Includes certificate groups with a name that is not exactly the same as the string entered.

For example, to display all certificate groups except the one with the name httpscer, enter httpscer in the Certificate Group Name field. A certificate group with the name Httpscer is displayed. You cannot use keywords, special characters, or wildcard characters.

Configuring HTTPS Keys

The private key is the secret half of a key pair used in a public key algorithm. Private keys are typically used to encrypt a symmetric session key, digitally sign a message, or decrypt a message that has been encrypted with the corresponding public key. PKCS #12 specifies a portable format for storing or transporting a user's private keys and certificate information. The private key that the Content Engine uses to act as an origin HTTPS server must match the selected certificate.

You can create keys with a given name, import keys from external sources, or remove existing keys using the Content Distribution Manager GUI. To configure HTTPS keys for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to configure HTTPS keys. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > Keys. The HTTPS Keys for Content Engine window appears. (The keys created for device groups can only be viewed; they cannot be modified.)

Step 4 Click the Create New HTTPS Key icon in the taskbar to configure an HTTPS key. The Creating new HTTPS Key for Content Engine window appears.

Step 5 In the Key Name field, specify the name of the private key to be imported from an internal or external certificate authority (CA). You need to create a private key before importing its value from an external source and associating it with an HTTPS server. Key names must consist solely of alphanumeric, underscore, and hyphen characters. Key names can begin with a numeric character. Key names can have a maximum length of 64 characters.

Note Once you have created the name of an HTTPS key, you cannot modify it. You need to delete the existing key and create a new one. Only HTTPS key names are stored in the CMS database. The actual certificates are stored on the Content Engine.

Step 6 In the Key URL field, specify the external location from which the private key is to be imported. The URL must be a valid URL using HTTP, FTP, or HTTPS. The key value is imported when you specify the URL and submit changes.

A key name without imported values can be listed in the Content Distribution Manager GUI; however, only keys with valid values can be associated with an HTTPS server. Two different keys can be imported from the URL and two different HTTPS servers can be associated with the same key.

After a key is imported from the Content Distribution Manager GUI, a new icon (Re-import) appears in the taskbar. The Re-import icon can be used to reimport the key if the import did not succeed the first time.

Step 7 In the Username field, specify the username required to access the external source from which the key is being imported. An entry is required in this field only if the external source is password-protected.

Step 8 In the Password field, specify the password used to authenticate users who want to gain access to the external source from which the key is being imported. An entry is required in this field only if the external source is password-protected. Reenter the password in the Confirm Password field.

Step 9 To view a subset of the entire list of HTTPS keys, click the Filter Table icon in the taskbar. See the next section "Filtering HTTPS Keys for the Content Engine" for more details.

Step 10 To revert to the display of all configured HTTPS keys, click the View All HTTPS Keys icon in the taskbar.

Step 11 To save the settings, click Submit.

Table 8-12 HTTPS Key Settings

GUI Parameter

Function

CLI Command

Key Name

Name of the key.

https server name key name password password

Key URL

External location from which the private key is to be imported.

Password

Password to decrypt the private key file.

Filtering HTTPS Keys for the Content Engine

You can use the Content Distribution Manager GUI to filter and display a subset of HTTPS keys by the private key name and URL.

To set the filter criteria to display selected HTTPS keys, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to filter HTTPS keys. The Device Home for Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > Keys. The HTTPS Keys for Content Engine window appears. The keys created for device groups can only be viewed; they cannot be modified.

Step 4 Click the Filter Table icon in the taskbar. The Filtering HTTPS Keys for Content Engine window appears.

Step 5 Choose a filter operator from the Key Name drop-down list and enter the name of the key that must be matched.

Step 6 Choose a filter operator from the Key URL drop-down list and enter the key location that must be matched.

Step 7 To revert to the display of all configured HTTPS keys, click the View All HTTPS Keys icon in the taskbar. Table 8-13 describes the filter operators for filtering HTTPS keys.

Step 8 Click Submit. The HTTPS Keys for Content Engine window reappears, displaying a list of all keys that match the specified filter criteria.

Table 8-13 Filtering HTTPS Keys

Filter Operators

Description

Like

Includes HTTPS keys with a setting that is similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or `, use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS keys with a name that begins with httpskey and is followed by a single character, enter httpskey_ in the Station Name field. Any key with the name Httpskey is not displayed.

Not like

Includes HTTPS keys with a setting that is not similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or `, use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, if you want to display HTTPS keys except the ones with a URL that starts with ftp://, you should enter %ftp:// in the Media field. Any key with the URL https://a.com or http://a.com is displayed.

In

Includes keys with settings that are present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (`) when the specified string contains commas or parentheses.

For example, to display keys with names KEY1, KEY2, and KEY(3), enter (KEY1,KEY2,`KEY(3)') or KEY1,KEY2,`KEY(3)' in the Key Name field. Keys with names such as KEY4 and KEY5 are not displayed.

Not in

Includes keys with settings that are not present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (`) when the specified string contains commas or parentheses.

For example, to display keys except the ones with names KEY1, KEY2, and KEY(3), enter (KEY1,KEY2,`KEY(3)') or KEY1,KEY2,`KEY(3)' in the Key Name field. Keys with the names such as KEY4 and KEY5 are displayed.

Equal to

Includes keys with a setting that is exactly the same as the string entered.

For example, to display all keys imported from the URL http://Location1, enter http://Location1 in the Key URL field. Keys imported from http://Location^1 are not displayed. You cannot use keywords, special characters, or wildcard characters.

Not equal to

Includes keys with a setting that is not exactly the same as the string entered.

For example, to display all keys not imported from the URL http://Location1, enter http://Location1 in the Key URL field. Keys imported from http://Location^1 are displayed. You cannot use keywords, special characters, or wildcard characters.

Configuring HTTPS Proxy Settings

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.

Note A Domain Name System (DNS) server must be configured to support HTTPS proxy requests. See the "Configuring the DNS Server for HTTP Proxy Caching" section for more information.

To configure HTTPS proxy parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Note HTTPS proxy parameters can be configured for individual Content Engines or for device groups. This procedure describes the steps for configuring an HTTPS proxy for a device group.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > HTTPS > HTTPS Proxy. The HTTPS Proxy Settings for Content Engine window appears. (See Figure 8-9 and Figure 8-10.) Table 8-14 describes the fields in these windows.

Figure 8-9 HTTPS Proxy Settings Window—Top

Step 4 To allow the Content Engine to accept incoming requests on ports in addition to port 80, check the Enable Incoming Proxy check box.

Step 5 In the List of Incoming Ports field, enter the port numbers used by the proxy server. Separate numbers with a space.

Step 6 To configure the TCP server connection's read/write timeout, check the Enable TCP check box.

Step 7 In the TCP Read/Write Timeout field, enter a value in seconds for the read/write timeout. The range is from 1 to 3600, and the default is 120 seconds.

Step 8 To enable the use of an outgoing proxy, if needed, check the Enable Outgoing Proxy check box.

Step 9 If HTTPS traffic is to be allowed on all ports, check the Allow All Ports check box.

Step 10 If HTTPS traffic is to be allowed on port 443, check the Allow port 443 check box.

Step 11 If HTTPS traffic is to be allowed on port 563, check the Allow port 563 check box.

Step 12 In the Other Allow Port List field, enter a list of port numbers on which HTTPS traffic is to be allowed, and separate each number with a space This field is required if an outgoing proxy is enabled. The range is from 1 to 65535. Up to eight ports can be configured. Ports 443 and 563 are allowed by default.

Step 13 If HTTPS traffic is to be blocked on all ports, check the Deny All Ports check box.

Step 14 In the Deny Port List field, enter a list of port numbers on which HTTPS requests must be rejected. Separate each number with a space. This field is required if an outgoing proxy is enabled.

The range is from 1 to 65535. Up to 8 ports can be configured. Ports under 1024 are denied for HTTPS requests by default. This ensures that unwanted access to any HTTPS port is prevented when a request goes through the Content Engine

Step 15 To enable the outgoing proxy configuration fields, check the Enable Outgoing Proxy check box. (See Figure 8-10.)

Figure 8-10 HTTPS Proxy Settings Window—Bottom

Step 16 To use the origin server if all outgoing proxies fail, check the Use Origin Server check box. If all the configured proxy servers fail, the Content Engine can optionally redirect HTTPS requests to the origin server specified in the HTTPS header if you have checked this check box. If this option is not enabled, the client receives an error response. Response errors and read errors are returned to the client, because it is not possible to detect whether these errors are generated at the origin server or at the proxy.

Step 17 Enter a value in microseconds in the Outgoing Connection Timeout field. This value specifies the number of microseconds before the outgoing proxy servers are probed to see whether they are active.

Step 18 Enter a value in the Outgoing Monitor Period field to specify how frequently the Content Engine polls the specified outgoing HTTPS proxy servers.

A background process on the Content Engine monitors the state of the configured outgoing proxy servers. You can configure the Content Engine to poll the specified outgoing proxy servers at a specific time in order to monitor their availability. The outgoing monitor period is the time during which the proxy servers are polled. The monitoring period is specified in seconds, and can be from 10 to 300 seconds. The default monitoring period is 60 seconds. If one of the outgoing proxy servers is unavailable, the polling mechanism waits for the connect timeout (300000 microseconds) before polling the next outgoing proxy server.

Step 19 In the Outgoing Proxy Hostname fields 1 through 8, specify an IP address or host name if an outgoing proxy is enabled. The server configured in the first field becomes the primary outgoing HTTPS proxy server for the Content Engine. This field is required if an outgoing proxy is enabled.

You can configure up to eight HTTPS outgoing proxy servers for each Content Engine. At any one time, the Content Engine uses only one of the configured outgoing HTTPS proxy servers. They cannot be used simultaneously.

Step 20 In the Outgoing Proxy Port fields 1 through 8, specify a port number that will be used by the outgoing proxy server to accept proxy HTTPS requests if an outgoing proxy is enabled. (A port is required for the primary server entered in the Hostname field.)

Step 21 To save the settings, click Submit.

A "Click to Submit" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings but the settings have not yet been submitted.

Table 8-14 shows the GUI parameters and CLI commands associated with HTTPS proxy features. The order in which the CLI commands are entered is not important.

Table 8-14 HTTPS Proxy Settings

GUI Parameter

Function

CLI Command

Enable incoming proxy

Configures the Content Engine to accept incoming HTTPS traffic request on ports in addition to port 80.

https proxy incoming

List of incoming ports

Supports up to 8 incoming proxy ports.

https proxy incoming port 1-65535, port, . . .

Enable TCP

Enables the TCP Read/Write Timeout field.

—

TCP Read/Write Timeout

Configures the TCP server connection's read/write timeout. The range is from 1 to 3600, and the default is 120 seconds.

https tcp-rw-timeout seconds

Enable outgoing proxy

Enables an outgoing HTTPS proxy server.

https proxy outgoing host {hostname | ipaddress} port 1-65535

Allow All ports

Allows HTTPS traffic on all ports.

https destination-port allow all

Allow port 443

Allows HTTPS traffic on port 443.

https destination-port allow 443

Allow port 563

Allows HTTPS traffic on port 563.

https destination-port allow 563

Other Allow Port List

List of port numbers on which HTTPS traffic is to be allowed (required, if an outgoing proxy is enabled).

The range is 1-65535. Up to 8 ports can be configured. Ports 443 and 563 are allowed by default.

https destination-port allow port_num port_num port_num . . .

Deny All ports

Denies HTTPS traffic on all ports.

https destination-port deny all

Deny Port List

List of port numbers on which HTTPS requests must be rejected (required, if an outgoing proxy is enabled).

https destination-port deny ports

Enable Outgoing Proxy

Enables the fields in the GUI window for configuring the outgoing proxy settings.

—

Use Origin Server

Redirects HTTPS requests to the origin server specified in the HTTPS header.

https proxy outgoing origin-server

Outgoing Connection Timeout

Timeout period (in microseconds) to use when probing for outgoing proxy servers. The range is from 200 to 5000000. The default value is 300 microseconds.

https proxy outgoing connection-timeout microsecs

Outgoing Monitor Period

Specifies the interval in seconds at which to monitor one outgoing proxy server. If multiple outgoing proxy servers are configured, they are monitored sequentially. The default value is 200 seconds.

https proxy outgoing monitor seconds

Outgoing Proxy Hostname 1-8

IP address or host name of the HTTPS outgoing proxy server.

https proxy outgoing host {hostname | ipaddress}

Outgoing Proxy Port 1-8

Port of the HTTPS outgoing proxy server.

https proxy outgoing host {hostname | ipaddress} port 1-65535

Note HTTPS traffic is encrypted and cannot be interpreted by the Content Engine or any other device between the web client and the origin server. HTTPS objects are not cached.

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Configuring HTTPS Servers

You can configure an HTTPS server and configure a caching solution to allow a Content Engine act as an origin HTTPS server. This configuration can reduce WAN traffic and increase data security because authorized clients from remote branch offices can access their own Content Engines, which are configured as HTTPS servers, by using HTTPS.

The Content Engine decodes HTTPS traffic from a client and perform normal HTTP operations on it, such as caching and request processing. The Content Engine will initiate HTTPS connections to an origin server and fetch content from origin servers upon a cache miss or cache validation.

Some restrictions exist concerning the usage of certificates, keys, and certificate groups.

•A certificate without valid imported values cannot be associated with a certificate group.

•A certificate group without added certificates cannot be associated with an HTTPS server.

•A certificate used by an HTTPS server cannot be modified or deleted.

•A certificate group used by an HTTPS server cannot be modified or deleted.

•A certificate added to a certificate group cannot be modified or deleted.

•A key used by an HTTPS server cannot be modified or deleted.

To configure HTTPS servers for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to configure HTTPS servers. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > HTTPS Servers. The HTTPS Servers for Content Engine window appears.

Step 4 The Aggregate Settings Yes radio button is selected by default. This means that HTTPS servers are displayed for the Content Engine as well as for any associated device groups. The settings for the HTTPS servers for device groups cannot be modified or deleted; they are read-only. However, you can modify the HTTPS servers for the Content Engine. If you click the Aggregate Settings No radio button, you can view and modify the HTTPS servers for the Content Engine only. The HTTPS servers for any associated device groups are not even displayed.

Step 5 To configure an HTTPS server, click the Create New HTTPS Server icon in the taskbar. The Creating new HTTPS Server for Content Engine window appears.

To configure HTTPS servers, you need to configure three sets of settings:

•HTTPS Servers

•Certificate Key/Associations

•General HTTPS Settings

Step 6 Under the HTTPS Server section, follow these steps:

a. In the Name field, specify the name of the HTTPS server. Server names can consist of Arabic numerals and upper- and lowercase alphabetic, underscore, hyphen, and period characters. Server names must begin with an alphabetic character or underscore and have a limit of 15 characters.

b. To enable caching and SSL termination for the HTTPS server, check the Enable check box. You must have entered the host name, certificate or certificate group, and private key before an HTTPS server can be enabled.

c. In the Host Name field, specify the IP address or fully qualified domain name for the origin HTTPS server. Two different HTTPS servers cannot have the same host name.

Each active server has one or more IP addresses associated with it, specified either as an IP address or a domain name that is resolved to one or more IP addresses. An HTTPS request arriving at a Content Engine (either by WCCP intercept or by direct proxy) is matched with a server configuration that will be used to handle the request by comparing the target IP address of the request with the IP addresses associated with the active servers.

Step 7 Under the Certificate Key/Associations section, follow these steps:

a. Choose the certificate group for the HTTPS server from the Server Certificate drop-down list. All certificate groups created using the HTTPS Certificate Groups for Content Engine window will be displayed here.

The certificate group is included in the SSL handshake that is sent to SSL clients. Only one certificate group can be selected for an HTTPS server at a time. SSL Version 2 does not support certificate groups.

b. Choose the certificate chains and authentication needed to access the HTTPS server from the Authenticating Certificate Group drop-down list. All certificate groups created using the HTTPS Certificate Groups for Content Engine window are displayed here. Only one certificate group can be selected for an HTTPS server at a time.

SSL Version 2 does not support certificate groups.

c. From the Certificate drop-down list, choose a specific SSL certificate so that the Content Engine can act as an origin HTTPS server while authenticating clients. All certificates created using the HTTPS Certificates for Content Engine window are displayed here. Only one certificate can be selected for an HTTPS server at a time.

d. From the Private Key drop-down list, choose a private key so that the Content Engine can act as an origin HTTPS server while authenticating clients. This private key must match the selected certificate. All keys created using the HTTPS Keys for Content Engine window are displayed here. Only one key can be selected for an HTTPS server at a time.

e. If the private key file is encrypted, in the Private Key Password field, specify the password required to decrypt it. Reenter the password in the Confirm Password field.

Step 8 Under the General HTTPS Settings section, follow these steps:

a. In the SSL cache size field, specify the number of SSL session caching entries. This indicates the maximum number of entries that can be stored in the cache before the origin HTTPS server must be contacted.

b. In the SSL cache Timeout field, specify the SSL session cache timeout in seconds. The Content Engine contacts the origin server to authenticate clients once this value is exceeded.

c. Choose the protocol versions to be used for communication between clients and HTTPS servers from the Protocol Version drop-down list. Table 8-15 shows the protocol versions available.

d. To enable server certificate authentication for the HTTPS server, check the Enable Authentication check box. This option is enabled by default.

e. To ignore errors caused by using the certificate before it is valid, check the Ignore CertNotNetYetValid Error check box.

f. To ignore errors due to domain name mismatch, check the Ignore DomainName Error.

g. To ignore certificate expiration errors, check the Ignore ExpiredDate Error check box.

h. To ignore errors caused by an unrecognized Certificate Authority (CA), check the Ignore InvalidCA Error check box.

Table 8-15 Protocol Versions

Protocol Version

Description

SSL v2

Sets the use of the SSL Version 2 protocol only.

SSL v23 and TLS v1

Sets the use and understanding of the SSL Version 2 or Version 3 and Transport Layer Security (TLS) Version 1 protocol.

SSL v3

Sets the use and understanding of the SSL Version 3 protocol only.

TLS v1

Sets the use and understanding of the TLS Version 1 protocol only.

Step 9 To save the settings, click Submit.

Filtering HTTPS Servers for the Content Engine

You can use the Content Distribution Manager GUI to filter and display a subset of HTTPS servers by server name, status (enabled or disabled), host name, SSL cache size, SSL cache timeout, protocol version, status of server certificate authentication (enabled or disabled), and status of server certificate authentication error tracking (enabled or disabled).

To set the filter criteria to display selected HTTPS servers, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to filter HTTPS servers. The Device Home for Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > HTTPS > HTTPS Servers. The HTTPS Servers for Content Engine window appears.

Step 4 Click the Filter Table icon in the taskbar. The Filtering HTTPS Server Entries for Content Engine window appears.

Step 5 From the Name drop-down list, choose a filter operator, and enter the name of the server that must be matched.

Step 6 From the Enable drop-down list, choose a filter operator, and from the second drop-down list, choose whether or not you want to view servers on which HTTPS caching is enabled.

Step 7 From the Host drop-down list, choose a filter operator, and enter the IP address or fully qualified domain name of the host that must be matched.

Step 8 From the SSL cache Size drop-down list, choose a filter operator, and enter the size of the SSL cache that must be matched.

Step 9 From the SSL cache Timeout drop-down list, choose a filter operator, and enter the timeout (in seconds) that must be matched.

Step 10 From the Protocol Version drop-down list, choose a filter operator, and enter the version of the communication protocol that must be matched.

Step 11 From the Enable Authentication drop-down list, choose a filter operator, and choose whether or not you want to view HTTPS servers for which server certificate authentication is enabled.

Step 12 From the CertNotNetYetValid Error drop-down list, choose a filter operator, and choose whether or not you want to view HTTPS servers for which errors caused by using the certificate before it is valid are ignored.

Step 13 From the Ignore DomainName Error drop-down list, choose a filter operator, and choose whether or not you want to view HTTPS servers for which errors due to domain name mismatch are ignored.

Step 14 From the Ignore ExpiredDate Error drop-down list, choose a filter operator, and choose whether or not you want to view HTTPS servers for which certificate expiration errors are ignored.

Step 15 From the Ignore InvalidCA Error drop-down list, choose a filter operator, and choose whether or not you want to view HTTPS servers for which errors caused by an unrecognized Certificate Authority (CA) are ignored.

Step 16 Click Submit. The HTTPS Servers for Content Engine window reappears, displaying a list of all servers that match the specified filter criteria.

Step 17 To revert to the display of all configured HTTPS servers, click the View All HTTPS Servers icon in the taskbar.

Table 8-16 Filtering HTTPS Servers

Filter Operators

Description

Like

Includes HTTPS servers with a setting that is similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or `, use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS servers with a name that begins with httpscer and are followed by a single character, enter httpscer_ in the Name field. Any server with the name Httpscer is not displayed.

Not like

Includes HTTPS servers with a setting that is not similar to the string entered. Use the percent sign (%) wildcard characters to match zero or more characters, and use the underscore (_) wildcard character to match exactly one character. If the string contains special characters such as ^, (, ), or `, use the escape character, a backslash (\), to ignore the meaning of such special characters. Any character except a % or _ can follow the escape character. Wildcard characters following an escape character are treated as literal characters.

For example, to display HTTPS servers except the ones with the URL that starts with httpscer, enter httpscer in the Name field. Any certificate with the name Httpscer is displayed.

In

Includes servers with names that are present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (') when the specified string contains commas or parentheses.

For example, to display servers with the names CER1, CER2, and CER(3), enter (CER1,CER2,`CER(3)') or CER1,CER2,`CER(3)' in the Server Name field. Servers with names such as CER4 and CER5 are not displayed.

Not in

Includes servers with settings that are not present in the list of specified strings. You can specify either a single string or a list of strings separated by commas. Use single quotes (`) when the specified string contains commas or parentheses.

For example, to display servers except the ones with the names CER1, CER2, and CER(3), enter (CER1,CER2,`CER(3)') or CER1,CER2,`CER(3)' in the Server Name field. Servers with names such as CER4 and CER5 are displayed.

Equal to

Includes servers with a setting that is exactly the same as the string or the value entered, or with a setting that matches the configuration chosen from the drop-down list.

For example, to display an HTTPS server with the host name host1, enter host1 in the Host field. An HTTPS server with the host name host2 is not displayed. You cannot use keywords, special characters, or wildcard characters.

Not equal to

Includes servers with a setting that is not exactly the same as the string or the value entered, or with a setting that does not match the configuration chosen from the drop-down list.

For example, to display all HTTPS servers except the one with protocol version sslv2-only, enter SSL v2 in the Protocol Version field. Any HTTPS server with the protocol version sslv3-only is displayed. You cannot use keywords, special characters, or wildcard characters.

Greater than

Includes servers with SSL cache size, SSL cache timeout, and protocol version higher than the value entered.

For example, to display all HTTPS servers for which the number of SSL session caching entries exceeds 1000, enter 1000 in the SSL cache size field. Any HTTPS server with a cache size lesser than or equal to 1000 is not displayed.

Less than

Includes servers with SSL cache size, SSL cache timeout, and protocol version lower than the value entered.

For example, to display all HTTPS servers for which the SSL session cache timeout is less than 1000 seconds, enter 1000 in the SSL cache timeout field. Any HTTPS server with an SSL session cache timeout greater than or equal to 1000 seconds is not displayed.

Greater than or equal to

Includes servers with SSL cache size, SSL cache timeout, and protocol version higher than or equal to the value entered.

For example, to display all HTTPS servers for which the number of SSL session caching entries exceeds 1000, enter 1000 in the SSL cache size field. Any HTTPS server with a cache size less than 1000 is not displayed.

Less than or equal to

Includes servers with SSL cache size, SSL cache timeout, and protocol version lower than or equal to the value entered.

For example, to display all HTTPS servers for which the SSL session cache timeout in seconds is lesser than or equal 1000, enter 1000 in the SSL cache timeout field. Any HTTPS server with an SSL session cache timeout greater than 1000 seconds is not displayed.

Transparent HTTPS Caching Using SSL

Caching an HTTPS client request using SSL termination means that the Content Engine decrypts the SSL-encrypted data. By decrypting the SSL-encrypted data, the Content Engine can see the HTTPS client request in plain text, which allows the Content Engine to perform numerous HTTP processing tasks (for example, caching, rule processing, and filtering) on such requests.

Transparent HTTPS caching using SSL works as follows:

1. The Content Engine, configured as an HTTPS server, receives an HTTPS request redirected through a WCCP-enabled router.

2. The Content Engine sends back an SSL certificate (obtained from the origin server) to the requesting client to negotiate an SSL connection.

3. The client sends HTTPS requests inside the negotiated SSL connection.

4. The Content Engine examines the request, looks in its cache, and performs normal HTTP request processing.

5. If the Content Engine can fulfill the request from its local storage (cache hit), it sends the requested content back using the SSL connection.

6. If the Content Engine cannot fulfill the request from its local storage (cache miss), it initiates a connection to the origin server to retrieve the requested content through the SSL connection.

7. The Content Engine caches the requested content (if possible) and also sends a copy to the requesting client through the negotiated SSL connection.

For the SSL-termination feature to work properly, you must install the SSL certificate and private key of the origin HTTPS servers on the Content Engine. The SSL-termination feature works in both transparent mode and proxy mode if the Content Engine has the correct certificates and private keys installed. For specific requested content to be cached, you must import the proper certificates and keys for these origin HTTPS servers into the Content Engine and configure the Content Engine to cache content from these origin HTTPS servers. See the "Configuring HTTPS Certificates" section.

Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings

When in transparent caching mode, the Content Engine can intercept requests sent to another proxy and send these requests to one of the following two destinations:

•Default server—This is the default option. The Content Engine retrieves the objects from the web server itself, or if it is configured to use an outgoing proxy for this protocol, it forwards the request to its outgoing proxy. In this scenario, the client browser configuration is ignored, and the Content Engine configuration is used to retrieve the object from the server.

•Original proxy—The Content Engine forwards the request to the proxy to which the client had originally addressed the request. This proxy may be different from the Content Engine's own outgoing proxy for the specified protocol.

ACNS 5.x software also has an option that allows the administrator to specify a single domain name, host name, or IP address to be globally excluded from proxy forwarding. Domains are entered as an ASCII string, separated by spaces. The wildcard character * (asterisk) can be used for IP addresses (for instance, 172.16.*.*). Requests with a destination specified with wildcard characters bypass the Content Engine proxy as well as the failover proxies.

To configure proxy protocol parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose Applications > Web > Outgoing Proxy Exclusions. The Outgoing Proxy Exclusions window appears. (See Figure 8-11.) Table 8-17 describes the fields in this window.

Figure 8-11 Outgoing Proxy Exclusions Settings Window

Step 4 To intercept requests sent to another proxy and send these requests to either the origin server or a specified proxy server, check the Enable Outgoing Proxy Exclusion check box.

Step 5 Enter domain names, IP addresses, or host names, each separated by a space, in the Outgoing Proxy Exclude List field. The item entered here is globally excluded from proxy forwarding. You can also specify the asterisk (*) wildcard character to match any IP address to be excluded.

Step 6 To set the transparent mode behavior for proxy-style requests, check the Enable Transparent Mode check box.

Step 7 Choose default-server, original-proxy, or reset from the Transparent Proxy Mode drop-down list. Table 8-17 explains these options.

Table 8-17 Proxy Protocols Key Parameters

Key Parameter

Function

CLI Command

Default-server

The Content Engine retrieves objects from the web server itself. With this option, a proxy-style request can be sent to an outgoing proxy server if such a server is configured. If no outgoing proxy server is configured, then the request is served by the origin server and the Content Engine.

proxy-protocols transparent default-server

Original-proxy

The Content Engine forwards the request to the original proxy that the client addressed the request to.

proxy-protocols transparent original-proxy

Reset

This option resets the transparent proxy mode to use the default server. The request will be returned to the client during a cache miss. The client does not obtain the requested object in this mode.

proxy-protocols transparent reset

Step 8 To save the settings, click Submit.

A "Click to Submit" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings but the settings have not yet been submitted.

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Configuring FTP Settings

You can configure, modify, and view FTP settings for Content Engines and device groups by completing the following tasks:

•Configuring FTP-Over-HTTP Connection Settings

•Configuring FTP-Over-HTTP Cache Freshness

•Configuring Native FTP Connections

•Configuring the Client Side of Nontransparent Native FTP Caching

•Configuring Native FTP Cache Freshness

•Enabling Inetd FTP Service

•Configuring Native FTP Custom Messages

You can configure the Content Engine for FTP caching in either of the following two usage modes:

•FTP-over-HTTP mode. The Content Engine (nontransparent forward proxy server) caches the contents of the specified FTP URLs that are sent to it directly by clients that are using the HTTP protocol. This mode allows users to use their browsers (HTTP protocol) to access files (to send and receive files) on remote FTP servers.

•Native FTP mode. The Content Engine caches the content of the FTP requests that are sent from clients in the native FTP protocol. In ACNS 5.4, native FTP caching is supported in transparent and nontransparent proxy mode. (Native FTP caching was only supported in transparent proxy mode in the ACNS 5.1 and 5.2 software releases.)

In both of these usage modes, the Content Engine uses the FTP protocol to retrieve and locally cache the content of the FTP requests. These two usage modes differ in the protocol used by the client to issue the FTP request. In FTP-over-HTTP mode, clients use their browsers (the HTTP protocol) to issue FTP requests. In native FTP mode, clients use the native FTP protocol to issue FTP requests.

Note Transparent redirection of FTP requests is supported only by WCCP Version 2; transparent redirection through a Layer 4 switch is not supported.

Note In ACNS 5.3.1 software, the following changes were made to FTP-related commands:

•show ftp proxy EXEC command has been replaced by show ftp-native and show ftp-over-http.

•show statistics ftp EXEC command has been replaced by show statistics ftp-over-http and show statistics ftp-native.

•clear statistics ftp EXEC command has been replaced by clear statistics ftp-over-http and clear statistics ftp-native.

FTP-over-HTTP Caching

ACNS 5.4 software supports proxying and caching of FTP URL client requests using proxy-mode HTTP requests when URLs specify the FTP protocol (for example, ftp://ftp.mycompany.com/ftpdir/ftp_file). For instance, the following is an example of an FTP-over-HTTP request that allows the end user to use a browser to access public files from an FTP server:
ftp://ftp.funet.fi/pub/cbm/crossplatform/converters/unix/
For these requests, the client uses HTTP as the transport protocol with the Content Engine, whereas the Content Engine uses FTP with the FTP server. When the Content Engine receives an FTP request from the web client, it first looks in its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server (if one is configured), or directly from the origin FTP server.

The FTP proxy supports anonymous as well as authenticated FTP requests. Only base64 encoding is supported for authentication. The FTP proxy accepts all FTP URL schemes defined in RFC 1738. In the case of a URL in the form ftp://user@site/dir/file, the proxy sends back an authentication failure reply and the browser supplies a popup window for the user to enter login information.

The FTP proxy supports commonly used MIME types, attaches the corresponding header to the client, chooses the appropriate transfer type (binary or ASCII), and enables the browser to open the FTP file with the configured application. For unknown file types, the proxy uses binary transfer as the default and instructs the browser to save the downloaded file instead of opening it. The FTP proxy returns a formatted directory listing to the client if the FTP server replies with a known format directory listing. The formatted directory listing has full information about the file or directory and provides the ability for users to choose the download transfer type.

The Content Engine can apply the Rules Template to FTP requests based on server name, domain name, server IP address and port, client IP address, and URL.

The Content Engine logs FTP transactions in the transaction log, in accordance with Squid syntax.

Configuring FTP-Over-HTTP Connection Settings

The Content Engine can handle FTP-style requests over HTTP 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.

To configure FTP-over-HTTP connection settings by using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears. (Alternatively, choose Devices > Devices.)

Step 2 Click the Edit icon next to the name of the device group (or Content Engine) that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > FTP > FTP Over HTTP Connections. The FTP Connection Settings window appears. (See Figure 8-12.) Table 8-18 describes the fields in this window.

Figure 8-12 FTP-Over-HTTP Connection Settings for Device Group Window

Step 4 To activate the Anonymous FTP Password field, check the Enable Proxy Caching check box.

Step 5 To enable the Content Engine to act in FTP active mode, check the Enable Incoming Active Mode check box. If active mode is enabled, the Content Engine attempts to fetch the object in active mode. If active mode fails, the Content Engine attempts to fetch the object again in passive mode.

Step 6 To accept incoming FTP-over HTTP requests on ports in addition to port 80, check the Enable Incoming Proxy check box.

Step 7 In the List of Incoming Ports field, enter port numbers used by the FTP proxy server or Content Engine to receive requests. The range is from 1 to 65535. Up to eight ports are allowed.

Step 8 In the Anonymous FTP Password field, enter the anonymous password (for example, wwwuser@cisco.com) needed to access the FTP proxy server. The default is anonymous@hostname.

Step 9 In the Confirm Anonymous FTP Password field, reenter the anonymous password needed to access the FTP proxy server.

Step 10 To allow an outgoing FTP proxy server or another Content Engine to receive FTP cache miss request traffic, check the Enable Outgoing Proxy check box.

Step 11 To use the origin server if all outgoing proxies fail, check the Use Origin Server check box. If all the configured proxy servers fail, the Content Engine can optionally redirect FTP requests to the origin server specified in the FTP header if you have checked this check box. If this option is not enabled, the client receives an error response. Response errors and read errors are returned to the client, because it is not possible to detect whether these errors are generated at the origin server or at the proxy.

Step 12 Enter a value in microseconds in the Outgoing Connection Timeout field. This value specifies the number of microseconds before the outgoing proxy servers are probed to see whether they are active.

Step 13 To specify how frequently the Content Engine polls the specified outgoing FTP proxy servers, enter a value in the Outgoing Monitor Period field.

A background process on the Content Engine monitors the state of the configured outgoing proxy servers. You can configure the Content Engine to poll the specified outgoing proxy servers at a specific time in order to monitor their availability. The outgoing monitor period is the time during which the proxy servers are polled. The monitoring period is specified in seconds, and can be from 10 to 300 seconds. The default monitoring period is 60 seconds. If one of the outgoing proxy servers is unavailable, the polling mechanism waits for the connect timeout (300000 microseconds) before polling the next outgoing proxy server.

Step 14 In the Outgoing Proxy Host Name field, enter the host name or IP address for the outgoing FTP proxy.

Step 15 In the Outgoing Proxy Port field, enter a port number corresponding to the outgoing proxy host name from Step 14. The range is from 1 to 65535, and up to eight ports are allowed. In proxy mode, the Content Engine accepts and serves FTP requests only on the ports specified. All FTP requests on other proxy-mode ports are rejected.

The Content Engine supports both anonymous and authenticated FTP requests. In the case of the URL ftp//user@site/dir/file, the proxy sends back an authentication failure reply and the browser displays a popup window for you to enter login information.

Step 16 To save the settings, click Submit.

A "Click to Submit" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings but the settings have not yet been submitted.

Table 8-18 FTP-Over-HTTP Connection Settings

GUI Parameter

Function

CLI Command

Enable Proxy Caching

Enables the Anonymous FTP Password field.

—

Enable Incoming Active Mode

Configures the Content Engine to support FTP active mode. Passive mode is the default.

ftp-over-http proxy active-mode enable

Enable Incoming Proxy

Configures the Content Engine to accept incoming FTP requests on ports in addition to port 80.

ftp-over-http proxy incoming portnum

List of Incoming Ports

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.

Anonymous FTP Password

Password required to access the outgoing FTP proxy server.

ftp-over-http proxy anonymous-pswd password

Confirm Anonymous FTP Password

Repeat the password required to access the outgoing FTP proxy server.

—

Enable Outgoing Proxy

Configures an outgoing proxy server or another Content Engine, without using ICP or WCCP, to receive FTP cache miss request traffic.

ftp-over-http proxy outgoing

Use Origin Server

When enabled, handles requests using the origin server if all outgoing proxy servers fail. If disabled, the user receives an error message if all outgoing proxy servers fail.

ftp-over-http proxy outgoing origin-server

Outgoing Connection Timeout

Timeout period (in microseconds) to use when probing for outgoing proxy servers. The range is from 200 to 5000000. The default value is 300 microseconds.

ftp-over-http proxy outgoing connection-timeout microsecs

Outgoing Monitor Period

Specifies the interval in seconds at which to monitor one outgoing proxy server. If multiple outgoing proxy servers are configured, they are monitored sequentially. The default value is 200 seconds.

ftp-over-http proxy outgoing monitor seconds

Outgoing Proxy Hostname 1-8

Configures multiple outgoing proxy servers. Enter the host name or IP address for the outgoing FTP proxy server.

ftp-over-http proxy outgoing host {hostname | ipaddress}

Outgoing Proxy Port 1-8

Port number corresponding to the outgoing FTP proxy host names.

ftp-over-http proxy outgoing host {hostname | ipaddress} portnum

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Configuring FTP-Over-HTTP Cache Freshness

You can configure FTP cache object freshness parameters for Content Engines on the ACNS network using the FTP Cache Freshness Settings window from the Content Distribution Manager GUI. These parameters can be configured for either directory listings or particular objects in the cache.

To configure FTP freshness parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears. (Alternatively, choose Devices > Devices.)

Step 2 Click the Edit icon next to the name of the device group (or Content Engine) that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > FTP > FTP Over HTTP Cache Freshness. (See Figure 8-13.) Table 8-20 describes the fields in this window.

Figure 8-13 FTP-Over-HTTP Cache Freshness Settings Window

Step 4 To enable FTP cache freshness settings on the Content Engine, check the Enable check box.

Step 5 Specify a value for the Directory Listing Age Multiplier field.

The age multiplier 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 6 Specify a value for the File Object Age Multiplier field.

The age multiplier 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 7 Choose days, hours, minutes, or seconds from the Max 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 8 Specify a value for the Max Directory Listing TTL field. Table 8-19 provides the valid range of values.

Table 8-19 Time To Live Range of Values for FTP Freshness

Scale

Range

Days

1-1825

Hours

1-43800

Minutes

1-2628000

Seconds

1-157680000

Step 9 Specify a value for the Max File Object TTL field.

See Table 8-19 for a list of maximum values depending on the scale used.

Step 10 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 11 To enforce the maximum object size specified in the next step, check the Enforce Max Object Size check box.

Step 12 Specify a value in the Max Object Size field.

This value represents the maximum object size (in kilobytes) that can be stored. The range of values is 1 to 204800 kilobytes. The default value is set to the maximum value of 1048576 kilobytes.

Step 13 Choose a method for handling reevaluation requests from the Re-eval Request drop-down list.

You can apply these FTP cache freshness parameters to the directory listing (directory-listing) or to objects as well as the directory listing (all). You can also choose not to apply a TTL scale to these parameters (none). In this case, a TTL is not applied, and objects in the cache have no expiration dates.

Step 14 To save the settings, click Submit.

A "Click to Submit" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings but the settings have not yet been submitted.

Table 8-20 FTP-over-HTTP Cache Freshness Settings

GUI Parameter

Function

CLI Command

Enable

Enables cache freshness settings.

—

Directory Listing Age Multiplier

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.

ftp-over-http age-multiplier directory-listing dl_time file fo_time

File Object Age Multiplier

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.

Max TTL Scale

Sets the unit of time for the maximum directory listing or file object TTL.

ftp-over-http max-ttl {days directory-listing dlmax_days file fmax_days | hours directory-listing dlmax_hours file fmax_hours | minutes directory-listing dlmax_min file fmax_min | seconds directory-listing dlmax_sec file fmax_sec}

Max Directory Listing TTL

Sets a ceiling on estimated expiration dates for directory listings.

Max File Object TTL

Sets a ceiling on estimated expiration dates for file objects.

Minimum TTL

Minimum Time To Live for objects in the cache.

ftp-over-http min-ttl min_minutes

Enforce Max Object Size

Stops the Content Engine from caching objects that exceed the specified maximum size.

ftp-over-http object max-size size

Max Object Size

Maximum object size (in kilobytes) that can be stored.

Re-eval Requests

Configures how reevaluation requests are to be handled.

ftp-over-http reval-each-request {all | none | directory-listing}

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Native FTP Caching

ACNS 5.4 software supports nontransparent native FTP caching, as well as transparent native FTP caching. With this capability, a Content Engine has the ability to handle native FTP requests from FTP clients in nontransparent mode.

When the Content Engine receives an native FTP request from an FTP client (for example, an native FTP request from a Reflection X or WS-FTP client or a UNIX or DOS command line FTP program), the Content Engine processes the request. If the requested content is already stored in its local cache, the Content Engine serves the content to the FTP client. If the content is not already stored in its local cache, the Content Engine has the ability to perform an FTP request to the origin FTP server to retrieve the content, and then store the content in its local cache. Native FTP requests are logged in the HTTP transaction log on the Content Engine.

Restrictions Regarding Native FTP Caching in ACNS 5.4 Software

Restrictions regarding native FTP caching support are as follows:

•Maximum FTP object size of 200 megabytes

•No support for bandwidth control for FTP client requests and FTP server pulls

•No support for the Type of Service (ToS) bit for FTP client requests

•No support for pre-positioned files in cdnfs

•No support for the Internet Content Adaptation Protocol (ICAP)

•No support for proxy authentication

•No support for the Internet Cache Protocol (ICP)

•No support for healing mode

•No support for Layer 4 switch FTP redirection

•No support for FTP request proxy rules

•No support for MIN-TTL and AGING-HEURISTIC-TTL cache control knob configurations

•No support for any URL filtering schemes (good list, bad list, N2H2, Websense, and SmartFilter)

•No support for caching files from a Macintosh FTP server

•No support for "offline" operation for the FTP proxy server

Configuring the Content Engine for Transparent Native FTP Caching

To configure the Content Engine for native FTP caching in transparent mode, you must enable the WCCP ftp-native service (service 60) on the Content Engine. The ftp-native service is the WCCP caching service that permits WCCP Version 2 routers to redirect native FTP requests transparently to a single port on the Content Engine. The Content Engine retrieves the requested FTP content, stores a copy locally (performs native FTP caching), and serves the requested content to the client.

(For information about how to configure the WCCP service for transparent native FTP caching, see the "Configuring WCCP Service Settings for the Content Engine" section on page 4-10.)

Configuring Native FTP Connections

To configure native FTP connections, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices (or Devices > Device Groups).

Step 2 Click the Edit icon next to the name of the Content Engine or device group that you want to configure.

Step 3 In the Contents pane, choose Applications > Web > FTP > Native FTP Connections. The Native FTP Connections Settings window appears. Table 8-21 describes the fields in this window.

Step 4 To enable the Content Engine to act in native FTP active mode, check the Enable Active Mode check box. If active mode is enabled, the Content Engine attempts to fetch the object in active mode, if the FTP client issues an active-mode data transfer request. (See the "About Native FTP Active and Passive Modes" section.)

Step 5 To enable native FTP proxy authentication, check the Enable Authentication check box. (See the "About Authenticating Native FTP Requests" section on page 15-13.)

Step 6 To accept incoming native FTP requests on ports in addition to port 21 (the standard FTP port), check the Enable Incoming Proxy check box.

Step 7 In the List of Incoming Ports field, list up to eight incoming port numbers separated by spaces (for example, 8021, 9021, and so forth).

Step 8 To save the settings, click Submit.

Table 8-21 Native FTP Connection Settings

GUI Parameter

Function

CLI Command

Enable Active Mode

Enables the Content Engine to act in native FTP active mode.

ftp-native proxy active-mode enable

Enable Authentication

Enables native FTP proxy authentication. The default is disabled. (See the "Considerations When Configuring Native FTP Proxied Authentication" section on page 15-14.)

ftp-native proxy authentication enable

Enable Incoming Proxy

Enables incoming native FTP requests on ports in addition to port 21.

ftp-native proxy incoming portnum portnum ...

List of Incoming Ports

Port numbers on which the Content Engine will accept incoming requests (native FTP requests) from FTP clients. Valid port numbers are 1 to 65535. You can specify up to eight incoming ports.

About Native FTP Active and Passive Modes

A Content Engine that is operating as an FTP proxy supports passive and active modes for fetching files and directories. In native FTP caching mode, if active mode is enabled, then the Content Engine uses the same mode with the FTP server for the data connection as the client used to access the Content Engine, which can be either active or passive.

If active mode is not enabled, the Content Engine uses passive mode with the origin FTP server for the data connection.

If the Content Engine adheres to the client's mode (active or passive) for native FTP, the following occurs:

•The Content Engine (the native FTP proxy server) performs an active-mode data transfer to or from the origin FTP server if the FTP client issues an active-mode data transfer request.

•The Content Engine performs a passive-mode data transfer to or from the FTP server if the FTP client issues a passive-mode data transfer request.

Note that the format of the URL that the Content Engine (a nontransparent proxy server that is functioning as a native FTP proxy server) creates for a native FTP request depends on the FTP login name and the transfer mode (binary or ACSII file transfer mode).

•If the FTP login name is an actual username instead of "anonymous," then the string "*user*:*password*@" is included in the URL before the host.

•If the mode used to transfer the file is binary mode, then the string ";type=i" is included at the end of the URL. The following is an example of the URL format that the Content Engine creates for a specific user when binary mode is being used.
ftp://*user*:*password*@10.100.200.5/home/myhome/mybinfile.obj;type=i
The URL for an "anonymous" user login and an ACSII file transfer mode will not have any fields embedded in the URL, as shown in the following example:
ftp://10.100.200.5/home/myhome/mytextfile.txt
Note Passive mode transfer between the FTP client and the native FTP proxy cannot be performed if the Content Engine is behind a NAT because the NAT firewall blocks the Content Engine from discovering its conduit IP address.

Configuring the Client Side of Nontransparent Native FTP Caching

Content Engines that are acting as nontransparent FTP proxy servers can accept native FTP requests from such FTP clients as Reflection X clients, WS-FTP clients, and Unix or DOS command line FTP programs. This section provides some examples of how to configure these different types of FTP clients to send native FTP requests directly to the Content Engine (that is acting as a nontransparent FTP proxy server for these FTP clients). Refer to the Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.4 for information on how to configure the client side proxy FTP request to the Content Engine.

The following example shows how to use a UNIX command line FTP program to configure the client side proxy FTP request to the Content Engine that is acting as the nontransparent FTP proxy server. In this example, 10.9.192.10 is the IP address of the FTP client, and 10.9.192.11 is the IP address of the Content Engine. The IP address of the server, abchost.company.com, does not get displayed at the FTP client.

In this example, the FTP client is opening a local port (on the FTP client machine) to which the Content Engine connects for the data transfer. When the client opens a local port, the data transfer is said to be an "active-mode" transfer. (Not shown in this example is "passive-mode" data transfer, where the Content Engine opens a port on the Content Engine and requests the client to connect to that port.)
shell# ftp -d 10.9.192.11 8501 
Connected to 10.9.192.11. 
220-Welcome to FTP-proxy. 
220-Login to origin server using the 'USER username@server-hostname' command,  
or 220 Login to origin server using the 'SITE server-hostname' and  
'USER username' commands. 
Name (10.9.192.11:admin): smartuser@abchost.company.com 
331 Password required for smartuser. 
Password: 
230 User smartuser logged in. 
Remote system type is UNIX. 
Using binary mode to transfer files. 
ftp> dir 
---> PORT 2,9,192,10,81,212 
200 PORT command successful. 
---> LIST 
150 Opening ASCII mode data connection for /bin/ls. 
total 8 
-rw-r--r-- 1 nobody abc 5496 Jan 31 2002 boot 
-rw-r--r-- 1 nobody abc 143 Oct 24 2001 cop 
226 Transfer complete. 
ftp> quit 
---> QUIT 
shell# 
Configuring Native FTP Cache Freshness

To configure native FTP cache freshness settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices (or Devices > Device Groups).

Step 2 Click the Edit icon next to the name of the Content Engine or device group that you want to configure.

Step 3 In the Contents pane, choose Applications > Web > FTP > Native FTP Cache Freshness. The Native FTP Cache Freshness Settings window appears.

Step 4 Specify a value in the Max Object Size field.

This value represents the maximum object size (in kilobytes) that can be stored. The range of values is 1 to 204800 kilobytes. The default value is set to 4 kilobytes.

Step 5 To save the settings, click Submit.

To configure native FTP cache freshness settings from the CLI, use the ftp-native object max-size command.

Enabling Inetd FTP Service

Inetd (an Internet daemon pronounced eye net dee) is a program that listens for connection requests or messages for certain ports and starts server programs to perform the services associated with those ports.

To enable Inetd FTP service, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears. (Alternatively, choose Devices > Devices.)

Step 2 Click the Edit icon next to the name of the device group (or Content Engine) that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > FTP > Inetd FTP. The Inetd FTP Settings window appears.

Step 4 To enable Inetd FTP service on the Content Engine, check the Inetd Enable FTP Service check box.

Step 5 To save this setting, click Submit.

To enable Inetd FTP service from the CLI, use the inetd enable ftp global configuration command.

Configuring Native FTP Custom Messages

ACNS 5.4 software supports custom welcome messages and ACL-denied messages for FTP proxy. You can download a custom message file to the Content Engine and upload the message to a remote host server. The welcome message is the FTP response to the client when the client connects to the Content Engine in proxy mode. The ACL-denied message is the FTP response to the client when the client is denied access through a configured access control list. (For more information about configuring access control lists, see Chapter 17, "Creating and Managing IP Access Control Lists.")

About Writing FTP Custom Welcome Messages

If you intend to enable proxy authentication, then the welcome message should inform the user to authenticate with the proxy before logging in to the origin server, as shown in the following example:
Welcome to ce-Boxman.  BigCorp's Content Engine for Native FTP Proxy. Please login to the 
proxy with your username and password.
Alternatively, if you do not intend to enable proxy authentication, then the welcome message should inform the user to log in to the origin server using either the USER or SITE method, as shown in the following examples:
Welcome to ce-Boxman. BigCorp's Content Engine for Native FTP Proxy. Please login to the 
origin server using the 'username@server-hostname' format.
Welcome to ce-Boxman. BigCorp's Content Engine for Native FTP Proxy. Please login to the 
origin server using the 'SITE server-hostname' command followed by the 'USER username' 
command.
Configuring FTP Message Download Settings

You can configure welcome messages and ACL-denied messages to an entire device group, or you can configure messages for an individual Content Engine. Only one of each message type can be configured for a Content Engine; therefore, if messages are configured for your Content Engines through the device group, you cannot configure a new FTP message for an individual Content Engine in the group. The Content Distribution Manager GUI issues a warning message when you attempt to create an FTP message where one already exists for the Content Engine.

To download a message to the Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups.

Step 2 Click the Edit icon next to the device group that you want to configure.

Step 3 In the Contents pane, choose Applications > Web > FTP > FTP Messages > Download. The FTP Message Download for Device Group window appears.

Step 4 From the FTP Message drop-down list, choose the message type: welcome or acl-denied.

Step 5 In the Download URL field, enter a URL for the message file that you want the Content Engine to fetch. Only HTTP, HTTPS, and FTP protocols are supported.

Step 6 To save the settings, click Submit. A message appears stating that the size of the file should not be greater than 16 kilobytes. To continue, click OK. The Content Engine retrieves the message file from the URL.

To download native FTP custom messages from the CLI, use the ftp-native custom-message download EXEC command.

Viewing the Content Engine FTP Message Configurations

To view the FTP message configurations for an individual Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon for the Content Engine that you want to view.

Step 3 In the Contents pane, choose Applications > Web > FTP > FTP Messages > Download. The FTP Message Download for Content Engine window appears.

Step 4 To view all of the FTP message configurations, including any that are configured through the Content Engine's device group and any configured on the Content Engine only, click the Aggregate Settings: Yes radio button.

•Messages configured on the Content Engine only are identified with an Edit icon next to the listing.

•Messages configured through the Content Engine's device group are identified with a View only icon next to the listing.

Step 5 To view only FTP messages configured on the individual Content Engine, click the Aggregate Settings: No radio button.

Resetting a Native FTP Custom Message

Use the reset (or delete) option when you want to change a native FTP custom welcome message or an ACL-denied message. To reset a message, follow these steps:

Step 1 To reset a message configuration from an individual device, choose Devices > Devices, and click the Edit icon for the Content Engine.

Step 2 In the Contents pane, choose Applications > Web > FTP > FTP Messages > Download. The FTP Message Download for Content Engine window appears.

Step 3 To reset all messages configured for the individual Content Engine, click the Trash icon in the taskbar. To confirm your action, click OK.

Step 4 To reset a welcome message only, click the Edit icon for the welcome message. In the Modifying FTP Message for Content Engine window, click the Trash icon in the taskbar. To confirm your action, click OK.

Step 5 To reset an ACL-denied message only, click the Edit icon for the ACL-denied message. In the Modifying FTP Message for Content Engine window, click the Trash icon in the taskbar. To confirm your action, click OK.

Step 6 To reset message configuration for a device group, choose Devices > Device Groups.

Step 7 Click the Edit icon next to the device group that you want to configure.

Step 8 In the Contents pane, choose Applications > Web > FTP > FTP Messages > Download. The FTP Message Download for Device Group window appears.

Step 9 To reset all messages configured for the device group, click the Trash icon in the taskbar. To confirm your action, click OK.

Step 10 To reset a welcome message only, click the Edit icon for the welcome message. In the Modifying FTP Message for Device Group window, click the Trash icon in the taskbar. To confirm your action, click OK.

Step 11 To reset a ACL-denied message only, click the Edit icon for the ACL-denied message. In the Modifying FTP Message for Device Group window, click the Trash icon in the taskbar. To confirm your action, click OK.

To reset a native FTP custom message from the CLI, use the ftp-native custom-message reset {acl-denied | all | welcome} EXEC command.

Configuring Native FTP Custom Message Upload Settings

Note Upload settings can only be configured after you have configured the download settings for the message file. Upload settings can only be configured for individual devices; the upload functionality is not supported for device groups.

To upload a custom message file from the Content Engine to a remote host server, configure the native FTP custom message upload settings by following these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the Content Engine that you want to configure.

Step 3 In the Contents pane, choose Applications > Web > FTP > FTP Messages > Upload. The FTP Message Upload Settings for Content Engine window appears.

Step 4 From the FTP Message drop-down list, choose a message type: welcome or acl-denied.

Step 5 To upload the custom message file to the specified host, directory, and filename using the FTP protocol, complete the following settings:

•In the FTP Server Address field, enter the hostname or IP address of the remote host to which you want the message file uploaded.

•In the FTP Server Directory field, enter the name of the directory on the host server.

•In the FTP Server Filename field, enter the filename.

Step 6 In the FTP Server Username field, enter the username for accessing the remote FTP server.

Step 7 In the FTP Server Password field, enter the password for accessing the remote FTP server.

Step 8 To confirm the password, re-enter the password in the Confirm Password field.

Step 9 To save the settings, click Submit.

To upload native FTP custom messages from the CLI, use the ftp-native custom-message upload EXEC command.

Configuring TFTP Settings

The Trivial File Transfer Protocol (TFTP) gateway feature provides a way for Content Engines to serve content files requested by networking devices that use the native TFTP protocol. Content Engines that use ACNS software perform TFTP to HTTP or FTP translation and eliminate the need for the system administrator to configure and manage a dedicated TFTP server to serve TFTP requests. This feature is called TFTP gateway because it 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.

Content files include router software images, router configurations, set top box images, IP phone configuration files, and so forth. If the requested file is not available on the Content Engine, the Content Engine, acting on behalf of the requesting device, retrieves the file from the origin server and caches it. The Content Engine then forwards the file to the device that originated the request. Future requests by any devices for the same file are satisfied by forwarding the file from the Content Engine cache.

You can configure, modify, and view TFTP settings for Content Engines and device groups by completing the following tasks:

•Configuring TFTP General Settings

•Configuring TFTP Proxy Server Settings

•Configuring TFTP Directory Settings

Configuring TFTP General Settings

Content Engines serve TFTP requests from clients by accepting native TFTP requests and retrieving content using FTP or HTTP from locally configured directories or origin servers. Content devices such as set top boxes and routers make TFTP requests for downloading router software images, set top box images, and router configurations. Content Engines allow TFTP-to-HTTP or TFTP-to-FTP translation without the need for configuring and managing a dedicated TFTP server to serve TFTP requests.

To enable the TFTP service on the Content Engine to serve TFTP requests from networking devices, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the desired Content Engine. The Modifying Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > TFTP > TFTP General Settings. The TFTP Settings for Content Engine window appears. Table 8-22 describes the fields in this window and provides the corresponding CLI global configuration commands.

Step 4 To enable the TFTP service application to run on the specified Content Engine, check the Inetd Enable TFTP Service check box.

Checking this check box enables the Content Engine to serve TFTP requests by retrieving the requested content. If you uncheck this check box, TFTP service is disabled on the Content Engine.

Step 5 To configure the maximum number of TFTP requests that the Content Engine will service simultaneously, enter a value in the Maximum Number of TFTP Connections field. The default is 200 requests. The range is 0-300.

Step 6 To save the settings, click Submit.

A "Click to Submit" message appears in red next to the current settings when there are pending changes to be saved. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings, but the settings have not yet been submitted.

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

Table 8-22 TFTP General Settings

GUI Parameter

Function

CLI Command

Inetd Enable TFTP Service

Enables TFTP service on the Content Engine.

inetd enable tftp

Maximum Number of TFTP Connections

Maximum number of TFTP requests that the Content Engine will service simultaneously.

tftp max-connections number

Configuring TFTP Proxy Server Settings

When a requested file does not exist on the Content Engine, the Content Engine makes an HTTP or FTP request to the origin server to retrieve the content. The requested content is cached and sent to the TFTP client. Future requests for the same content from TFTP clients are served by forwarding the file from the cfs or cdnfs directory on the Content Engine.

You can configure a maximum of two origin servers: a primary and a secondary backup server. The TFTP server application running on the Content Engine attempts to retrieve content from the secondary backup server, if configured, when the primary server fails. You can associate priorities with the two origin servers to categorize them as primary or secondary servers.

To configure the TFTP proxy server settings, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the desired Content Engine. The Modifying Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > TFTP > TFTP Proxy. The TFTP Proxy for Content Engine window appears.

Step 4 Click the Create New TFTP Proxy icon in the taskbar. The Creating New TFTP Proxy for Content Engine window appears. (See Figure 8-14.) Table 8-23 describes the fields in this window and provides the corresponding CLI global configuration commands.

Figure 8-14 Creating New TFTP Proxy for Content Engine Window

Note Only two TFTP proxy servers can be defined. When you attempt to create a third TFTP proxy server, the system displays a popup window stating that only two TFTP proxy servers can be defined because each server needs to be configured with a unique priority value.

Step 5 From the Protocol drop-down list, choose the protocol (HTTP or FTP) that the proxy server will use to serve TFTP requests.

Step 6 In the TFTP Gateway Server field, enter the host name or IP address of the TFTP proxy server.

Step 7 To change the default port setting for the HTTP protocol, enter a port number in the Port field.

Step 8 From the Priority drop-down list, choose the priority (LOW or HIGH) with which the origin servers are queried for content.

Priority values categorize a server as a primary or a secondary backup server. The proxy server with the higher priority is the primary origin server and is queried first for content. You cannot configure two origin servers with the same priority, whether they are of the same or different protocols.

Step 9 In the Directory Path field, enter the path to the content that exists on the proxy server. You can enter the complete path or a relative path that specifies the directory in which the requested content resides.

Step 10 To specify user authentication details for logging in to the proxy server, check the Configure User check box. The user details cannot be entered if this check box is not checked.

Step 11 In the User Name field, enter the login ID of the user to be used on the remote server.

Note Authenticated objects are never cached by the Content Engine for HTTP or FTP. If you want to cache these objects, leave the username and password fields in the tftp-server gw command blank. When used with FTP, this configuration is equivalent to allowing anonymous access.

Step 12 In the Password field, enter the user password to be used to authenticate users who access the proxy server. Reenter the same password in the Confirm Password field. The password details are encrypted in the display.

Step 13 To save the settings, click Submit.

Table 8-23 TFTP Proxy Settings

GUI Parameter

Function

CLI Command

Protocol

Protocol (HTTP or FTP) that the proxy server will use to serve TFTP requests.

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

TFTP Gateway Server

Host name or IP address of the TFTP proxy server.

Port

Port that the proxy server will use for the HTTP protocol. The default port for HTTP is port 80.

tftp-server gw proto http server {hostname | ipaddress} [port port_num]

Priority

priority (LOW [2] or HIGH [1]) with which the origin servers are queried for content.

Directory Path

Path to the content that exists on the proxy server. You can enter the complete path or a relative path that specifies the directory in which the requested content resides.

Configure User

Enables fields to specify user authentication details for logging in to the proxy server.

User Name

Login ID of the user to be used on the remote server.

Password

Password to authenticate users who access the proxy server.

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

Confirm Password

—

Configuring TFTP Directory Settings

When a TFTP client makes a request for content, the TFTP server application running on the Content Engine searches the specified directory to serve the content. If the request does not contain any directory path, the default directory is used. You can configure a maximum of eight TFTP directory configurations that TFTP clients can access.

To configure the directories to be used by TFTP, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the desired Content Engine. The Modifying Content Engine window appears with the Contents pane on the left.

Step 3 In the Contents pane, choose Applications > Web > TFTP > TFTP Directory. The TFTP Directory Settings for Content Engine window appears. (See Figure 8-15.)

Figure 8-15 TFTP Directory Settings Window

Step 4 In the TFTP Directory Settings section, check the Configure TFTP Directories check box to enable configuration of TFTP directories.

If this check box is unchecked, the remaining fields in the window are disabled. By default, this check box is unchecked. When the Configure TFTP Directories check box is unchecked, all configured TFTP directories are removed.

Step 5 To configure the default directory, enter the complete absolute path to the directory to be used by the TFTP server application in the Directory 1 field. The first directory configured in the list of TFTP directories becomes the default directory.

You can configure seven more TFTP directories. You cannot duplicate directory paths.

Step 6 To save the settings, click Submit.

A "Click to Submit" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings, but the settings have not yet been submitted.

Note For other operations that you can perform using the icons in the taskbar, see Table 3-3, "Content Distribution Manager GUI Icons."

To configure TFTP directories from the CLI, use the tftp-server dir directory global configuration command.

Configuring DNS Caching Name Service for WCCP Transparent Caching

For transparent interception of DNS requests using WCCP, administrators must configure the DNS caching name service (WCCP service group number 53) on the Content Engine and on a router that supports WCCP Version 2.

The DNS process interacts with the WCCP process in these ways:

•Maintaining the bypass lists.

•Monitoring the active state of the DNS process to make sure that the DNS can accept requests. If the DNS cache has no servers that are responsive, the cache will deregister the service until it has acceptable servers.

•Configuring and managing the WCCP service (the DNS caching name service).

In a centrally managed ACNS network that employs one or more Content Routers, configuring the DNS caching name service with WCCP interception on registered Content Engine causes a conflict with the Content Router because the Content Router and the Content Engine will be listening for DNS requests on the same port (port 53). Consequently, you should not configure DNS cache support with WCCP interception in centrally managed environments that employ Content Routers. You can, however, enable the standard DNS caching name service (without WCCP interception support) in such environments.

The advantages of having the Content Engines intercept DNS requests include the following:

•You can control the servers used through WCCP redirect lists, through bypass entries, or by simply having the Content Engine intercept requests to servers not in use and then reissuing them to others.

•DNS servers can be easily updated and changed as needed.

•Performance is improved (faster response time and lower bandwidth consumption) because of the DNS cache hits.

You can partition your network with a series of forwarders, each with its own DNS cache, which results in the following:

•You can effectively control the DNS traffic across a WAN.

•You can be better equipped to compensate for the loss of one or more servers because the Content Engine can issue the request to a different upstream server.

Typically, this partitioning also results in a performance improvement if a cluster of requests occurs, especially on high-latency interconnections.

Configuring DNS Caching Server Settings for the Content Engine

To configure the DNS caching server settings for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the devices registered in the ACNS network.

Step 2 Click the Edit icon of the Content Engine for which you want to configure DNS caching server settings. The Device Home for Content Engine window appears.

In the Contents pane, choose Applications > DNS > DNS Caching Server. The DNS Caching Server Settings for Content Engine window appears. Table 8-25 describes the fields in this window and provides the corresponding CLI global configuration commands.

Step 3 Check the Enable DNS Caching check box to start the DNS server for resolution of domain names to IP addresses after the listener port is configured. (See the "Configuring DNS Server Bindings for the Content Engine" section.) Enabling the DNS server creates an entry of 127.0.0.1 as the name server for the system and starts the memory-based DNS cache on port 53.

Note To enable transparent interception of DNS requests using WCCP, you must configure the WCCP DNS caching name service (the WCCP service with service ID 53) on the Content Engine and the WCCP Version 2 router.

Step 4 Check the Lookup Name Servers Recursively check box to allow each configured name server to be queried in turn if the request to the primary name server fails. This option is relevant only if you have configured the DNS cache to use the DNS servers configured on the Content Engine as the original request contains only a single DNS server. (See Step 6 for more details.)

Step 5 Check the Use Expired Cache Entries check box to use a resource record in the DNS cache, even if it has expired.

When checked, the DNS cache uses an expired resource record, if the record resides in its cache, to serve the user request. At the same time, the DNS cache initiates a new lookup to revalidate the cached object. This serving of expired resource records is particularly useful when the upstream DNS is slow or unresponsive. The expired record will continue to be used until the entry is updated by a new record, or is purged from the cache using the Least Recently Used (LRU) algorithm.

Step 6 Choose the method that the Content Engine (DNS caching name server) uses to handle transparent DNS requests from the Use Origin Server drop-down list. Table 8-24 describes the options in this list.

You can configure the method that the DNS caching name server uses to handle transparent DNS requests redirected from a WCCP-enabled router. These transparent DNS requests contain the original destination server in the packet headers. However, because the Content Engine can have more than one DNS name server configured, the DNS caching name server can be configured to use either the original DNS server specified in the original request packet headers or the DNS name servers configured on the Content Engine, or a combination of both.

Table 8-24 Use Origin Server Options

Option

Description

Do Not Set

Uses only the DNS servers configured on the Content Engine. This option is selected by default.

Only

Uses only the DNS server identified in the original request.

After-configured

Uses the DNS name servers configured on the Content Engine. If these fail, uses the DNS server specified in the original request packet.

Before-configured

Uses the DNS server specified in the original request. If this fails, uses the DNS name servers configured on the Content Engine.

Step 7 In the Maximum Size of Cache field, specify the maximum size of the DNS cache memory in megabytes. The default value for the allocated memory used by the cache is 5 MB. It is important that you impose a strict maximum memory limit within which the DNS server operates so as not to unduly tax the overall system resources.

Step 8 In the Minimum TTL field, specify the minimum time to store a resource record in the cache. The default is 1 second. After the time-to-live elapses, the cached response must be revalidated. If a response is served from the cache, for that response to be valid, all appropriate resource records must be valid in the cache. Minimum time-to-live must be lower than maximum time-to-live. Otherwise, an error message is displayed on submit.

Step 9 In the Maximum TTL field, specify the maximum time to store a resource record in the cache. The default is 86400 seconds. The cached resource record expires after this period. Maximum time-to-live must be greater than minimum time-to-live. Otherwise, an error message is displayed on submit.

Because the DNS protocol is using UDP, packets can be lost or dropped. The burden of retransmitting DNS requests is on the requester. Typically, a retransmit is initiated every 3 seconds until a response is received, or if a response is not received, the request times out after 90 seconds. If a DNS server times out, then a new upstream server is selected to query. If there are no more servers to query upstream, then the server returns a DNS failed response to the requesting client.

Step 10 In the Retry Period field, specify the time period before an unanswered request is discarded. The default is 90 seconds.

Step 11 In the Retry Timeout field, specify the time between retransmission of UDP DNS requests sent to an upstream DNS server. The default is 3 seconds.

Step 12 To save the settings, click Submit. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.

Table 8-25 DNS Caching Server Settings

GUI Parameter

Function

CLI Command

Enable DNS Caching

Enables the DNS server for resolution of domain names to IP addresses after the listener port is configured.

dns enable

Lookup Name Servers Recursively

Allows each configured name server to be queried in turn if the request to the primary name server fails.

dns serial-lookup

http dns-cache serial-lookup

Use Expired Cache Entries

DNS uses a resource record in the DNS cache, even if it has expired.

dns user-expired enable

Use Origin Server

Configures the method that the DNS caching name server uses to handle transparent DNS requests redirected from a WCCP-enabled router.

dns use-original-server {only | after-configured | before-configured}

Maximum Size of Cache

Maximum size (in megabytes) of the DNS cache memory.

dns max-cache-memory mbytes

Minimum TTL

Minimum time to store a resource record in the cache.

dns min-ttl seconds

Maximum TTL

Maximum time to store a resource record in the cache.

dns max-ttl seconds

Retry Period

Time period before an unanswered request is discarded.

dns retry-period seconds

Retry Timeout

Time between retransmission of UDP DNS requests sent to an upstream DNS server.

dns retry-timeout seconds

Cacheable Resource Records in the Content Engine DNS Cache

Content Engines with ACNS software can intercept DNS requests that have been issued to DNS servers (forwarders or recursive) that traverse the interception device. Upon receiving a request, the Content Engine transmits that response to the client if it has a current cached response. For a cached response to be valid, it must have all the appropriate resource records for the required sections (Answer, Authority, Additional). If any of these resource records have been purged or have expired the request is queued for transmission.

Table 8-26 describes the resource records that can be cached in the Content Engine DNS cache.

Table 8-26 Cacheable Resource Records

Record

Description

A

Address record

HINFO

Host information

NULL

Null record

TXT

Text string

WKS

Well known service description

NS

Name server record

CNAME

Canonical name

MB

Mail box domain name

MD

Mail destination

MF

Mail forwarder

MG

Mail group member

MR

Mail rename domain

PTR

Pointer record

MX

Mail exchange

SOA

Source of authority

Although other resource records are not cached, they are passed through to the client requesting them. The DNS caching name service does support compression of the DNS response as defined by RFC 1035, including those responses generated by the cache. If the cache does not understand the server response to the query, it does not cache that response but passes it through to the client. This action reduces the chance of a nonstandard client or server being disrupted.

Configuring DNS Server Bindings for the Content Engine

To configure DNS server bindings for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the devices registered in the ACNS network.

Step 2 Click the Edit icon of the Content Engine for which you want to configure IP addresses and port numbers that the DNS cache uses to listen for requests. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Applications > DNS > DNS Server Binding. The DNS Server Bindings for Content Engine window appears.

Step 4 Click the Create New Server Binding icon in the taskbar to configure IP address and port number pair for the DNS server to listen for client requests. The Creating New DNS Server Binding for Content Engine window appears.

Note You can create a new DNS server binding only if the DNS server is not listening on configured interface IP addresses for client requests and if the DNS server binding entries have not reached the maximum limit of 16 entries.

If the DNS server is already listening on all the interface IP addresses, then the following warning message appears: "DNS Service is already listening on all IP Addresses."

If the DNS server binding entries have already reached their maximum limit of 16, then the following warning message appears: "DNS Server Binding Entries have reached their maximum limit of 16."

Step 5 Configure the DNS caching name server to listen either on a specific interface IP address or to listen on all the IP addresses configured on the Content Engine.

•To configure the DNS caching name server to listen on a specific interface IP address, click the Listen on IP Address radio button and choose an IP address from the drop-down list. All IP addresses associated with the primary interface or other interfaces configured on the Content Engine are listed here. You can choose an IP address of the interface from the drop-down only after you click the radio button.

•To configure the DNS caching name server to listen on all the IP addresses configured on the Content Engine, click the Listen on all IP Addresses radio button. Once the host name has been resolved to an IP address, it is stored in the memory-based DNS cache.

Step 6 In the Port field, specify the port on which the DNS caching server listens for client requests. The range is 1-65535. Ensure that the configured port number is not already used by any other application running on the Content Engine.

Note If Listen on IP Address is configured, then the DNS caching server listens on the specific IP address and on this port. If Listen on All IP Addresses is configured, then the DNS caching server listens on all IP addresses configured on the Content Engine and on this port.

Step 7 In the Hostname field, specify the host name of the listener to be mapped to an IP address.

Step 8 To save the settings, click Submit. A dialog box alerts you that if the configured port number is being used by any other application running on the Content Engine, the DNS cache listener will fail.

If you have configured Listen on All IP Addresses, a dialog box alerts you that configuring the DNS cache server to listen on all IP addresses for client requests will remove all other DNS server binding settings. Click OK to confirm.

The DNS Server Bindings for Content Engine window appears with the configured DNS cache listener settings.

To configure the DNS caching name server to listen either on a specific interface IP address or to listen on all the IP addresses configured on the Content Engine from the CLI, use the following global configuration command:

dns listen {all | ipaddress} port port_num hostname hostname

Configuring DNS Address Record Mappings for the Content Engine

The DNS server must know the DNS name of the host on which it is being enabled and map the name to an IP address within its own cache. If the DNS cache listener does not match a DNS name, use the mapping type to pin an IP address to name mapping.

To configure the DNS host name to IP address mapping for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon of the Content Engine for which you want to statistically map the IP addresses and host names. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Request Routing > DNS > A-Record Mapping. The DNS A-Record Mappings for Content Engine window appears.

Step 4 Click the Create New DNS A-Record Mappings icon in the taskbar. The Creating New DNS A-Record Mapping for Content Engine window appears.

When you try to configure either a host name or a canonical name (canonical names are configured from the DNS CNAME Record Mappings window) and the total number of pinning configurations has reached its maximum limit of 256, an error message is displayed.

Step 5 Choose the method to allow you to look up an IP address against a name within the cache from the Mapping Type drop-down list. Table 8-27 describes the options in the drop-down list.

Table 8-27 Mapping Type Options

Option

Description

Forward

Maps the host name to the IP address

Reverse

Maps the IP address to the host name

Both

Maps in both forward and reverse directions

Step 6 In the Hostname field, specify the host name to be mapped to an IP address. Host names cannot be duplicated, must begin with an alphabet character, and cannot exceed 256 characters.

Exceptions to host name duplication are as follows:

•If a host name has been configured with forward mapping type, you can configure the same host name with reverse mapping type.

•Conversely, if a host name has been configured with reverse mapping type, you can configure the same host name with forward mapping type.

Step 7 In the IP Address fields, specify the IP address of bidirectional, forward, or reverse mapping. When a client query arrives, the configured host name will be resolved to any one of the IP addresses specified here. The first IP address is a required entry.

Note You must specify IP addresses in sequence. Otherwise, an error message is displayed on submit.

Step 8 To save the settings, click Submit.

If you click the Delete DNS A-Record Mapping icon to delete an address record mapped to a canonical name, an error message appears. You need to remove the mapping before you attempt to delete the address record.

To configure the DNS host name to IP address mappings from the CLI, use the following global configuration command:

dns pin {forward hostname ipaddress | reverse hostname ipaddress | both hostname ipaddress}

Configuring DNS Canonical Name Record Mappings for the Content Engine

The DNS server must know the DNS name of the host on which it is being enabled and map the name to an IP address within its own cache. If the DNS cache listener does not match a DNS name, map the canonical name resource record to the address record after pinning an IP address to name mapping.

To configure the mapping of DNS canonical name to address records for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the devices registered in the ACNS network.

Step 2 Click the Edit icon of the Content Engine for which you want to insert canonical name (CNAME) mapping. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Request Routing > DNS > CNAME Record Mapping. The DNS CNAME Record Mappings for Content Engine window appears.

Step 4 Click the Create New DNS CNAME Record Mappings icon in the taskbar. The Creating New DNS CNAME Record Mapping for Content Engine window appears.

Note When you try to configure a canonical name and the total number of pinning configurations has reached its maximum limit of 256, an error message is displayed.

Step 5 In the Canonical Name field, specify the canonical name to be mapped to the address resource record. You can map a canonical name with a maximum of eight address records. Canonical names cannot be duplicated, must begin with an alphabet character, and cannot exceed 256 characters.

Step 6 Choose the address record to be looked up against the canonical name within the cache from the A-Record drop-down list. The first A-record is a required option.

The A-record drop-down list contains all configured forward and bidirectional mapping type address records. You can associate one or more unique A-records with the CNAME record.

Note You must specify A-records in sequence. Otherwise, an error message is displayed on submit.

Step 7 To save the settings, click Submit.

To configure the mapping of DNS canonical name to address records from the CLI, use the dns pin cname records global configuration command.

Configuring the DNS Server for HTTP Proxy Caching

DNS allows the network to translate domain names entered in requests into their associated IP addresses. To configure DNS caching on a Content Engine, you must complete the following tasks:

•Specify the list of DNS servers, which are used by the network to translate requested domain names into IP addresses that the Content Engine should use for domain name resolution.

•Specify the name of the local domain.

•Specify the maximum number of records that the DNS cache on the Content Engine should store. This setting defines the size of the DNS cache on the Content Engine.

•Enable DNS caching on the Content Engine.

By default, the DNS caching name service on the Content Engine uses a DNS server from its list of configured DNS servers instead of the original DNS server.

•Original DNS server—DNS server from the original request (referred to as the original DNS server).

•List of Configured DNS Servers—DNS servers that are used in the network and have been added to the list of DNS servers that the Content Engine should use for domain name resolution.

To configure DNS server settings for a Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose General Settings > Services > DNS. The HTTP DNS Cache Settings window appears. (See Figure 8-16.) Table 8-28 defines the fields in this window and provides the corresponding CLI global configuration commands.

Figure 8-16 HTTP DNS Cache Settings Window

Step 4 To enable DNS caching, check the Enable DNS Caching of DNS Entries for Http Proxy check box.

Step 5 In the Maximum Cached DNS Entries field, enter a value in megabytes to configure the size of the DNS cache hash table to be temporarily used for storing records. The range is from 5 to 512.

Step 6 To allow each configured name server to be queried in turn if the request to the primary name server fails, check the Enable Serial Lookup check box.

Step 7 In the Local Domain Name field, enter the name of the local domain that is to be DNS cached.

Step 8 In the List of DNS Servers field, enter a list of DNS servers used by the network to resolve host names to IP addresses. You can configure up to eight DNS servers. Separate items in the list with a space.

Step 9 To save the settings, click Submit. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default and device group settings. To revert to the previously configured window settings, click Reset. The Reset button appears only when you have applied default or group settings to change the current device settings but the settings have not yet been submitted.

Table 8-28 HTTP Proxy DNS Cache Settings

GUI Parameter

Function

CLI Command

Enable DNS Caching of DNS Entries for HTTP Proxy

Enables DNS caching in the system.

dns enable

Maximum Cached DNS Entries

Defines the maximum size of the DNS cache hash table used for temporarily saving DNS records.

dns max-cache-memory

Enable Serial Lookup

Allows each configured name server to be queried in turn if the request to the primary name server fails.

dns serial-lookup

Local Domain Name

Name of the local domain to be DNS cached.

ip domain-name name1 name2 name3

List of DNS Servers

DNS servers that are used by the network to translate requested domains into IP addresses.

ip name-server

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 Content Engines 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 Content Engines) and an ICP client (sending requests to neighboring Content Engines) is supported.

ICP Client Settings

You can configure your Content Engine farm to generate ICP queries before retrieving requested objects from the Internet using the ICP client functionality.

With ICP functionality, you can configure parent and sibling Content Engines in a hierarchy. 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, whereas sibling Content Engines cannot retrieve data and instead forward the request to the parent Content Engines.

To configure ICP client functionality, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose Applications > Web > HTTP > ICP > Client. The ICP Client Settings window appears. (See Figure 8-17.) Table 8-29 describes the fields in this window.

Figure 8-17 ICP Client Settings Window

Step 4 To enable ICP client queries, check the Enable check box.

Step 5 In the Maximum Reply Wait Time field, specify the timeout period in seconds for ICP responses.

Step 6 In the Number of Failures field, specify the number of failures that each Content Engine allows an unresponsive ICP server before it removes that ICP server from the list of available servers.

Step 7 Enter a domain to be excluded from ICP queries in the Excluded Domains field.

Step 8 To save the settings, click Submit.

Table 8-29 describes the ICP client settings in the Content Distribution Manager GUI and provides the corresponding global configuration CLI commands.

Table 8-29 ICP Client Parameters

GUI Parameter

Function

CLI Command

Enable

Enables the ICP client.

icp client enable

Maximum Reply Wait Time

Configures how long the Content Engine waits before retrieving the requested data directly from the Internet. The range is from 1 to 30 seconds, and the default value is 2 seconds.

icp client max-wait timeout

Number of Failures

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

icp client max-fail retries

Exclude Domains

Excludes local domains from ICP caching services.

icp client exclude domainnames

ICP Remote Client Settings

To add a remote ICP client to the ICP client list using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > HTTP > ICP > Remote Clients.

Step 4 Click the Create New ICP Remote Client icon. The Creating New ICP Remote Client window appears.

Step 5 Enter the host name or IP address for the ICP remote client in the Client Name field.

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

Step 7 To save the settings, click Submit.

To set the ICP server remote client from the CLI, use the following global configuration command:

icp server remote-client {hostname | ipaddress} {fetch | no-fetch}

ICP Server Settings

You can also configure a 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.

To configure ICP server functionality, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > HTTP > ICP > Server. The ICP Server Settings for Content Engine window appears. (See Figure 8-18.) Table 8-30 describes the fields in this window and provides the corresponding CLI global configuration commands.

Figure 8-18 ICP Server Settings Window

Step 4 To enable ICP server queries. check the Enable check box.

Step 5 In the ICP Port field, designate a port that will listen for ICP requests on the server.

Step 6 In the HTTP Port field, specify the HTTP port that will listen for ICP-generated requests on the server.

Step 7 To save the settings, click Submit.

Table 8-30 ICP Server CLI Command Summary

GUI Parameter

Function

CLI Command

Enable

Enables the ICP sever.

icp server enable

ICP Port

Configures an HTTP proxy port to listen for ICP-generated requests. The range is from 0 to 65535. The default port number is 3128.

icp server http-port port

HTTP Port

Configures an 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.

icp server port icpport

ICP Remote Server Settings

To add a remote ICP server to the ICP server list using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Applications > Web > HTTP > ICP > Remote Servers.

Step 4 Click the Create New ICP Remote Servers icon. The Creating New ICP Remote Server window appears. (See Figure 8-19.) Table 8-31 describes the fields in this window and provides the corresponding CLI global configuration commands.

Figure 8-19 Creating New ICP Remote Server Settings Window

Step 5 In the Server Name field, enter the host name or IP address for the ICP remote server.

Step 6 To enable the configured ICP server to act as a parent server and retrieve cache miss data, check the Parent check box. If this box is not checked, the configured ICP server will not retrieve cache miss data.

Step 7 In the ICP Port field, enter the ICP port to which ICP queries are directed on this ICP server. The range is from 1 to 65535, and the default port is 3130.

Step 8 In the HTTP Port field, enter the HTTP port on the ICP server to which proxy-style requests are forwarded. The range is from 1 to 65535, and the default port is 3128.

Step 9 In the Excluded Domains field, enter a list of excluded domains if you want to limit ICP requests directed to this ICP server to a specific set of domains. Otherwise, all ICP requests (aside from those specified as "local domains") are forwarded to this ICP server.

Step 10 To save the settings, click Submit.

Table 8-31 ICP Remote Server Settings

GUI Parameter

Function

CLI Command

Server Name

Host name or IP address for the ICP remote server.

icp client add-remote-server {hostname | ipaddress} {parent | sibling} icp-port icpport http-port httpport [restrict domainnames]

Parent

Enables the configured ICP server to act as a parent server and retrieve cache miss data.

ICP Port

Port to which ICP queries are directed.

HTTP Port

Port on the ICP server to which proxy-style requests are forwarded.

Excluded Domains

Excludes the domains listed.