-
Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.2
-
Title
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Getting Started
-
Chapter 4: Deployment Scenarios for Standalone Content Engines
-
Chapter 5: Configuring Transparent Redirection for Standalone Content Engines
-
Chapter 6: Configuring Conventional Caching Services for Standalone Content Engines
-
Chapter 7: Configuring WMT Streaming Media Services on Standalone Content Engines
-
Chapter 8: Configuring RTSP Media Services on Standalone Content Engines
-
Chapter 9: Configuring Content Authentication and Authorization on Standalone Content Engines
-
Chapter 10: Configuring URL Filtering on Standalone Content Engines
-
Chapter 11: Configuring ICAP on Standalone Content Engines
-
Chapter 12: Configuring the Rules Template on Standalone Content Engines
-
Chapter 13: Configuring Primary and Backup Proxy Servers for Standalone Content Engines
-
Chapter 14: Configuring Advanced Transparent Caching Features on Standalone Content Engines
-
Chapter 15: Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines
-
Chapter 16: Configuring Login Authentication and Authorization on Standalone Content Engines
-
Chapter 17: Configuring AAA Accounting on Standalone Content Engines
-
Chapter 18: Creating and Managing IP Access Control Lists for Standalone Content Engines
-
Chapter 19: Viewing and Modifying TCP Stack Parameters on Standalone Content Engines
-
Chapter 20: Monitoring and Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Reference Material for Standalone Content Engine Deployments
-
Table Of Contents
Configuring Conventional Caching Services for Standalone Content Engines
Overview of Configuring Conventional Caching Services
Configuring HTTP Caching for Standalone Content Engines
Configuring Nontransparent HTTP Forward Proxy Caching on Standalone Content Engines
Configuring HTTP Cache Freshness Settings
Configuring Authenticated HTTP Cache Settings
Specifying a Reauthentication Interval
Displaying the Configuration of the HTTP Authentication Cache
Enabling the Caching of Authenticated Content
Displaying HTTP Authentication Cache Statistics
Configuring Transparent HTTP Forward Proxy Caching for Standalone Content Engines
Configuring the Standard Web Cache Service (Service 0) for Standalone Content Engines
Configuring the Custom Web Cache Service (Service 98) for Standalone Content Engines
Configuring HTTP Reverse Proxy Caching for Standalone Content Engines
Configuring HTTPS Caching for Standalone Content Engines
About SSL Termination of HTTPS Client Requests
About Tunneling of HTTPS Client Requests
Configuring HTTPS Proxy Caching for Standalone Content Engines
Configuring HTTPS Transparent Caching for Standalone Content Engines
Configuring HTTPS Server Settings on Standalone Content Engines
Configuring Certificates and Private Keys for HTTPS Caching
Configuring Certificate Groups for HTTPS Caching
Configuring HTTPS Outgoing Proxy Servers for Standalone Content Engines
Preventing Unwanted Access to Any Destination Port
Configuring FTP Caching for Standalone Content Engines
Overview of FTP Caching with Standalone Content Engines
About Native FTP Caching Support
About FTP-Over-HTTP Caching Support
Restrictions Regarding Native FTP Caching in ACNS 5.1 and 5.2 Software
Configuring Native FTP Caching for Standalone Content Engines
Configuring FTP-over-HTTP Caching on Standalone Content Engines
Configuring the TFTP Server and Gateway for Standalone Content Engines
Using the TFTP Service and Gateway on Standalone Content Engines
Enabling the TFTP Server and Gateway
Configuring the TFTP Server and Gateway on Standalone Content Engines
Configuring DNS Caching for Standalone Content Engines
About DNS Caching for Standalone Content Engines
Domain Name Resolution Requirements
DNS WCCP Transparent Interception Overview
Configuring DNS Servers for the DNS Caching Service (Service 53)
Configuring the DNS Caching Service (Service 53) for Standalone Content Engines
Disabling DNS Caching on Standalone Content Engines
Configuring Persistent Connections
Enabling Persistent Connections
Disabling Persistent Connections
Configuring Healing Mode for Content Engine Clusters
Configuring the Internet Cache Protocol for Content Engine Clusters
Configuring Standalone Content Engines as ICP Clients
Configuring Standalone Content Engines as ICP Servers
Configuring Conventional Caching Services for Standalone Content Engines
This chapter describes how to configure conventional caching services (HTTP, FTP, HTTPS, or DNS caching) for standalone Content Engines. It also describes how to configure the TFTP gateway, persistent connections, healing mode, and the Internet Cache Protocol (ICP) for standalone Content Engines. This chapter includes the following sections:
•
Overview of Configuring Conventional Caching Services
•
•
•
•
•
•
•
•
Note
Overview of Configuring Conventional Caching Services
This section provides an overview of how to use the Content Engine CLI to configure conventional caching services (HTTP, HTTPS, FTP, and DNS caching) on standalone Content Engines. For information about how to use the Setup utility to configure the following three commonly used conventional caching services (HTTP reverse proxy caching, HTTP transparent caching using WCCP Version 2, and HTTP forward proxy caching), see the "Configuring a Basic Configuration on Standalone Content Engines with the Setup Utility" section.
Figure 6-1 provides a detailed view on how to configure conventional caching services for standalone Content Engines.
Figure 6-1 Detailed View of Configuring Conventional Caching Services for Standalone Content Engines
Table 6-1 is a checklist of tasks for configuring conventional caching services (HTTP, HTTPS, FTP, and DNS caching) for standalone Content Engines. This checklist also includes the steps involved in configuring these services on a standalone Content Engine.
Table 6-1 Checklist for Configuring Conventional Caching Services for Standalone Content Engines
1.
routing methods to direct client requests
to the standalone Content Engine.–
–
Layer 4 switching)For direct proxy routing, see the "Configuring Client Browsers and Media Players for Direct Proxy Routing" section.
For WCCP routing, see the "Configuring Standalone Content Engines for WCCP Transparent Redirection" section.
For Layer 4 switching, see the "Configuring Layer 4 Switching as a Redirection Method" section.
2.
a *.pac file to be used?•
directly to the standalone Content Engine as a direct proxy
server. See the "Manually Pointing Client Browsers to a Standalone Content Engine" section.•
client browsers to use a proxy autoconfiguration (PAC) file.
See the "Using PAC Files to Point Client Browsers Directly to a Standalone Content Engine" section.3.
conventional caching services on
this standalone Content Engine.–
–
–
See the following sections in this chapter:
•
•
•
4.
caching services for this standalone
Content Engine.–
–
–
–
–
See the following sections in this chapter:
•
•
•
•
5.
–
–
persistent connections.–
cache clusters.–
Content Engine.–
Content Engine.–
Content Engine.–
See tasks 6 through 24 below in this table.
6.
See "Configuring the TFTP Server and Gateway for Standalone Content Engines" section.
7.
8.
See the "Configuring Healing Mode for Content Engine Clusters" section.
9.
cache clusters.See the "Configuring the Internet Cache Protocol for Content Engine Clusters" section.
10.
on the Content Engine."Configuring WMT Streaming Media Services on Standalone Content Engines"
11.
on the Content Engine."Configuring RTSP Media Services on Standalone Content Engines"
After configuring caching and streaming services on the standalone
Content Engine, you can configure such content services as
access control, URL filtering, ICAP, and rules.12.
to be controlled (access control for HTTP,
HTTPS, and FTP-over-HTTP requests).•
•
as described in "Configuring Content Authentication and Authorization on Standalone Content Engines."13.
•
•
FTP requests, as described in "Configuring URL Filtering on Standalone Content Engines."14.
Internet Content Adaptation Protocol
(ICAP) server.•
•
requests, as described in "Configuring ICAP on Standalone Content Engines."15.
for processing content requests.•
•
WMT, and RTSP requests, as described in "Configuring the Rules Template on Standalone Content Engines."16.
(for example, traffic bypass, overload bypass,
flow protection, and IP spoofing)."Configuring Advanced Transparent Caching Features on Standalone Content Engines"
17.
standalone Content Engine."Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines"
18.
services on this standalone Content Engine."Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines"
19.
administrative users who will be accessing the
Content Engine for configuration, monitoring,
or troubleshooting purposes."Configuring Administrative Login Authentication and Authorization on Standalone Content Engines."
20.
for system accounting with TACACS+.21.
on this standalone Content Engine."Creating and Managing IP Access Control Lists for Standalone Content Engines"
22.
for this standalone Content Engine."Viewing and Modifying TCP Stack Parameters on Standalone Content Engines"
23.
for this standalone Content Engine.24.
with SNMP or ACNS software alarms.25.
such as traceroute or ping.
Configuring HTTP Caching for Standalone Content Engines
HTTP is the main protocol used on the web for communication between web browsers and web servers. There are two commonly implemented HTTP versions today: HTTP 1.0 and HTTP 1.1. ACNS 5.x software supports both HTTP 1.0 and HTTP 1.1.
HTTP runs over TCP port 80 (which is reserved for HTTP) and is a request-response protocol. The client (web browser) sends a request to a web server, and the web server responds with the content. Each request or response can carry a number of headers with it, specifying various properties of the client, the server, the object or communicating states between the client and the web server.
The HTTP 1.1 specification allows objects to be transmitted using "Chunked Transfer Coding." In ACNS software, Release 5.1 and earlier, the proxying of chunked transfer encoded (CTE) objects was supported; however, the caching of these objects was not supported.
In ACNS software, Release 5.2.1 or later, support for the caching of CTE HTTP objects is supported. A subsequent request for the same CTE object, which meets the standard HTTP caching freshness criteria, results in that object being fetched from the Content Engine's cache and sent to the client that is HTTP 1.1 compliant. Note that HTTP 1.0 clients do not support CTE. Consequently, if an object is stored in a CTE format, then the Content Engine must refetch the object from the source HTTP server if the HTTP client is not HTTP 1.1 compliant.
To enable the caching of CTE HTTP objects on a standalone Content Engine, specify the http cache-chunk-encoded enable global configuration command. After enabling this feature, you can use the show statistics http request EXEC command to verify that this feature is working properly. Check the command output to verify whether the displayed value in the "Chunked HTTP Responses:" field increments after the Content Engine serves cached CTE HTTP objects to HTTP 1.1 compliant clients.
Note
Table 6-2 lists the HTTP caching services that are supported by Content Engines that are running ACNS software (Release 5.2 or later). The type of services supported varies based on the method used to route the HTTP request to the Content Engine.
Table 6-2 Supported HTTP Caching Services with Standalone Content Engines
Nontransparent HTTP
forward proxy cachingConfiguring Nontransparent HTTP Forward Proxy Caching on Standalone Content Engines
Transparent HTTP
forward proxy cachingConfiguring Transparent HTTP Forward Proxy Caching for Standalone Content Engines
Transparent HTTP
reverse proxy cachingConfiguring HTTP Reverse Proxy Caching for Standalone Content Engines
In ACNS software, Releases 5.1 and earlier, a maximum of eight active WCCP services were supported by a WCCP Version 2 router and a Content Engine. ACNS 5.2 software supports up to 25 active WCCP Version 2 services but only 17 services are currently defined. See Table B-3 for a list of WCCP services.
Configuring Nontransparent HTTP Forward Proxy Caching on Standalone Content Engines
You can use the Content Engine GUI or CLI to configure HTTP proxy caching on a standalone Content Engine (nontransparent forward proxy server).
From the Content Engine GUI, choose Caching > HTTP Proxy, and use the displayed HTTP Proxy window to configure the HTTP connection settings. For more information on how to use this window, click the HELP button in the window.
From the Content Engine CLI, follow these steps:
Step 1
Point the client browsers directly to the Content Engine so that HTTP requests from these browsers are sent directly to the Content Engine (direct proxy routing). You can use the proxy autoconfiguration feature (PAC file) or manually configure the client browsers by specifying the IP address and port number of the forward proxy server. For more information on this topic, see the "Configuring Client Browsers and Media Players for Direct Proxy Routing" section.
Step 2
http proxy incoming ports
where ports is the port number used by the standalone Content Engine to receive HTTP requests directly from the client browsers. This number ranges from 1 to 65535. You can specify up to eight ports.
This example configures an incoming HTTP proxy on port 8080. Up to eight incoming proxy ports can be configured on the same command line.
ContentEngine(config)# http proxy incoming 8080Step 3
Step 4
Configuring HTTP Cache Freshness Settings
With HTTP 1.1, you can configure the Content Engine to check the freshness of its cached objects before serving the requested content to a client browser. A "fresh object" is a web object that is not "stale." A cached object is considered fresh under any of the following conditions:
•
•
•
You can use the If-Modified-Since (IMS) feature to configure a standalone Content Engine to revalidate the freshness of the content stored in its local cache before serving the content to a client browser. The Content Engine checks the freshness of its cached content under the following conditions:
•
•
Note
The Content Engine validates the freshness of requested content in its cache by sending an IMS request to the origin web server. The Content Engine also sends an IMS request to the origin web server when the maximum Time To Live (TTL) has expired.
Content freshness is based upon a conditional GET feature of the HTTP protocol. The Content Engine will retrieve the requested information from the origin server again if the content has changed since it was cached on the Content Engine. In the HTTP protocol, the conditional GET request uses the value of the Last-Modified response header that was received with the document when it was retrieved and stored in the Content Engine cache. This value (the last modification date and time of the cached document) is sent in the If-Modified-Since request header. The conditional GET request uses the time stamp from the Last-Modified: header and sends it along with the request in the If-Modified_Since header.
The following example shows an IMS request that a Content Engine would send to an origin web server.
GET /index.html HTTP/1.1Server: www.cisco.comConnection: keep-aliveIf-Modified-Since: Tue 12 Sep 2000 10:07:04 GMT Accept: */*If the content has not changed, the origin web server responds with a 304 Not Modified message, and does not send the content.
If the content has changed, the new version is transferred to the Content Engine again. Typically, the origin web server also sends the Content Engine a 200 OK response along with the new version of the content.
The following examples show these two possible responses from the origin web server to the Content Engine IMS request.
304 Not Modified(end-of-request)or
200 OK(response headers)(data)(end-of-request)The Expires response, which indicates the time that the response expires, also affects caching. This response header indicates the time that the response becomes stale and should not be sent to the client without an up-to-date check (using a conditional GET operation). If the HTTP header of a cached object does not specify an expiration time, the Content Engine can age out cached objects through the http age-multiplier and http max-ttl global configuration commands.
The Content Engine can also calculate an expiration time for each web object before it is written to disk. The Content Engine's algorithm to calculate an object's cache expiration date is as follows:
Expiration date = (Today's date - Object's last modified date) * Freshness factor
The last modified date is provided by the end server's file system. The freshness factor is tunable and derived from the text and binary percentage parameters of the http age-multiplier global configuration command. Valid age-multiplier values are from 0 to 100 percent of the object's age. Default values are 30 percent for text (HTML) and 60 percent for binary objects (for example, gifs). After the expiration date has passed, the object is considered stale and subsequent requests causes a fresh retrieval of the content by the Content Engine.
When configuring the HTTP cache freshness settings on standalone Content Engines, note the following:
•
•
•
•
You can use the Content Engine CLI or GUI to configure the freshness settings for an HTTP cache on a standalone Content Engine.
From the Content Engine GUI, choose Cache > HTTP Freshness, and use the displayed HTTP Freshness window. To obtain more information about how to use the HTTP Freshness window to configure freshness settings, click the HELP button in the window.
From the Content Engine CLI, follow these steps:
Step 1
ContentEngine(config)# http age-multiplier text 50% bin 70%Step 2
ContentEngine(config)# http min-ttl 10Step 3
ContentEngine(config)# http max-ttl days text 2 binary 4ContentEngine(config#) http max-ttl hours text 1 hours binary 4The TTL sets a ceiling on estimated expiration dates. An explicit expiration date in the HTTP header takes precedence over the configured TTL. Table 6-3 lists the valid range of values.
Table 6-3 Time To Live Range of Values for HTTP Freshness
Days
1-1825
Hours
1-43800
Minutes
1-2628000
Seconds
1-157680000
Step 4
The following example configures the Content Engine to revalidate all HTTP objects for every HTTP request.
ContentEngine(config)# http reval-each-request allStep 5
ContentEngine(config)# http object max-size 500
Note
Step 6
ContentEngine(config)# http cache-cookiesStep 7
ContentEngine# show http ttlMaximum time to live in days: text 3 binary 7Minimum time to live for all objects in minutes: 5
Configuring Authenticated HTTP Cache Settings
The authenticated HTTP caching feature allows content that was authenticated through basic authentication and NTLM authentication to be cached and served to more than one user, while maintaining security. If an authenticated object is cached, then subsequent requests for that object (from new users) require authentication. The cached object is revalidated with the origin server through the authorization header for the new user. If the user is not authorized, the server sends a 401 (Unauthorized) response. If the user is authorized and the object is not modified, the cached object is served to the client.
Note
You can use the Content Engine GUI or CLI to configure the parameters for the HTTP authentication cache on standalone Content Engines:
•
•
http authentication {cache {max-entries entries | max-group-entries number | timeout minutes | ttl minutes} | header {401 | 407} | realm line}
Table 6-4 Parameters for the http authentication CLI Command
cache
Configures parameters that are related to the authentication cache on the Content Engine.
max-entries
Sets the maximum number of entries retained in the authentication cache.
entries
Maximum number of entries retained in the authentication cache on the Content Engine. Valid values are from 500 to 32000 entries. This is limited by the physical resources available on the Content Engine.
max-group-
entriesSets the maximum number of entries retained in the authentication group cache. This is subject to physical resources on the Content Engine. This option is only available in ACNS software Release 5.2 or later.
Tipnumber
Maximum number of entries retained in the authentication group cache on the Content Engine. Valid values are from 500 to 12000 entries. This is limited by the physical resources available on the Content Engine.
timeout
Sets the timeout value of records in the authentication cache. Specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires a server lookup for reauthentication. This is the least-recently-used (LRU) value. It is also referred to as the "idle time."
minutes
Time in minutes (1-1440) between the user's last Internet access and the removal of that user's entry from the authorization cache, forcing reauthentication. The default is 240 minutes (4 hours); the minimum is 30 minutes; and the maximum is 1440 minutes (24 hours).
ttl
Sets an absolute Time To Live (TTL) for entries in the authentication cache. This option is only available in ACNS software Release 5.2 or later. By default, this option is disabled, 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.
minutes
Time in minutes (1-1440) that specifies the maximum amount of time that an entry is valid in the authentication cache entry after its creation. The minimum is 1 minute; the maximum is 1440 minutes (24 hours). For more information, see the "Specifying a Reauthentication Interval" section.
header
Determines which HTTP header to use for authentication (user ID and password) when the style of the HTTP request indicates that no proxy server is present. Headers can be either HTTP 401 (Unauthorized) or HTTP 407 (Proxy Authentication Required). The default is HTTP 401.
401
Uses HTTP 401 to query users for credentials.
407
Uses HTTP 407 to query users for credentials.
realm
Configures the realm string for basic HTTP request authentication.
line
Name of the realm string to be authenticated. The default is Cisco Content Engine.
The maximum number of entries that is maintained in the authentication cache is 32,000. The minimum number is 500. The default value is 16,000 entries. Use the http authentication max-entries global configuration command to configure the maximum number of entries that is to be maintained in the authentication cache on this Content Engine, if necessary.
If the authentication cache is not large enough to accommodate all authenticated users at the same time, the Content Engine purges older entries that have not yet timed out. The default time interval between the user's last Internet access and the removal of that user's entry from the authorization cache is 240 minutes (4 hours). The minimum time interval is 1 minute, and the maximum is 1440 minutes (24 hours). The Content Engine forces reauthentication with the access control server once this time interval expires.
In this example, the length of time that entries are valid in the authentication cache is set at 1000 minutes:
ContentEngine(config)# http authentication cache timeout 1000When LDAP, RADIUS, and TACACS+ are used in proxy redirection mode, the authentication record kept in the authentication cache is indexed by the username and the password entered. When LDAP, RADIUS, or TACACS+ is used in WCCP-enabled router redirection mode, the authentication record indexed is the IP address of the Content Engine that is sending the request in transparent mode. When an NTLM server is used in either proxy redirection mode or WCCP-enabled router redirection mode, all authentication records are indexed by using the IP address of the requesting client. By default, the Content Engine authenticates cache loads based on the URL syntax of the incoming request.
Use the http authentication header global configuration command to configure the Content Engine to send a message to the client when authorization has failed. You can choose http authentication header 401 (Unauthorized) or http authentication header 407 (Proxy Authorization Required).
The following example specifies that the Content Engine should use the 407 header when asking the end user for authentication credentials (user ID and password).
ContentEngine(config)# http authentication header 407
Note
Specifying a Reauthentication Interval
In 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.
The ability to specify an absolute TTL for HTTP authentication cache entries was added in ACNS 5.2 software 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 scenario, 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.
ContentEngine(config)# http authentication cache ?max-entries Maximum entries in authentication cache; this is subject tophysical resources on the platformmax-group-entries Maximum entries in authentication group cache; this issubject to physical resources on the platformtimeout Amount of time between last access and cache removalttl Maximum amount of time from creation an entry is valid inthe cacheNote that in order to use the absolute TTL effectively in a shared workstation environment that uses the Internet Explorer browser, there are additional considerations, because by default the browser will automatically send the workstation logon credentials when the Content Engine queries the user for credentials. Therefore, for the absolute TTL to provide additional security, either the logon credentials must not be valid request authentication credentials for the Content Engine or the Internet Explorer browser must configure its security settings to not send the logon credentials automatically when the Content Engine queries the user for credentials. To configure this on the Internet Explorer browser, choose Tools > Internet Options > Security > Internet (and/or the other zones) > Custom Level > User Authentication > Logon > Prompt for Username and Password. For this browser configuration to be effective, it must receive a 401 HTTP reply code when it is queried for credentials, which is the default in transparent redirection using WCCP. To have the 401 HTTP reply code used when in proxy redirection mode, use the Content Engine http authentication header 401 global configuration command.
Note
For non-shared workstations that use the Internet Explorer browser, configure the Internet Explorer browsers on these workstations to automatically send their logon credentials by choosing Tools > Internet Options > Security > Internet (and/or the other zones) > Custom Level > User Authentication > Logon > Automatic logon only in Intranet zone (or Automatic logon with current username and password). Note that the workstation logon credentials of the non-shared workstation users must be the same credentials that will successfully authenticate with the Content Engine. This explicit configuration of the browser is only needed if WCCP mode is being used. In proxy mode, the client browsers will always send the credentials.
This absolute TTL timeout (the ttl option) allows you to specify an absolute value for the maximum time that an authentication cache entry is considered valid. The TTL timeout is specified in minutes (1-1440). The minimum is 1 minute; the maximum is 1440 minutes (24 hours). By default, this absolute TTL timeout option is disabled on the Content Engine.
Note that although a short absolute configuration value increases security in a shared workstation environment, it also increases the number of requests that must be made to the authentication server.
Note
Displaying the Configuration of the HTTP Authentication Cache
Use the show http authentication EXEC command to display the current configuration of the HTTP authentication cache on a standalone Content Engine.
ContentEngine# show http authenticationHTTP Authentication:Header: Based on URL syntaxRealm: "Cisco Content Engine"Cache Timeout: 480 (minutes)Cache TTL: 240 (minutes)Cache Maximum entries configured: 8000Cache Maximum entries platform limit: 8000Group Cache Maximum entries configured: 500Group Cache Maximum entries platform limit: 1000Enabling the Caching of Authenticated Content
By default, authenticated content is not cached in HTTP. You can use the http cache-authenticated global configuration command to change this default policy.
http cache-authenticated {all | basic | ntlm}
Table 6-5 describes these command parameters.
This example enables caching of both basic and NTLM authenticated content on the Content Engine:
ContentEngine(config)# http cache-authenticated allThis example shows how to verify which types of object caching are currently enabled on the Content Engine.
ContentEngine(config)# show http cache-authenticated allBasic authenticated objects are cached.NTLM authenticated objects are cached.The following example shows how to enable NTLM object caching on a standalone Content Engine:
ContentEngine(config)# http cache-authenticated ntlmWhen NTLM object caching is enabled on a Content Engine, when the Content Engine receives an NTLM HTTP request from a client, it searches its cache for the requested content. If a cache hit occurs, the Content Engines sends the client the requested content. If a cache miss occurs, the Content Engine retrieves the requested content from the origin server, caches a local copy of the content, and sends the requested content to the client.
The cached objects are tagged as "NTLM protected" so that subsequent requests for these same objects are subjected to authentication before the Content Engine can serve the content to the client. If there is a cache hit and the requested object is an NTLM protected object, the Content Engine checks whether there is a secured connection between this client and the server.
•
•
Displaying HTTP Authentication Cache Statistics
To display authentication cache statistics for a standalone Content Engine, use the show statistics http-authcache EXEC command:
•
•
•
Configuring Transparent HTTP Forward Proxy Caching for Standalone Content Engines
When transparent redirection is being used to direct HTTP requests to a Content Engine, you can configure the following caching services on the Content Engine:
•
•
You can use the Content Engine GUI or CLI to configure these caching services on a standalone Content Engine. If you use the Content Engine GUI to enable and configure the standard web-cache service (service 0) or the custom-web-cache service (service 98) on a standalone Content Engine, then you must specify the designated router list for each of these WCCP services in the following Content Engine GUI windows: the Web Cache window (WCCP > Web Cache), and the Custom Web Cache window (WCCP > Custom Web Cache). For more information on how to use the Custom Web Cache window, click the HELP button in the window.
Configuring the Standard Web Cache Service (Service 0) for Standalone Content Engines
The standard web-cache service (service 0) permits a single WCCP Version 1-enabled router or one or more WCCP Version 2-enabled routers to redirect HTTP traffic to standalone Content Engines on port 80 only. In order for a standalone Content Engine to accept redirected HTTP requests on port 80, you must configure the standard web-cache service on the Content Engine (transparent HTTP forward proxy caching).
To configure a standalone Content Engine to run the web-cache service (service 0) with WCCP Version 2, use the wccp web-cache global configuration command. To disable this service, use the no form of this command.
wccp web-cache {mask {[dst-ip-mask hex_num] [dst-port-mask port_hex_num] [src-ip-mask hex_num] [src-port-mask port_hex_num]} | router-list-num num [assign-method-strict] [l2-redirect] [mask-assign] [password key] [weight percentage]}
Table 6-6 describes the command parameters.
In the following scenario, the web-cache service (service 0) is configured on a standalone Content Engine and a WCCP-enabled router. By configuring this WCCP service on the router, the WCCP router redirects HTTP requests transparently to the Content Engine on port 80. By configuring this service on the Content Engine, the Content Engine listens on port 80 for redirected HTTP requests. If the Content Engine determines that it should accept and process the redirected HTTP request, it retrieves the requested information from the origin server if it is not already stored in its cache, caches a copy of the content in its local storage if the content is cacheable, and then send the requested content to the client browser.
To configure the standard web-cache service (service 0) on a Content Engine and a WCCP router, follow these steps:
Step 1
ContentEngine(config)# wccp version 1or
ContentEngine(config)# wccp version 2Step 2
Tip
Step 3
In this case, there is only one router on router list 1 (the router that you just configured for the standard web-cache service, which has an IP address of 10.0.1.1).
ContentEngine(config)# wccp router-list 1 10.0.1.1If you use the Content Engine GUI to enable and configure WCCP on this Content Engine, then you must specify the designated router list for the web-cache service in the Web Cache window (WCCP > Web Cache) of the Content Engine GUI.
Step 4
ContentEngine(config)# wccp web-cache router-list-num 1Step 5
ContentEngine(config)# exitStep 6
ContentEngine# write memoryStep 7
Router# configure terminalRouter(config)# ip wccp version 2Step 8
Router(config)# ip wccp web-cacheStep 9
Router(config)# interface type numberIn the following example, Ethernet interface 0/1 on the router is configured to run the web-cache service.
Router(config)# interface ethernet 0/1Step 10
Router(config-if)# ip wccp web-cache redirect in
Configuring the Custom Web Cache Service (Service 98) for Standalone Content Engines
To enable a standalone Content Engine to accept redirected HTTP traffic on a port other than 80, configure the Content Engine to support the custom-web-cache service (service 98).
The wccp custom-web-cache global configuration command causes the Content Engine to establish WCCP Version 2 redirection services automatically with a Cisco router on a user-specified port number. The Content Engine then performs transparent web caching for all HTTP requests over that port while port 80 transparent web caching continues without interruption. For custom web caching, the custom-web-cache service (service 98) must be enabled on routers that are running WCCP Version 2. WCCP Version 1 does not support the custom-web-cache service.
To configure the custom-web-cache service on a standalone Content Engine, use the wccp custom-web-cache global configuration command. To disable the custom-web-cache service on the Content Engine, use the no form of this command.
wccp custom-web-cache {mask {[dst-ip-mask hex_num] [dst-port-mask port_hex_num] [src-ip-mask hex_num] [src-port-mask port_hex_num]} | router-list-num num port port [assign-method-strict] [hash-destination-ip] [hash-destination-port] [hash-source-ip] [hash-source-port] [l2-redirect] [mask-assign] [password key] [weight percentage]}
Table 6-7 describes these command parameters.
The l2-redirect option permits the Content Engine to receive transparently redirected traffic from a WCCP Version 2-enabled router or switch if the Content Engine has a Layer 2 connection with the device and the device is configured for Layer 2 redirection.
The weight parameter represents a percentage of load redirected to the Content Engine cluster (for example, a Content Engine with a weight of 30 receives 30 percent of the total load). If the total of all weight parameters in the Content Engine cluster exceeds 100, the percentage load for each Content Engine is recalculated as the percentage that its weight parameter represents of the combined total.
In the following scenario, a standalone Content Engine and a router that are both running WCCP Version 2 are configured to support the custom-web-cache service (service 98). By configuring this WCCP caching service, the WCCP Version 2 routers can redirect HTTP traffic transparently to a Content Engine (transparent forward proxy server) on multiple ports (up to eight ports). This enables you to configure the Content Engine to intercept HTTP requests on multiple ports without having to configure a user-defined WCCP service (services 90 to 97). For more information about configuring user-defined WCCP services on a Content Engine and a router, respectively, see the "Configuring WCCP Services on Standalone Content Engines" section and the "Configuring WCCP Services on a Router" section.
To configure the custom-web-cache service (service 98) on a standalone Content Engine and a router, follow these steps:
Step 1
ContentEngine(config)# wccp version 2The Content Engine must be running WCCP Version 2 to support the custom-web-cache service (service 98). WCCP Version 2 is required for any of the WCCP services listed in Table B-3 other than the standard web-cache service (service 0).
Tip
Step 2
In this case, there is only one router on router list 1 (the router that you just configured for the custom-web-cache service, which has an IP address of 10.0.1.1).
ContentEngine(config)# wccp router-list 1 10.0.1.1If you use the Content Engine GUI to enable and configure WCCP on this Content Engine, then you must specify the designated router list for the custom-web-cache service in the Custom Web Cache window (WCCP > Custom Web Cache) of the Content Engine GUI.
Step 3
ContentEngine(config)# wccp custom-web-cache router-list-num 1 port 31Step 4
ContentEngine(config)# exitStep 5
ContentEngine# write memoryStep 6
Router# configure terminalRouter(config)# ip wccp version 2Step 7
Router(config)# ip wccp 98Step 8
Router(config)# interface type numberIn the following example, the Ethernet 0 interface on the router is configured to run the custom-web-cache service.
Router(config)# interface ethernet 0Step 9
Router(config-if)# ip wccp 98 redirect out
Configuring HTTP Reverse Proxy Caching for Standalone Content Engines
The reverse-proxy service (service 99) is the pre-defined WCCP Version 2 service that permits WCCP Version 2-enabled routers to redirect reverse proxy packets to a standalone Content Engine that is functioning as a transparent reverse proxy server.
This section provides a sample scenario of how to how to configure this WCCP service with a WCCP Version 2-enabled router and a standalone Content Engine. In this scenario, WCCP Version 2 and the reverse-proxy service (service 99) are used to redirect HTTP reverse proxy requests transparently to the Content Engine on port 80. By configuring this service on the Content Engine, the Content Engine processes the redirected HTTP reverse proxy requests. As part of processing the request, the Content Engine retrieves the requested information from the origin server if it is not already stored in its cache, caches a local copy, and sends the requested content to client browser.
To configure the reverse-proxy service (service 99) on a standalone Content Engine and a WCCP router, follow these steps:
Step 1
ContentEngine(config)# wccp version 2The Content Engine must be running WCCP Version 2 to support the reverse-proxy service. WCCP Version 1 only supports the standard web-cache service (service 0); it does not support the reverse-proxy service. See Table B-3 for a list of the WCCP services.
Tip
Step 2
In this case, there is only one router on router list 1 (the router that you just configured for the reverse proxy cache service, which has an IP address of 10.0.1.1).
ContentEngine(config)# wccp router-list 1 10.0.1.1If you use the Content Engine GUI to enable and configure WCCP on this Content Engine, then you must specify the designated router list for the reverse-proxy service in the following Content Engine GUI window: the Reverse Proxy window (WCCP > Reverse Proxy).
Step 3
ContentEngine(config)# wccp reverse-proxy router-list-num 1Step 4
ContentEngine(config)# exitStep 5
ContentEngine# write memoryStep 6
Router# configure terminalRouter(config)# ip wccp version 2Step 7
Router(config)# ip wccp 99Step 8
Router(config)# interface type numberIn the following example, the Ethernet 0 interface on the router is configured to run the reverse-proxy service.
Router(config)# interface ethernet 0Step 9
Router(config-if)# ip wccp 99 redirect out
Configuring HTTPS Caching for Standalone Content Engines
The HTTPS protocol is essentially the HTTP protocol running over a Secure Socket Layer (SSL) transport. SSL is a protocol that provides a secure channel between two devices (for example, a client and a server). SSL uses public-key crypotography to ensure the security and privacy of the exchange between the client browser and the server. HTTPS uses a unique URL that begins with https:// (for example, https://abc.com). The default port number for HTTPS is port 443 instead of port 80, which is the default port for HTTP.
Content Engines can either SSL terminate or tunnel HTTPS client requests to the origin HTTPS server, as described in the following sections:
•
•
For information about how to configure the different types of HTTPS caching on a standalone Content Engine, see:
•
•
About SSL Termination of HTTPS Client Requests
If the Content Engine SSL terminates an HTTPS client request, this means that it 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. Content Engines running ACNS software, Release 5.1 and later, support this SSL-termination feature. Content Engines running ACNS 5.2 and later, can also rewrite and redirect HTTPS requests as defined by the specified rules. If the Content Engine terminates an HTTPS request, it can apply most of the rules on the HTTPS request. (The no-proxy, use-icap-service, and use-proxy rule actions are not supported for HTTPS caching.) For more information, see "Configuring the Rules Template on Standalone Content Engines."
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. For standalone Content Engines, this is performed through the Content Engine CLI, as described in the "Configuring Certificates and Private Keys for HTTPS Caching" section.
In ACNS 5.2 software, the Content Engine SSL terminates HTTPS requests in WCCP mode and in manual proxy mode if the requested HTTPS servers are configured on the Content Engine, and tunnels the rest of the HTTPS traffic.
About Tunneling of HTTPS Client Requests
Tunneling of HTTPS request is another mode that ACNS software supports for HTTPS client requests. In this mode, the Content Engine can only support limited processing on the HTTPS client requests (for example, no caching support, and only limited filtering support).
ACNS software, Release 3.0 and later, supports HTTPS tunneling through the CONNECT method, which is the standard HTTPS tunneling method that is defined in the HTTP specification.
ACNS software, Release 5.1.5 and later, supports tunneling of transparently redirected native HTTPS traffic. This means that the Content Engine can accept native HTTPS traffic from the client and tunnel such requests to the origin HTTPS server. Even though the Content Engine can apply filtering on such traffic, it does not see the actual HTTPS content because the certificate and private key of the origin HTTPS server is not installed on the Content Engine.
Configuring HTTPS Proxy Caching for Standalone Content Engines
With HTTPS proxy caching, direct proxy routing is used to direct HTTPS requests (HTTPS-over-HTTP from client browsers) directly to the Content Engine. The Content Engine functions as a nontransparent forward proxy server (nontransparent HTTPS proxy server) for these client browsers. For information about how to configure a client browser to point directly to a Content Engine, see the "Pointing Client Browsers Directly to a Standalone Content Engine" section.
Configure the Content Engine to operate in HTTPS proxy mode to allow the Content Engine to service HTTPS requests from client browsers that have been configured to use this Content Engine as their HTTPS proxy server.
Note
From the Content Engine GUI, choose Caching > HTTPS Proxy, and use the displayed HTTPS Proxy window. To obtain more information about how to use the HTTPS Proxy window to configure HTTPS proxy caching, click the HELP button in the window.
From the Content Engine CLI, use the https proxy global configuration command, as described in Table 6-8. The order in which the CLI commands are entered is not important.
The following scenario shows how to configure a standalone Content Engine to support HTTPS-over-HTTP proxy caching.
Step 1
https proxy incoming ports
where ports are the ports (in addition to port 80) on which the standalone Content Engine will accept incoming HTTPS requests from client browsers. This number ranges from 1 to 65535. You can specify up to eight ports.
This example configures the Content Engine to accept HTTPS requests on ports 8080, 8081, and 9090. If multiple ports are entered, separate each port number with a blank space.
ContentEngine(config)# https proxy incoming 8080 8081 9090Remember that if you use this command to configure the Content Engine to accept HTTPS-over-HTTP requests on a port other than port 80, you must also configure the client browsers to send their HTTPS requests to that port on the Content Engine. For more information, see the "Pointing Client Browsers Directly to a Standalone Content Engine" section.
Step 2
•
•
Use the primary keyword to set the specified host as the primary outgoing HTTPS proxy server. If several servers (hosts) are configured with the primary keyword, the last one configured becomes the primary outgoing HTTPS proxy server for the Content Engine.
In this example, Content Engine A is configured to send its cache miss HTTPS traffic (cache misses for browser HTTPS-over-HTTP requests) to the host 10.1.1.1 on port 8088. Host 10.1.1.1 is explicitly designated as the primary outgoing HTTPS proxy server for Content Engine A. Host 10.1.1.2 is configured as a backup outgoing HTTPS proxy server for Content Engine A.
ContentEngineA(config)# https proxy outgoing host 10.1.1.1 8088 primaryContentEngine(config)# https proxy outgoing host 10.1.1.2 220In ACNS software, Releases 5.1.x and earlier, you could only configure the Content Engine to use one outgoing HTTPS proxy server. With ACNS 5.2 software, you can specify up to eight outgoing proxy servers for HTTPS-over-HTTP proxy requests. The benefit of supporting up to eight outgoing HTTPS proxy servers is that if one outgoing proxy fails, the Content Engine will fail over to the next specified outgoing proxy server, thereby providing redundancy. All outgoing requests will be directed to the primary outgoing proxy server. If the primary proxy server fails, requests are directed to the next active proxy server on the list.
Step 3
Configuring HTTPS Transparent Caching for Standalone Content Engines
To configure a Content Engine to support HTTPS transparent caching, you must configure the Content Engine and a router support the WCCP Version 2 HTTPS caching service (the https-cache service [service 70]). The https-cache service is the WCCP HTTPS caching service that permits WCCP Version 2-enabled routers to intercept port 443 TCP traffic and redirect this HTTPS traffic to the Content Engine (that is acting as a transparent forward proxy server, which is configured for HTTPS transparent caching). The Content Engine retrieves the requested content, stores a copy locally (performs HTTPS transparent caching) if the content is cacheable, and serves the requested content to the client.
In ACNS 5.1.x software, only one interception mode (the accept-only mode) was supported for the https-cache service. With the accept-only mode, the Content Engine can only accept requests that are directed to configured HTTPS servers.
ContentEngine(config)# wccp https-cache router-list-num 1or
ContentEngine(config)# wccp service-number 95 router-list-num 1 port-list 1 https-cache
In both of the above examples, the Content Engine would only accept redirected HTTPS traffic if the HTTPS server was configured on the Content Engine (that is, you had used the https server global configuration command to specify the IP address or host name and the private key and certificate of the origin HTTPS server on the Content Engine).
In ACNS 5.2 software, another interception mode (the accept-all mode) was added for the https-cache service (service 70). When the accept-all mode is enabled, the Content Engine intercepts all HTTPS requests regardless of whether the origin HTTPS server is configured on the Content Engine. If the private key or certificate of the origin HTTPS server is not configured on the Content Engine, the Content Engine tunnels the request to the origin HTTPS server instead of SSL terminating the request. (In ACNS 5.1 software, the Content Engine would bypass HTTPS requests that were directed to HTTPS servers that it had not been explicitly configured to support.)
The accept-all mode was added to support the filtering of HTTPS traffic. See below.
ContentEngine(config)# wccp https-cache ?accept-all Accept all https traffic by defaultmask Specify mask used for CE assignementrouter-list-num Router list numberThe accept-all mode works the same way as the traditional WCCP services do (for example, the standard web-cache service [service 0] that intercepts all web traffic by default). If the wccp https-cache accept-all option is used, the HTTPS cache (the Content Engine that has the https-cache service configured and enabled) operates in "accept all" mode (that is, all HTTPS traffic is intercepted by the Content Engine). If the wccp https-cache accept-all option is not used, the Content Engine operates in "accept only" mode.
The Content Engine listens for redirected HTTPS requests on the standard HTTPS port (default port 443). To intercept HTTPS traffic on ports other than the default port, configure a user-defined WCCP service (services 90 to 97). For more information on this topic, see the "Configuring Standalone Content Engines to Support User-Defined WCCP Services" section.
The following scenario shows how to configure HTTPS transparent caching on a standalone Content Engine and a single router running WCCP Version 2.
Step 1
a.
RouterA# configure terminalRouterA(config)# ip wccp version 2b.
RouterA(config)# ip wccp 70c.
Router(config)# ip wccp 70 redirect outStep 2
a.
ContentEngine(config)# wccp router-list 1 10.1.202.1b.
ContentEngine(config)# wccp https-cache router-list-num 1c.
ContentEngine(config)# wccp version 2d.
ContentEngine(config)# wccp https-cache accept-allStep 3
a.
ContentEngine# https ?cert Certificate management commandscertgroup Certificate chain management commandskey Private key management commandsFor more information, see the "Configuring Certificates and Private Keys for HTTPS Caching" section.
Step 4
Step 5
a.
ContentEngine(config)# https server abc1ContentEngine(config-https)#b.
ContentEngine(config-https)# cert ?WORD Certificate nameContentEngine(config-https)# key ?WORD Private key nameContentEngine(config-https)# host ?WORD FQDN or ip address of the origin HTTPS serverContentEngine(config-https)# enableUse the cert and key command options to configure a Content Engine to use a set of SSL certificates and keys that will enable the Content Engine to act as the origin HTTPS server. The Content Engine will be able to decode HTTPS traffic from a client and perform normal HTTP operations on it, such as caching and request processing. The Content Engine will be able to initiate HTTPS connections to an origin server and fetch content from origin servers upon cache miss (or cache validation). For more information, see the "Configuring HTTPS Server Settings on Standalone Content Engines" section.
Step 6
a.
b.
ContentEngine(config-https)# protocol-version ?sslv2-only Only use and understand SSL v2 protocolsslv23-tlsv1 Use and understand SSL v2/v3 and TLS v1 protocols (default)sslv3-only Only use and understand SSL v3 protocoltlsv1-only Only use and understand TLS v1 protocolor
CONTENTENGINE(config)# https server name protocol-version ?sslv2-only Only use and understand SSL v2 protocolsslv23-tlsv1 Use and understand SSL v2/v3 and TLS v1 protocols (default)sslv3-only Only use and understand SSL v3 protocoltlsv1-only Only use and understand TLS v1 protocolc.
ContentEngine(config-https)# serverauth ignore ?cert-not-yet-valid Ignore errors caused by using the certificate bevaliddomain-name Ignore errors due to domain name mismatchexpired-date Ignore certificate expiration errorsinvalid-ca Ignore errors caused by an unrecognized CAd.
ContentEngine(config-https)# session-cache ?size SSL session cache size settingtimeout SSL session cache timeout setting
Configuring HTTPS Server Settings on Standalone Content Engines
After you have specified the name of an origin HTTPS server on a Content Engine using the https server server-name global configuration command, you can specify a set of parameters for the configured HTTPS server (see the sample below). You can specify these parameters from the HTTPS configuration submode or from global configuration mode.
ContentEngine(config)# https server abc1ContentEngine(config-https)# ?cert Select certificate to use for the HTTPS servercertgroup Select certificate chains for the HTTPS serverenable Enable caching of the HTTPS serverhost Input hostname or ip address of the origin HTTPS servekey Select private key to use for the HTTPS serverprotocol-version SSL protocol versions for client/server communicationserverauth HTTPS server authentication commandssession-cache SSL session caching parameters tuning<cr>Table 6-9 describes the global configuration commands for configuring the HTTPS server settings on a standalone Content Engine.
Configuring Certificates and Private Keys for HTTPS Caching
In ACNS software, Release 5.1 or later, the Content Engine CLI can be used to configure certificates and private keys on the Content Engine in order to support HTTPS caching. (The Content Engine GUI does not currently support this configuration capability.)
Use the https EXEC command to create, remove, and import certificates and private keys when using a standalone Content Engine as an HTTPS server. Table 6-10 describes the parameters for the https cert cert-name and https key key_name EXEC commands.
You can assign a certificate and associate a key with the HTTPS server assuming that you have configured the Content Engine with the https server global configuration command. The Content Engine presents the certificate to HTTPS clients that make requests to the HTTPS server.
Use the https cert EXEC command to create certificates with a given name, to import a certificate from external sources, or to remove existing certificates from the Content Engine.
Note
Configuring Certificate Groups for HTTPS Caching
In ACNS software, Release 5.1 or later, the Content Engine CLI can be used to configure certificate groups a on the Content Engine in order to support HTTPS caching. (The Content Engine GUI does not currently support this configuration capability.)
Certificate groups are formed to represent a trust relationship chain from root Certificate Authority to end entity. Each one of the certificates in a certificate group except the end entity's certificate signs and trusts the next one in the chain. An end entity's certificate can be trusted only if all certificates in the certificate group leading to this certificate can be trusted. A certificate group can be used to represent an HTTPS server just like a single certificate, but with the added benefit that the client does not need to have all certificates locally. A certificate group can also be used to verify and authenticate an HTTPS server by comparing the server's certificates to the certificate group.
Use the https certgroup cert-name EXEC command to create, remove, or form certificate groups on a standalone Content Engine. Table 6-11 describes the parameters for the https certgroup cert-name EXEC command.
Configuring HTTPS Outgoing Proxy Servers for Standalone Content Engines
When you use the https proxy outgoing host global configuration command to configure the Content Engine to use an HTTPS outgoing proxy, all incoming HTTPS requests are directed to this outgoing proxy. The proxy-protocols outgoing-proxy exclude global configuration command specifies a global proxy exclude domain effective for all proxy server protocols, including HTTPS.
The Content Engine applies the following logic when an outgoing proxy is configured:
•
•
•
When a Content Engine intercepts a proxy request intended for another proxy server and there is no outgoing proxy configured for HTTPS, and the proxy-protocols transparent default-server global configuration command is invoked, the Content Engine addresses the request to the destination server directly and not to the client's intended proxy server. However, if the proxy-protocols transparent reset global configuration command is used on the Content Engine and a cache miss occurs, all transparently intercepted requests sent by clients are returned to the client and requested objects are not delivered. For more information about configuring HTTPS outgoing proxy exclusion settings on standalone Content Engines, see the "Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings" section.
The following example shows how to configure the Content Engine (which is acting as a nontransparent forward proxy) as an HTTPS proxy server and have it listen on port 8081 for HTTPS requests from client browsers.
ContentEngine(config)# https proxy incoming 8081In this example, Content Engine A is configured to send its missed HTTPS traffic (cache misses for browser requests for HTTPS content [HTTPS-over-HTTP requests]) to the host 10.1.1.1 on port 8088. Host 10.1.1.1 is explicitly designated as the primary outgoing HTTPS proxy server for Content Engine A. Host 10.1.1.2 is configured as a backup outgoing HTTPS proxy server for Content Engine A.
ContentEngineA(config)# https proxy outgoing host 10.1.1.1 8088 primaryContentEngine(config)# https proxy outgoing host 10.1.1.2 220In ACNS software, Releases 5.1.x and earlier, you could only configure the Content Engine to use one outgoing HTTPS proxy server. In ACNS 5.2 software, the ability to configure the Content Engine to use up to eight outgoing HTTPS proxy servers was added. For more information on this topic, see "Configuring Primary and Backup Proxy Servers for Standalone Content Engines."
In transparent mode, all HTTPS proxy-style requests intended for another HTTPS proxy server are accepted. The Content Engine acts on these transparently received requests as defined by the proxy-protocols transparent global configuration command. For more information on this topic, see the "Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings" section.
Preventing Unwanted Access to Any Destination Port
A Content Engine may not provide the desired level of security if rules controlling access (allow or deny) to destination ports are not configured on the Content Engine.
Caution
In order to prevent web users from creating HTTPS tunnels to non-HTTPS servers, access to destination ports can be restricted. The restrictions can be made for individual ports or for all ports. In the case of a conflict in the restriction rules, the individual port setting takes precedence over the "all" rule, and the "allow" rule takes precedence over the "deny" rule.
Preventing access to destination ports is supported with WCCP transparent redirection (that is, a WCCP Version 2-enabled router transparently intercepts and redirects HTTPS request to the Content Engine) as well as with direct proxy routing, in which client browsers send their HTTPS requests directly to the Content Engine.
You can use the Content Engine GUI or CLI (see below) to configure this feature. To use the Content Engine GUI, choose Cache > HTTPS Proxy, and use the displayed HTTPS Proxy window to restrict destination ports. To obtain more information about how to use the HTTPS Proxy window, click the HELP button in the window.
To use the Content Engine CLI, enter this command:
ContentEngine(config)# https destination-port ?allow Allow HTTPS traffic to port (443 and 563 allowed by default)deny Deny HTTPS traffic to port (port under 1024 denied by default)To prevent unwanted access to any destination HTTPS port when a request is going through the Content Engine, use the following command sequence:
ContentEngine(config)# no https destination-port allow 443 563ContentEngine(config)# https destination-port deny allThis command sequence denies access to any port above and below 1024. Ports 443 and 563 (the standard HTTPS ports) must be explicitly denied access using the no https destination-port allow 443 563 global configuration command.
Note
For example, when these commands are configured on the Content Engine and the request to access port xxx at https://banking.wellsfargo.com is redirected to this Content Engine either through WCCP transparent redirection or direct proxy routing, the connection to port xxx is denied.
Configuring FTP Caching for Standalone Content Engines
This section provides an overview of FTP caching features that are available with a standalone Content Engine, and how to configure the different types of FTP caching, as follows:
•
•
The Content Engine has the ability to handle FTP-style requests over HTTP transport when configured in proxy mode. When the Content Engine receives an FTP request from a client, it processes the request by searching its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server if this proxy server has been configured, or it fetches the object directly from the origin FTP server.
ACNS software, Release 5.1 or later, also supports native FTP caching with Content Engines (transparent proxy servers) and WCCP Version 2-enabled routers. You can use the Content Engine GUI or the CLI to configure FTP caching on a standalone Content Engine.
Overview of FTP Caching with Standalone Content Engines
A standalone Content Engine that is running ACNS software, Release 5.1 or later, can be configured for FTP caching in the following two usage modes:
•
•
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, as shown in the following example:
ContentEngine# ftp server.cisco.com
Note
Native FTP requests are logged in the HTTP transaction log on the standalone Content Engine.
About Native FTP Caching Support
A standalone Content Engine that is operating as an FTP proxy supports passive and active mode for fetching files and directories. In native FTP caching mode, if the ftp proxy active-mode enable global configuration command is used 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 the ftp proxy active-mode enable command is not specified, the Content Engine uses passive mode with the FTP server for the data connection.
The following partial output of the show ftp EXEC command shows that if you use the ftp proxy active-mode enable global configuration command, the Content Engine (the nontransparent proxy server that is functioning as a native FTP proxy server) adheres to the client's mode (active or passive):
•
•
ContentEngine# show ftpFTP Configuration-----------------WCCP FTP service status: ENABLEDMaximum size of a FTP cacheable object: 204800 KBytesFTP data connection mode with Server: Adhere to Client's mode (active or passive)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).
•
•
ftp://*user*:*password*@10.100.200.5/home/myhome/mybinfile.obj;type=iThe 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.txtThe following two examples demonstrate the use of native FTP with a Content Engine. In the first example, the user logs in with an actual username name ("huff") and is able to retrieve the requested file (test.c) from the FTP server. Note that in this case, the current directory for the user named "huff" is "/home/huff."
ContentEngine# ftp server.cisco.comConnected to server.cisco.com.220 server.cisco.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.Name (server:huff): huff331 Password required for myserver.Password:230 User huff logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> pwd257 "/home/huff" is current directory.ftp> get /tmp/test.c200 PORT command successful.150 Opening BINARY mode data connection for /tmp/test.c (645 bytes).226 Transfer complete.645 bytes received in 0.00077 seconds (8.2e+02 Kbytes/s)ftp> quitContentEngine#In the example shown below, the user logs in as an anonymous user and cannot retrieve the requested file (test.c) because the file is not located in the document root directory of the FTP server ("/"), which is the current directory for any anonymous user.
ContentEngine# ftp server.cisco.comConnected to server.cisco.com.220 server.cisco.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.Name (server:huff): anonymous331 Guest login ok, send your complete e-mail address as password.Password: test@cisco.com230 Guest login ok, access restrictions apply.Remote system type is UNIX.Using binary mode to transfer files.ftp> pwd257 "/" is current directory.ftp>ftp> passivePassive mode onftp> get(remote-file) /tmp/test.c(local-file) test.clocal: test.c remote: /tmp/test.c227 Entering Passive Mode (172.31.255.255)550 /tmp/test.c: No such file or directory.ftp>ContentEngine#About FTP-Over-HTTP Caching Support
ACNS software, Release 5.1 or later, 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). The following example of an FTP-over-HTTP request shows how the end user can 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 download 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.
About FTP Cache Freshness
ACNS 5.x software can be tuned to balance HTTP and FTP object freshness with the cache hit rate. The ACNS software default parameters are weighted in favor of securing fresh content over maximizing the cache hit rate (to avoid the undesirable scenario of increasing the cache hit rate by serving stale content).
Tip
You can use the Content Engine GUI or CLI to configure FTP cache object freshness settings for standalone Content Engines. These parameters can be configured for either directory listings or particular objects in the cache.
•
•
For FTP-over-HTTP caching, you can also use the ftp age-multiplier, ftp max-ttl, ftp object, ftp reval-each-request, and the ftp min-ttl global configuration commands. The following example configures a maximum Time To Live of 3 days in the cache for directory listing objects and file objects for FTP-over-HTTP caching.
ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3The following example configures the Content Engine to keep FTP objects in the cache for a minimum of 10 minutes and a maximum of 24 hours (1 day) for FTP-over-HTTP caching.
ContentEngine(config)# ftp min-ttl 10ContentEngine(config)# ftp max-ttl hours directory-listing 24 file 24Restrictions Regarding Native FTP Caching in ACNS 5.1 and 5.2 Software
Restrictions regarding native FTP caching support in ACNS software, Release 5.1 and 5.2, are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring Native FTP Caching for Standalone Content Engines
The ftp service (service 60) is the WCCP caching service that permits WCCP Version 2-enabled routers to redirect native FTP requests transparently to a 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 requestor. For background information about native FTP caching, see the "About Native FTP Caching Support" section.
To configure native FTP caching with a standalone Content Engine (transparent proxy server) and a WCCP Version 2-enabled router, follow these steps:
Step 1
ContentEngine(config)# wccp ftp ?mask Specify mask used for CE assignmentrouter-list-num Router list numberContentEngine(config)# wccp ftp mask ?dst-ip-mask Specify sub-mask used in packet destination-IP addresssrc-ip-mask Specify sub-mask used in packet source-IP addressContentEngine(config)# wccp ftp router-list-num ?<1-8> Router List NumberStep 2
In native FTP caching mode, if this command is used, 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 this command is not used, the Content Engine uses passive mode with the FTP server for the data connection.
Step 3
ContentEngine# show wccp servicesServices configured on this Content EngineWeb CacheCustom Web CacheFTP CacheRTSPStep 4
ContentEngine# show wccp modulesModules registered with WCCP on this Content EngineModule Socket Expire(sec) Name Supported Services------ ------ ----------- --------------- ------------------5 6 3 FTP Proxy FTP Cache1 7 3 RTSP Proxy RTSP0 8 3 HTTP Proxy Web CacheReverse ProxyCustom Web CacheWCCPv2 Service 90WCCPv2 Service 91WCCPv2 Service 92WCCPv2 Service 93WCCPv2 Service 94WCCPv2 Service 95WCCPv2 Service 96WCCPv2 Service 97ContentEngine# show wccp masks ?custom-web-cache Custom web caching serviceftp FTP Proxy caching servicereverse-proxy Reverse Proxy web caching servicertsp Media caching serviceweb-cache Standard web caching serviceStep 5
ContentEngine# show ftpFTP over HTTP Configuration---------------------------FTP heuristic age-multipliers: directory-listing 30% file 60%Maximum time to live in days: directory-listing 3 file 7Minimum time to live for all objects in minutes: 30Incoming Proxy-Mode:Configured Proxy mode FTP connections on ports: 80 8080Outgoing Proxy-Mode:Not using outgoing proxy mode.Active mode of FTP transfer is enabledMaximum size of a FTP cacheable object is 204800 KBytesNo object is revalidated on each requestFTP Configuration-----------------WCCP FTP service status: ENABLEDMaximum size of a FTP cacheable object: 204800 KBytesFTP data connection mode with Server: Adhere to Client's mode (active or passive)Step 6
a.
Router(config)# ip wccp 60b.
Router(config)# interface type numberc.
Router(config-if)# ip wccp 60 redirect out
Configuring FTP-over-HTTP Caching on Standalone Content Engines
You can use the Content Engine GUI or CLI commands to configure FTP-over-HTTP caching on standalone Content Engines, which are nontransparent forward proxy servers. With FTP-over-HTTP caching, the standalone Content Engine is functioning as a nontransparent forward proxy server for FTP-over-HTTP requests from client browsers. For more background information about this type of caching, see the "About FTP-Over-HTTP Caching Support" section.
From the Content Engine GUI, choose Caching > FTP Proxy, and use the displayed FTP Proxy window. To obtain more information about how to use the FTP Proxy window to configure FTP-over-HTTP caching, click the HELP button in the window.
From the Content Engine CLI, follow these steps:
Step 1
ftp proxy incoming ports
where ports are the port numbers on which the standalone Content Engine will accept incoming FTP-over-HTTP requests from client browsers in addition to port 80. Valid port numbers are 1 to 65535. You can specify up to eight ports.
The following example configures the Content Engine to accept FTP-over-HTTP requests (FTP requests from client browsers) on ports 8080, 8081, and 9090. Up to eight incoming proxy ports can be configured on the same command line.
ContentEngine(config)# ftp proxy incoming 8080 8081 9090Remember that if you use this command to configure the Content Engine to accept FTP-over-HTTP requests on a port other than port 80, you must also configure the client browsers to send their FTP requests to that port. For more information, see the "Pointing Client Browsers Directly to a Standalone Content Engine" section.
Step 2
The following example sets the maximum size for an FTP object size to 2 megabytes.
ContentEngine(config)# ftp object max-size 2000
Step 3
ContentEngine(config)# ftp reval-each-request allStep 4
In ACNS software prior to Release 5.2, you could specify only a single outgoing proxy server for the FTP protocol. With ACNS 5.2 software, you can specify up to eight outgoing proxy servers for FTP-over-HTTP proxy requests. The benefit of supporting up to eight outgoing FTP proxy servers is that if one outgoing proxy fails, the Content Engine fails over to the next specified outgoing proxy server, thereby providing redundancy. All outgoing requests are directed to the primary outgoing proxy server. If the primary proxy server fails, requests are directed to the next active proxy server on the list.
Tip
The first specified outgoing FTP proxy server is designated the primary outgoing FTP server by default. In the following example, Content Engine A is configured to send its miss FTP traffic (cache misses for browser requests for FTP content [FTP-over-HTTP requests]) to Host 10.1.1.1 on port 8088. Host 10.1.1.1 is designated as the primary outgoing FTP proxy server for Content Engine A. Host 10.1.1.2 is configured as a backup outgoing FTP proxy server for Content Engine A.
ContentEngineA(config)# ftp proxy outgoing host 10.1.1.1 8088ContentEngine(config)# ftp proxy outgoing host 10.1.1.2 220Step 5
Step 6
In FTP-over-HTTP caching mode, if the ftp proxy active-mode global configuration command is used the Content Engine first attempts to use active mode with the FTP server for the data connection. If the active mode fails, the Content Engine attempts to use passive mode for the data connection.
In FTP-over-HTTP-caching mode, if the ftp proxy active-mode command is not used the Content Engine first attempts to use passive mode with the FTP server for the data connection, and automatically switches to active mode if passive mode is not supported by the FTP server.
Configuring the TFTP Server and Gateway for Standalone Content Engines
In ACNS software, Release 5.1 or later, the Trivial File Transfer Protocol (TFTP) gateway feature enables Content Engines to serve content files requested by networking devices that use native TFTP. Content Engines now perform TFTP-to-HTTP or TFTP-to-FTP translation, eliminating the need for the system administrator to configure and manage a dedicated TFTP server to serve TFTP requests. This feature allows the Content Engine to accept native TFTP requests from the client at the front end and serve the request using the HTTP or FTP protocol at the back end; hence, the term TFTP gateway.
Content files include router software images, router configurations, IP phone configuration files, and so forth. If the requested file is not available on the Content Engine, the Content Engine caches the file on the fly from the origin server. The Content Engine that is functioning as a caching engine retrieves the file from the Internet on behalf of the device and forwards it to the device. Future requests by any devices for the same file are satisfied by forwarding the file from the local cache on the Content Engine.
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 caches the file on the fly from the origin server. The Content Engine that is functioning as a caching engine, retrieves the file from the Internet on behalf of the device and forwards it to the device. Future requests by any devices for the same file are satisfied by forwarding the file from the Content Engine's local cache.
Note
After the TFTP server has been enabled on the Content Engine, and a client sends a TFTP request for a file, the following events occur:
1.
2.
3.
4.
5.
6.
Using the TFTP Service and Gateway on Standalone Content Engines
You can use the tftp-server global configuration command to configure the TFTP service and gateway on a standalone Content Engine to serve content in response to TFTP requests in two ways:
•
•
When both the TFTP server and gateway are enabled, the Content Engine responds to TFTP requests by searching for files in its default local directory if the full path name is not specified in the request. Otherwise, it looks in the local directory that matches the directory in the path name. If the file is not found, it uses the HTTP or FTP protocol to forward the request to the Content Engine that is functioning as a caching engine. If the file is found on a remote server, the Content Engine caches the file and sends the file to the client that issued the request. The Content Engine replies to subsequent requests for the file from its local cache. If the file is not found, the Content Engine replies to the request with a 404 "File not found" message.
By default, the TFTP service is disabled and access to the TFTP server is denied.
The default local directory assigned to the TFTP server is /tftpboot. However, this directory must be created using the mkdir command.
The TFTP timeout value is fixed at 5 seconds, and the number of retries is fixed at five retries. These values are nonconfigurable.
Enabling the TFTP Server and Gateway
To serve requests for local content, follow these steps:
1.
2.
a.
b.
When you use the tftp-server dir command to identify one or more local directories, the first directory identified becomes the default directory. Enter the tftp-server dir command once for each directory that you want to identify.
The TFTP server searches for files without a fully qualified path name in its default directory. The TFTP server only looks for files in the other local directories if the TFTP request explicitly identifies the directory.
If you do not configure any local directories, /tftpboot is automatically assigned as the default directory. However, you would still need to create the /tftpboot directory using the mkdir command before the TFTP server can serve requests.
To use the TFTP gateway to serve content from remote servers, you must enable the TFTP server and also identify the remote servers to which the TFTP gateway (the standalone Content Engine) will direct requests. To identify the servers to which the Content Engine will direct requests when it cannot find the requested files in its local directories, use the tftp-server gw proto command. For more information on this topic, see the next section, "Configuring the TFTP Server and Gateway on Standalone Content Engines."
To enable the TFTP server or gateway on a standalone Content Engine, follow these steps:
1.
2.
3.
4.
Note
Configuring the TFTP Server and Gateway on Standalone Content Engines
The TFTP server searches for files in the default local directory when it receives a request that does not identify the full directory path to the file. If you do not configure any local directories, the default directory is /tftpboot. Although this directory is automatically assigned as the default directory, you still need to create it (or any other directories you assign to the TFTP server) using the mkdir EXEC command.
When you use the tftp-server dir global configuration command to identify one or more local directories, the first directory identified becomes the default directory. Enter the tftp-server dir global configuration command once for each directory that you want to identify.
The TFTP server only looks for files in the other directories if the TFTP request explicitly identifies the directory.
To configure the TFTP server and gateway on a standalone Content Engine, use the tftp-server global configuration command and follow these steps:
Step 1
For example, the following commands configure two local directories from which the Content Engine will try to fulfill TFTP requests:
ContentEngine(config)# mkdir /local/mydirContentEngine(config)# mkdir /local/clientsContentEngine(config)# tftp-server dir /local/mydirContentEngine(config)# tftp-server dir /local/clientsThe first directory specified, /local1/mydir, is considered the default directory.
Step 2
tftp-server access-list {acl-num | acl-name}
For example, configure the Content Engine to check access list 1 to determine if TFTP access should be allowed or denied.
ContentEngine(config)# tftp-server access-list 1Step 3
tftp-server gw proto {ftp | http} server {hostname | ip_address}
[name name passwd password] [path directory] pri priority
Note
Table 6-12 describes the parameters for the tftp-server gw proto global configuration command.
The following example shows how to enable the TFTP server on a standalone Content Engine.
ContentEngine(config)# inetd enable tftpThe following example shows how to define a standard access list that permits access to the TFTP service for FTP clients on the 192.168.1.0 subnetwork.
ContentEngine(config)# ip access-list standard 1ContentEngine(config-std-nacl)# ip access-list permit 192.168.1.0 0.0.0.255ContentEngine(config-std-nacl)# exitThe following example shows how to configure two local directories from which the Content Engine will try to fulfill TFTP requests.
ContentEngine(config)# tftp-server dir /local1/mydirContentEngine(config)# tftp-server dir /local1/clientsThe first directory specified, /local1/mydir, is considered the default directory.
The following command identifies the IP access list that permits access to the TFTP service.
ContentEngine(config)# tftp-server access-list 1The following example shows how to enable the TFTP gateway feature on a standalone Content Engine, and identify the FTP server to which the Content Engine should forward requests when it cannot find the file in its local directories. It also sets the username and password for authentication to the origin server.
ContentEngine(config)# tftp-server gw proto ftp 192.168.100.1 pri 1 path /myremotedir name myuser passwd mypasswordThe directory name /myremotedir is used in the URL sent by the ACNS caching service on the Content Engine to retrieve the file from the remote server. The URL created by using this sample configuration would be as follows:
ftp://myuser:mypasswd@192.168.100.1/myremotedir/requested-file-name
Configuring DNS Caching for Standalone Content Engines
This section describes how to deploy Domain Name System (DNS) caching on standalone Content Engines, and covers the following topics:
•
•
About DNS Caching for Standalone Content Engines
DNS is a system used in the Internet for translating names of network nodes into IP addresses. DNS allows the network to translate domain names entered in requests into their associated IP addresses. For example, when end users (web clients) enter http://www.cisco.com into their browsers, DNS translates the domain name cisco.com into its associated IP address so that these requests can be processed (that is, the requested content can be served to the web clients).
DNS caching allows the Content Engine to cache DNS entries to avoid multiple WAN accesses for DNS server resolution. When you enable DNS caching on a standalone Content Engine, the Content Engine caches the results of recent DNS queries for faster resolution of identical queries in the future. This cached information is then made available to clients making future requests. The ability to store DNS information that can then be distributed to requesting clients turns the Content Engine into a DNS caching name server.
Caution
In centrally managed ANCS networks, configuring the DNS caching service with WCCP interception on a centrally managed Content Engine causes a conflict with the Content Router, because they will both be listening for DNS requests on the same port (port 53). Consequently, they are mutually exclusive and you should not configure DNS cache support with WCCP interception in such environments. You can, however, enable the standard DNS caching service (without WCCP interception support) in centrally managed ACNS networks.
To configure DNS caching on a standalone Content Engine, you can use the Content Engine GUI or CLI. You must specify the IP address of the DNS server that the Content Engine should use for domain name resolution, and then enable DNS caching on the Content Engine. By default, DNS caching is disabled on a Content Engine.
To enable DNS caching on a standalone Content Engine, you must complete the following tasks:
•
•
•
•
Transparent interception of DNS requests using WCCP was added in ACNS software, Release 5.1. To enable this feature, you must configure the WCCP Version 2 DNS caching service (service 53) on the Content Engine and the WCCP Version 2-enabled router. For more information on this topic, see the "DNS WCCP Transparent Interception Overview" section.
Domain Name Resolution Requirements
Domain name resolution requires that at least one DNS name server be configured on the Content Engine. You can configure one or more DNS name servers for the Content Engine by defining a list of DNS servers for the Content Engine through the Content Engine GUI (the System > DNS option) or the CLI (the ip name-server global configuration command). For more information about defining this list of DNS servers, see the "Configuring DNS Servers for the DNS Caching Service (Service 53)" section.
DNS WCCP Transparent Interception Overview
For transparent interception of DNS requests using WCCP, you must configure the DNS caching service (service 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:
•
•
•
By default, the ACNS DNS caching service (service 53) uses the DNS servers configured on the Content Engine rather than the original DNS server. For information about how to configure a list of DNS servers on the Content Engine, see the next section, "Configuring DNS Servers for the DNS Caching Service (Service 53)."
Configuring DNS Servers for the DNS Caching Service (Service 53)
By default, the Content Engine uses a DNS server from its list of configured DNS servers for domain name resolution.
•
•
If the DNS WCCP interception feature is enabled (that is, service 53 is configured on the Content Engine and a WCCP Version 2-enabled router), you can use the dns use-original-server global configuration command to define which DNS server a standalone Content Engine should use to resolve a domain name, as described in Table 6-13.
You can use the Content Engine GUI or the CLI to configure one or more DNS servers for the Content Engine
Note
Configuring the DNS Caching Service (Service 53) for Standalone Content Engines
The DNS caching service (the dns service [service 53]) is the WCCP service that permits WCCP Version 2-enabled routers to redirect client requests transparently to a Content Engine for the Content Engine to resolve the DNS name. After the Content Engine resolves the DNS name, it stores the resolved DNS name locally so that it can use these resolved names for future DNS requests.
To configure DNS caching for a standalone Content Engine, follow these steps:
Step 1
Router# configure terminalRouter(config)# ip wccp version 2Step 2
Router(config)# ip wccp 53Step 3
Router(config)# interface type numberStep 4
Router(config-if)# ip wccp 53 redirect outStep 5
ContentEngine(config)# wccp version 2Step 6
ContentEngine(config)# wccp dnsStep 7
In the following example, the listener IP address, port number, and host name are configured first. Then DNS caching is enabled on the Content Engine.
ContentEngine(config)# dns listen 10.1.1.0 port 53 hostname acmeIf the dns listen name does not match a DNS name, use the dns pin global configuration commands to pin an IP address to name mapping. The dns pin global configuration commands (both, cname, forward, and reverse) allow you to lock an IP address against a name within the cache. The forward option maps the host name to the IP address. The reverse option maps the IP address to the host name. The both option maps in both the forward and reverse directions. The cname option inserts the canonical name (CNAME) mapping.
Step 8
Step 9
Because the DNS protocol is using UDP packets that 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 60 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 initial DNS server contacted returns a DNS failed response to the requesting client.
Step 10
Step 11
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.
ContentEngine(config)# dns enableStep 12
To avoid unduly taxing overall system resources, it is important that you impose a strict maximum memory limit for Content Engine. In the following example, the size of the DNS cache is set to 20,000 records.
ContentEngine(config)# dns-cache size 20000
Note
Disabling DNS Caching on Standalone Content Engines
To disable DNS caching on a standalone Content Engine, enter the no dns-cache size global configuration command.
ContentEngine(config)# no dns-cache size
Configuring Persistent Connections
Content Engines by default use persistent connections to the server for improving performance. With ACNS 5.0.7 software, the rule action no-persistent-connection global configuration command was added. This command enables you to disable or enable persistent connections for specific domains, source and destination IP addresses, or ports. This is useful when a server does not support persistent connections.
Enabling Persistent Connections
The Content Engine GUI or the CLI can be used to enable and disable persistent connections on standalone Content Engines.
To use the Content Engine GUI to enable persistent connections on a locally deployed Content Engine, choose Caching > Persist. Connect, and use the displayed Persistent Connections window. For more information about how to use the Persistent Connections window to enable persistent connections, click the HELP button in the window.
To use the Content Engine CLI to enable persistent connections on standalone Content Engines, use the http persistent-connections global configuration command.
ContentEngine(config)# http persistent-connections [all|client-only|server-only| timeout seconds]To configure the number of seconds that the Content Engine should wait for a connection response before it times out, use the timeout option.
Table 6-14 describes the HTTP persistent connection parameters.
Disabling Persistent Connections
Use the no form of the http persistent-connections [all | client-only | server-only | timeout seconds] global configuration command to disable all persistent connections, client-only persistent connections, or server-only persistent connections.
ContentEngine(config)# no http persistent-connections [all|client-only|server-only| timeout seconds]Use the rule action no-persistent-connection global configuration command to disable specific persistent connections to specific domains, IP addresses, or ports:
ContentEngine(config)# rule action no-persistent-connection pattern-list list_num [protocol {http|https|ftp}]The rule action no-persistent-connection global configuration command has the following options:
•
•
•
You can specify the criteria for disabling persistent connections by creating a pattern list using one or more of the following supported patterns:
•
•
•
•
•
•
•
•
Table 6-15 describes the syntax for the rule action no-persistent-connection command.
The following example disables a persistent connection for the domain mywebsite.com, based on a pattern in pattern list 10.
ContentEngine(config)# rule action no-persistent-connection server-only pattern-list 10WARNING: rule action no-persistent-connection will affect end-to-end NTLM authenticationto these serversContentEngine(config)#ContentEngine# show rule allRules Template Configuration----------------------------Rule Processing EnabledActions :rule action no-persistent-connection server-only pattern-list 100 protocol allPattern-Lists :rule pattern-list 100 domain mywebsite.comContentEngine#For more information about using the Rules Template feature to configure rules for standalone Content Engines, see "Configuring the Rules Template on Standalone Content Engines."
Configuring Healing Mode for Content Engine Clusters
Healing mode allows a newly added Content Engine to query and obtain cache objects from all other Content Engines in the Content Engine cluster on a cache miss. If the object is not found in the cluster, the Content Engine processes the request through the outgoing proxy or origin server. The Content Engine in healing mode is called a "healing client." The Content Engines in the Content Engine cluster that respond to healing client requests are called "healing servers."
When a Content Engine is added to an existing Content Engine cluster running WCCP Version 2, it can receive requests for content that was formerly served by another Content Engine in the Content Engine cluster. This event is termed a "near-miss," because if the request had been sent to the former Content Engine, it would have been a cache hit. A near-miss lowers the overall cache hit rate of the Content Engine cluster.
Note
To allow a Content Engine in a Content Engine farm to query and obtain cache objects from other Content Engines in the cluster, you must enable healing mode on the Content Engine, using the Content Engine GUI or CLI to enable healing mode on a standalone Content Engine.
To configure the clustering parameters (the parameters related to WCCP service clusters) from the Content Engine GUI, choose WCCP > Clustering. Use the Clustering window to specify these parameters for this Content Engine. For more information about how to use the Clustering window to specify these parameters, click the HELP button in the window.
To use the Content Engine CLI to enable healing mode on standalone Content Engines, use the http cluster global configuration command.
http cluster {heal-port number | http-port number | max-delay seconds | misses number}
Table 6-16 describes the http cluster command parameters.
Use the http cluster http-port global configuration command to specify the port number over which requests from the healing Content Engine (healing client) are sent to the healing servers (other Content Engines in the cluster). The default port number is port 80. If you choose to configure a port other than port 80, make sure that it matches the port that was specified on the healing servers in the cluster, using the http proxy incoming global configuration command. Otherwise, the healing client is not able to retrieve objects from the healing servers.
Use the http cluster heal-port global configuration command to specify the port number over which the healing client sends healing queries and the healing server sends healing responses. The default port number is 14333. If a port other than the default is configured, make sure that all Content Engines in the cluster use the same port.
Use the http cluster misses global configuration command to specify the maximum number of misses that the healing Content Engine can receive from the cluster from the last healing mode hit response until the healing process is disabled. The default is 0 misses.
After a WCCP bucket redistribution, the Content Engine will try to populate its cache from other Content Engines on every cache miss. You can configure the maximum number of seconds a Content Engine should wait for a response from its neighbors before retrieving the object itself. The default is 0 seconds. Use the http cluster max-delay global configuration command to specify the maximum time in seconds that a healing Content Engine waits for a healing response from the cluster before considering the healing request a miss.
To enable the healing client, you should, at the least, configure the max-delay and misses options. The default port number for http-port is 80. If you use the default port, you do not have to configure http-port. The default port number for heal-port is 14333.
The following example enables the healing mode feature by setting the HTTP port for forwarding HTTP requests to a healing server, setting the maximum delay to wait for a response from the cluster in seconds before considering the healing request a miss, and setting the maximum number of misses that the healing Content Engine (healing client) can receive from the cluster before healing mode is disabled at the healing client.
ContentEngine(config)# http cluster http-port 8080ContentEngine(config)# http cluster max-delay 5ContentEngine(config)# http cluster misses 5To disable the healing client, you should, at the least, configure either the misses or max-delay option to 0, or you can use the no form of the http cluster misses and http cluster max-delay global configuration commands:
ContentEngine(config)# no http cluster missesContentEngine(config)# no http cluster max-delayConfiguring the Internet Cache Protocol for Content Engine Clusters
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 cluster (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 Content Engines beyond a single unit, history has shown ICP to be a poor way of scaling a Content Engine clustering solution. In fact, because of the way that traffic is currently directed toward a transparent network Content Engine cluster, the requirement for ICP is all but negated for the majority of Content Engine deployments.
The ICPv2 protocol is documented in two standards documents:
•
•
Note
The following example shows how to use the Content Engine CLI to restrict the ICP parent and sibling to specific domain sets:
ContentEngine(config)# icp client add-remote-server 10.1.1.1 parent icp-port 3130 http-port 3128 domain_x.com domain_y.com domain_z.comContentEngine(config)# icp client add-remote-server 10.1.1.1 sibling icp-port 3130 http-port 3128 domain_a.com domain_b.com domain_c.comContentEngine(config)# icp client enableContentEngine(config)#You can use the Content Engine CLI or GUI to configure ICP on a standalone Content Engine that is part of a cache cluster, as described in the following sections:
•
•
Configuring Standalone Content Engines as ICP Clients
You can configure your Content Engine cluster to generate ICP queries before retrieving requested objects from the Internet using ICP client functionality. With ICP, you can configure parent and sibling Content Engines in a caching hierarchy. ICP parents are essentially one step higher than ICP siblings in a hierarchy of Content Engines.
You can configure a standalone Content Engine to be either a parent or a sibling.
•
•
You can use the Content Engine CLI or GUI to configure a standalone Content Engine as an ICP client.
•
•
Table 6-17 describes the parameters of the icp client global configuration command.
The following example shows how to use the Content Engine CLI to restrict ICP parent and sibling to specific domain sets.
ContentEngine(config)# icp client add-remote-server 172.16.0.0 parent icp-port 3130 http-port 3128 domain_x.com domain_y.com domain_z.comContentEngine(config)# icp client add-remote-server 172.16.0.0 sibling icp-port 3130 http-port 3128 domain_a.com domain_b.com domain_c.comContentEngine(config)# icp client enableIcp Client startedConfiguring Standalone Content Engines as ICP Servers
You can also configure a standalone 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.
You can use the Content Engine GUI or the CLI to configure a standalone Content Engine as an ICP server.
•
•
Table 6-18 describes the parameters for the icp server global configuration command.
