-
Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.5
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Deployment Scenarios for Standalone Content Engines
-
Chapter 4: Getting Started
-
Chapter 5: Performing Other Basic Tasks for Standalone Content Engines
-
Chapter 6: Configuring Transparent Redirection for Standalone Content Engines
-
Chapter 7: Configuring Conventional Caching Services for Standalone Content Engines
-
Chapter 8: Configuring RealMedia Services on Standalone Content Engines
-
Chapter 9: Configuring WMT Streaming Media Services on Standalone Content Engines
-
Chapter 10: Configuring Content Authentication and Authorization on Standalone Content Engines
-
Chapter 11: Configuring Content Preloading and URL Filtering on Standalone Content Engines
-
Chapter 12: Configuring ICAP on Standalone Content Engines
-
Chapter 13: Configuring the Rules Template on Standalone Content Engines
-
Chapter 14: Configuring Primary and Backup Proxy Servers for Standalone Content Engines
-
Chapter 15: Configuring Advanced Transparent Caching Features on Standalone Content Engines
-
Chapter 16: Updated Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines
-
Chapter 17: Configuring Administrative Login Authentication and Authorization on Standalone Content Engines
-
Chapter 18: Configuring AAA Accounting on Standalone Content Engines
-
Chapter 19: Creating and Managing IP Access Control Lists for Standalone Content Engines
-
Chapter 20: Viewing and Modifying TCP Stack Parameters on Standalone Content Engines
-
Chapter 21: Monitoring Standalone Content Engines and Transactions
-
Chapter 22: Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Reference Material for Standalone Content Engine Deployments
-
Index
-
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
Configuring Nontransparent FTP-over-HTTP Caching on Standalone Content Engines
Configuring FTP Native Caching for Standalone Content Engines
About IP ACL Support for FTP Native Requests
Configuring Nontransparent FTP Native Caching
Configuring Transparent FTP Native Caching
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 Standalone Content Engines to Send out
TCP KeepalivesConfiguring Persistent Connections on Standalone Content Engine
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 [FTP-over-HTTP caching and native FTP caching], 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. Figure 7-1 provides a detailed view on how to configure conventional caching services for 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 on page 4-10.
For information about how to configure media caching services (WMT and RTSP caching and streaming services) in a locally managed deployment, see the following chapters:
•
•
Figure 7-1 Detailed View of Configuring Conventional Caching Services for Standalone Content Engines
Table 7-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 7-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 on page 4-35.
For WCCP routing, see the "Configuring Standalone Content Engines for WCCP Transparent Redirection" section on page 6-9.
For Layer 4 switching, see the "Configuring Layer 4 Switching as a Redirection Method" section on page 6-50.
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 on page 4-42.•
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 on page 4-37.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.
Configuring the TFTP Server and Gateway for Standalone Content Engines
7.
Configuring Standalone Content Engines to Send out TCP Keepalives
8.
9.
cache clusters.Configuring the Internet Cache Protocol for Content Engine Clusters
10.
on the Content Engine.Chapter 9, "Configuring WMT Streaming Media Services on Standalone Content Engines"
11.
on the Content Engine.Chapter 8, "Configuring RealMedia 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 Chapter 10, "Configuring Content Authentication and Authorization on Standalone Content Engines."13.
•
•
FTP requests, as described in Chapter 11, "Configuring Content Preloading and URL Filtering on Standalone Content Engines."14.
Internet Content Adaptation Protocol
(ICAP) server.•
•
requests, as described in Chapter 12, "Configuring ICAP on Standalone Content Engines."15.
for processing content requests.•
•
WMT, and RTSP requests, as described in Chapter 13, "Configuring the Rules Template on Standalone Content Engines."16.
(for example, traffic bypass, overload bypass,
flow protection, and IP spoofing).Chapter 15, "Configuring Advanced Transparent Caching Features on Standalone Content Engines"
17.
standalone Content Engine.Chapter 16, "Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines"
18.
services on this standalone Content Engine.Chapter 16, "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.20.
for system accounting with TACACS+.Chapter 18, "Configuring AAA Accounting on Standalone Content Engines"
21.
on this standalone Content Engine.Chapter 19, "Creating and Managing IP Access Control Lists for Standalone Content Engines"
22.
for this standalone Content Engine.Chapter 20, "Viewing and Modifying TCP Stack Parameters on Standalone Content Engines"
23.
for this standalone Content Engine.24.
with SNMP or the ACNS software alarms.Chapter 21, "Monitoring Standalone Content Engines and Transactions"
25.
such as traceroute or ping.Chapter 21, "Monitoring Standalone Content Engines and Transactions"
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. The 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 the ACNS 5.1 software and earlier releases, the proxying of chunked transfer encoded (CTE) objects was supported; however, the caching of these objects was not supported.
In the ACNS 5.2 software and later releases, 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. 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 7-2 lists the HTTP caching services that are supported by Content Engines that are running the ACNS 5.2.1 software and later releases. The type of services supported varies based on the method used to route the HTTP request to the Content Engine.
Table 7-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 the ACNS 5.1 software and earlier releases, a maximum of eight active WCCP services were supported by a WCCP Version 2 router and a Content Engine. In the ACNS 5.2.1 software and later releases, up to 25 active WCCP Version 2 services are supported. In ACNS 5.2.1 software release, only 17 WCCP services were defined. In the ACNS 5.3.1 software release, 18 WCCP services are defined.
See Table B-3 for a list of supported 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 on page 4-35.
Step 2
ContentEngine(config)# http proxy incoming ports
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, keep the following important points in mind:
•
•
•
•
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 7-3 lists the valid range of values.
Table 7-3 Time To Live Range of Values for HTTP Freshness
Days
1-1825
Hours
1-43800
Minutes
1-2628000
Seconds
1-157680000
Step 4
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 7-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 the ACNS 5.2 software and later releases.
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 the ACNS 5.2.1 software and later releases. 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).
In the following example, the Content Engine is configured to use the 407 header when asking end users for their authentication credentials (user ID and password):
ContentEngine(config)# http authentication header 407
Note
Specifying a Reauthentication Interval
In the ACNS 5.1 software, an inactivity timer was used to determine when the client browser was prompted to reenter authentication credentials after being initially authenticated. This inactivity timer is configured with the http authentication cache timeout global configuration command. By default, the inactivity timeout period was 8 hours. This meant that as long as someone continued to use the client browser after the legitimate authenticated user was initially authenticated, the client was not forced to reenter that person's authentication credentials.
In the ACNS 5.2.1 software and later releases, you can specify an absolute TTL for HTTP authentication cache entries for increased security in a shared workstation environment. This ability to specify an absolute TTL timeout adds security to the inactivity timeout mechanism for content that is served through the Content Engine. When the absolute TTL period has expired, the client browser is forced to reauthenticate itself, and the user must enter valid credentials.
A security vulnerability exists in a shared workstation environment that is using WCCP-enabled router redirection mode with any authentication method, or proxy redirection mode and the NTLM authentication method. In these cases, the Content Engine uses the client's IP address as the index into the authentication record kept in the authentication cache, and the Content Engine can therefore authenticate users who have not presented valid credentials of their own if a different user using the same workstation has previously presented valid credentials that are cached in the authentication cache. To provide additional security in this situation, you can configure the absolute TTL for HTTP authentication cache entries; this will specify the absolute time during which an authentication cache entry is valid in the cache. If a cache lookup occurs on an entry and its configured TTL time is exceeded, then the entry is deleted and the Content Engine will query the user for credentials.
To support this feature, the ttl option was added to the http authentication cache global configuration command.
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 cacheIn 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). The workstation logon credentials of the nonshared 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.
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
To display the current configuration of the HTTP authentication cache on a standalone Content Engine, enter the show http authentication EXEC command.
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. To change this default policy, use the http cache-authenticated global configuration command.
http cache-authenticated {all | basic | ntlm}
Table 7-5 describes these command parameters.
Enable caching of both basic and NTLM authenticated content on the Content Engine:
ContentEngine(config)# http cache-authenticated allVerify 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.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 7-6 describes the command parameters.
In the following example, the standard 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 2The Content Engine must be running WCCP Version 2 to support any of the WCCP services listed in Table B-3 other than the web-cache service (service 0). If you enable WCCP Version 1 as opposed to Version 2 on this Content Engine, only a single WCCP router can be configured to support the only supported service (the standard web-cache service). If you select Version 2, up to eight WCCP routers can be specified to support a particular WCCP service, and all WCCP services are supported.
Tip
Step 2
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 3
ContentEngine(config)# wccp web-cache 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 web-cacheStep 8
Router(config)# interface type numberIn the following example, Ethernet interface 0/1 on the router is configured to run the standard web-cache service:
Router(config)# interface ethernet 0/1Step 9
Router(config-if)# ip wccp web-cache redirect in
