-
Cisco ACNS Software Caching and Streaming Configuration Guide, Release 5.1
-
Index
-
Title Page
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Content Engine Configuration Overview
-
Chapter 4: Transparent Caching
-
Chapter 5: Proxy-Style Caching
-
Chapter 6: Reverse Proxy Caching
-
Chapter 7: Configuring Login Authentication and Authorization
-
Chapter 8: Configuring Content Authentication and Authorization
-
Chapter 9: Configuring a Primary Proxy Server
-
Chapter 10: Configuring Caching Protocols
-
Chapter 11: Configuring Content Service Protocols
-
Chapter 12: Configuring Streaming Media Services
-
Chapter 13: Configuring URL Filtering
-
Chapter 14: Configuring the Rules Template
-
Chapter 15: Creating and Managing IP Access Control Lists
-
Chapter 16: Configuring TCP Stack Parameters
-
Chapter 17: Monitoring and Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Web Cache Communication Protocol Version 1
-
Appendix C: Web Cache Communication Protocol Version 2
-
Table Of Contents
HTTP Transparent and Proxy Caching
HTTPS Transparent and Proxy Caching
Understanding Transparent HTTPS Caching
Configuring Browser Autoconfiguration
FTP Proxy Configuration Examples
Proxy-Style Caching
This chapter explains nontransparent, or proxy-style, caching and presents configuration examples relevant to proxy-style caching with the Content Engine with ACNS software installed on it.
This chapter contains the following sections:
•
HTTP Transparent and Proxy Caching
•
•
All of the features outlined in this chapter are associated with Content Engines operating in nontransparent mode. In this mode, end user web browsers need to be explicitly configured to point to the IP address or host name of the Cisco Content Engine, and there is no need for additional hardware such as Layer 4 switches or WCCP-enabled routers to intercept user requests, as in transparent caching. Customers are normally interested in deploying transparent network caching, but some customers may have a legacy requirement for a nontransparent cache. For more information on transparent caching configurations with the Content Engine, see "Transparent Caching."
Note
Proxy Mode Operation
As Figure 5-1 illustrates, the Content Engine in proxy mode caches content as follows.
1.
2.
a.
b.
3.
4.
Figure 5-1 Web Caching with the Content Engine in Proxy Mode
Note
A proxy-style request arrives with the same destination IP address as the Content Engine; it has been specifically routed to the Content Engine by the client. The Content Engine supports up to eight incoming ports each for FTP, HTTPS, HTTP, MMS, and RTSP proxy modes. The incoming proxy ports can be the same ports that are used by transparent mode services. The incoming proxy ports can be changed without stopping any WCCP services running on the Content Engine or on other Content Engines in the Content Engine farm.
In proxy mode, the Content Engine services any protocols for which it has been configured. The supported protocols are HTTP, HTTPS, FTP, MMS, and RTSP. If the Content Engine is not configured to support a received protocol, the proxy server returns an error. For example, if port 8080 is configured to run an HTTP and HTTPS proxy service, an FTP request coming to this port is rejected.
TCP ports reserved for system or network services should not be used for proxying services in transparent mode or in proxy mode (for example, DNS or FTP). If more than eight ports for a protocol are required, the administrator can configure multiple dynamic WCCP services. Intercepted FTP, HTTP, and HTTPS requests addressed to other proxy servers (received on transparent mode ports) are serviced according to the proxy-protocols transparent command parameters.
HTTP Proxy Caching
The Content Engine accepts proxy-style requests in nontransparent mode from a web browser when the incoming proxy ports are configured with the http proxy incoming ports option. Up to eight incoming proxy ports can be specified on a single command line or on multiple command lines.
To configure the Content Engine to direct all HTTP miss traffic to a parent cache (without using the Internet Cache Protocol [ICP] or WCCP), use the http proxy outgoing host ip-address port primary option, where host is the system name or IP address of the outgoing proxy server, and port is the port number designated by the outgoing (upstream) server to accept proxy requests. Use the primary option to set this host as the primary proxy. See the "Designating a Primary Proxy Server" section for more information on the http proxy outgoing command.
HTTP Transparent and Proxy Caching
Certain scenarios involve the deployment of a Content Engine in proxy mode at company headquarters and a Content Engine in transparent mode at remote locations in branch offices. In these scenarios, if a cache miss occurs at the remote Content Engine, company policy requires that the request be routed to the Content Engine at headquarters.
When an HTTP request intended for the Content Engine acting as a proxy server is intercepted by the Content Engine in transparent mode at the remote location and a cache miss occurs, the Content Engine forwards the request to the intended proxy server if the proxy-protocols transparent original-proxy command was entered. If this command was not entered, then the Content Engine forwards the request to the origin server where the initial HTTP request was made. See the "Configuring HTTP and HTTPS Outgoing Proxy Exclusion Settings" section for information on how to use this command.
SSL Tunneling
The SSL tunneling protocol allows a proxy server to act as a tunnel between the end user and the origin server. The client asks for an SSL tunnel through an HTTP request. This allows the Content Engine to service CONNECT method requests in the form https://url for tunneling SSL over HTTP.
Tip
HTTPS Transparent and Proxy Caching
The ACNS 5.1 software supports HTTPS in the following two scenarios:
•
•
In both cases the Content Engine creates a connection to the origin server (directly or through another proxy server) and allows the web client and origin server to set up an SSL tunnel through the Content Engine.
Note
HTTPS Proxy Features
Table 5-1 describes the ACNS CLI commands associated with a particular HTTPS proxy feature. The order in which the CLI commands are entered is not important.
The Content Engine acting as an HTTPS proxy server supports up to eight ports. It can share the ports with transparent-mode services and with HTTP. In proxy mode, the Content Engine accepts and services the HTTPS requests on the ports specified with the https proxy incoming command. All HTTPS requests on other proxy-mode ports are rejected in accordance with the error-handling settings on the Content Engine. In transparent mode, all HTTPS proxy-style requests intended for another HTTPS proxy server are accepted. The Content Engine acts on these transparently received requests in accordance with the proxy-protocols transparent command.
When the Content Engine is configured to use an HTTPS outgoing proxy with the https proxy outgoing host command, all incoming HTTPS requests are directed to this outgoing proxy. The proxy-protocols outgoing-proxy exclude command specifies a global proxy exclude domain effective for all proxy server protocols, including HTTPS.
The Content Engine applies the following logic when an outgoing proxy server is configured:
•
•
•
When a Content Engine intercepts a proxy request intended for another proxy server and there is no outgoing proxy configured for HTTPS, and the proxy-protocols transparent default-server command is invoked, the Content Engine addresses the request to the destination server directly and not to the client's intended proxy server. However, if the proxy-protocols transparent reset command is configured on the Content Engine and a cache miss occurs, all transparently intercepted requests sent by clients are returned to the client and requested objects are not delivered.
Content Engine Security
To prevent unwanted access to any destination HTTPS port when a request is going through the Content Engine, use the following command sequence:
no https destination-port allow 443 563
https destination-port deny all
This command sequence denies access to any port above and below 1024. Ports 443 and 563 (the standard HTTPS ports) must be explicitly denied access using the no https destination-port allow 443 563 command.
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, the connection to port xxx is denied. This configuration is valid either in the transparent deployment scenario, in which requests are redirected to the Content Engine, or in HTTPS proxy server mode, when the user makes the requests directly to the Content Engine.
HTTPS Statistics Reporting
Only connection statistics are reported. Because requests and responses are sent through the secure tunnel, the Content Engine is not able to identify the number of requests sent, or the number of bytes per request. Thus, the request and transaction per second (TPS) statistics are not available for HTTPS.
HTTPS Transaction Logging
The Content Engine logs HTTPS transactions in the transaction log in accordance with Squid syntax. One log entry is made for each HTTPS connection, though many transactions are performed per connection. The Content Engine is not aware of objects conveyed through the SSL tunnel, only the HTTPS server name.
HTTPS TCP Keepalives
When no keepalive messages are sent by the Content Engine to the clients and to the edge Content Engines, the connection is closed. In ACNS software, Release 5.1, the ACNS system administrator can force the Content Engine to send keepalive probes using the https tcp-rw-timeout global configuration command. When the HTTPS TCP keepalive feature is enabled, the Content Engine sends TCP keepalives on idle HTTPS TCP connections using keepalive configuration parameters such as TCP keepalive timeout, TCP keepalive probe count, and TCP keepalive probe interval.
The https tcp-rw-timeout timeout command allows administrators to configure a maximum read/write timeout of 3600 seconds; that is, HTTPS keepalives are sent for the specified period. For HTTPS connections, the default timeout value is 5 minutes.
Understanding Transparent HTTPS Caching
Transparent HTTPS caching using SSL works as follows:
1.
2.
3.
4.
5.
6.
7.
Tip
Table 5-2 describes the ACNS software CLI commands that are related to transparent HTTPS caching.
.
Examples of HTTPS Caching
In this example, the Content Engine is configured as an HTTPS proxy server, and accepts HTTPS requests on port 8081. Only a single port is supported in the HTTPS protocol.
ContentEngine(config)# https proxy incoming 8081In this example, the Content Engine is configured to forward HTTPS requests to an outgoing proxy server (10.1.1.1) on port 8880.
ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880In this example, a domain name is excluded from being forwarded to an outgoing proxy server.
ContentEngine(config)# proxy-protocols outgoing-proxy exclude cruzio.comContentEngine(config)# proxy-protocols transparent default-serverIn this example, the show https all command is used to display all HTTPS-related information residing on the local Content Engine.
ContentEngine# show https allIncoming HTTPS proxy:Incoming Proxy-Mode:Not servicing incoming proxy mode connections.Outgoing HTTPS proxy:Not using outgoing proxy mode.Destination port restrictions:Allow 443 563HTTPS caching certificate information:HTTPS caching certificate group information:HTTPS caching private key information:Display all https server caching information:ContentEngine#Configuring Browser Autoconfiguration
ACNS 5.x software provides support for proxy automatic configuration files (.pac files). A browser obtains proxy IP address and port configuration information from the proxy automatic configuration file when the browser's autoconfiguration URL field is configured with the Content Engine IP address, incoming port number, file directory, and .pac filename.
The proxy-auto-config download EXEC command downloads an automatic configuration file from an FTP server to the present working directory of the Content Engine. To enable the proxy automatic configuration file feature, enter the proxy-auto-config enable global configuration command. Each time you download a new automatic configuration file to the Content Engine, enter a no proxy-auto-config enable and proxy-auto-config enable command.
Note
The autoconfiguration feature is supported by the Microsoft Internet Explorer and Netscape browsers. The browser must be manually configured for automatic proxy configuration.
This example demonstrates how to download an automatic configuration file from an FTP server to the Content Engine:
ContentEngine# proxy-auto-config download 172.16.10.10 remotedirname theproxyfile.pacThis example enables browser autoconfiguration on the Content Engine:
ContentEngine(config)# proxy-auto-config enableThis example demonstrates the URL syntax to enter in the browser's automatic proxy configuration
URL field:http://ContentEngine-IPaddress:portnumber/theproxyfile.pac
Tip
FTP Proxy Caching
In the ACNS 5.1 software release, the Content Engine supports the following types of FTP caching:
•
•
FTP-Over-HTTP Caching
FTP proxy caching on a Content Engine refers to the ability to service FTP-over-HTTP requests. The transport between the web browser and cache is over HTTP, and the cache initiates an FTP transfer to the origin FTP server.
Tip
The ftp proxy command enables the Content Engine to operate in environments where WCCP is not enabled, or where client browsers have previously been configured to use a legacy FTP proxy server.
The ftp proxy incoming port option specifies a port number used by the proxy server to receive requests. This number can range from 1 to 65535. A maximum of eight incoming proxy ports can be configured. You can share these incoming proxy ports with transparent-mode services and also with the other proxy-mode protocols supported by the Content Engine, such as HTTP and HTTPS. The ftp proxy incoming port option is disabled by default.
Note
The Content Engine accepts FTP requests when URLs specify the FTP protocol (for example, GET ftp://ftp.cisco.com/pub/cao/READM). 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.
The Content Engine caches both the FTP file objects and directory listings in the cache file system (cfs). The Content Engine transforms the regular directory listings from the FTP server into HTML, with links that the client users can point to and click to download files.
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 Content Engine can apply the Rules Template to FTP requests based on server name, domain name, server IP address and port, client IP address, and URL.
The Content Engine logs FTP transactions in the transaction log, in accordance with Squid syntax.
FTP and Caching
ACNS software, Release 5.0 supports proxying and caching of FTP URL client requests using proxy-mode HTTP requests when URLs specify the FTP protocol (for example, ftp://ftp.mycompany.com/ftpdir/ftp_file). For these requests, the client uses HTTP as the transport protocol with the Content Engine, whereas the Content Engine uses FTP with the FTP server.
FTP over HTTP allows end users to use their web browsers to access files (to send and receive files) on remote FTP servers. For instance, the following is an example of an FTP over HTTP request that allows the end user to access public files from an FTP server:
ftp://ftp.funet.fi/pub/cbm/crossplatform/converters/unix/
ACNS software, Release 5.1 supports FTP requests from clients that are sent in the native FTP protocol, as well as those sent using HTTP. Because a typical use of FTP is to help with the distribution of application software, allowing native FTP enhances FTP proxy protocol requests while providing caching services for these requests.
The FTP proxy supports passive and active mode for fetching files and directories. Passive mode is the default FTP mode. The Content Engine automatically changes to active mode if passive mode is not supported by the FTP server. If the ftp proxy active-mode enable command is configured, FTP first attempts to fetch the file in active mode. If active mode fails, FTP attempts to fetch the file again in passive mode.
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.
The Content Engine caches FTP traffic only when the client uses the Content Engine as a proxy server for FTP requests. All FTP traffic that was sent directly from the web client to an FTP server, if transparently intercepted by the Content Engine, is treated as non-HTTP traffic.
The FTP proxy supports up to eight incoming ports. It can share the ports with transparent-mode services and also with the other proxy-mode protocols supported by the Content Engine, such as HTTP and HTTPS. In proxy mode, the Content Engine accepts and services the FTP requests only on the ports configured for FTP proxy. All the FTP requests on other proxy mode ports are rejected in accordance with the error-handling settings on the Content Engine.
The Content Engine can apply the Rules Template toFTP requests based on server name, domain name, server IP address and port, client IP address, and URL.
The Content Engine logs FTP transactions in the transaction log, in accordance with the Squid syntax. When URL tracking is enabled, the Content Engine logs FTP transaction information to the syslog. The syslog entries are prefixed with <ftp>.
FTP Proxy Configuration Examples
This section provides some examples of how to use the CLI to configure a Content Engine as an FTP proxy.
This example configures an incoming FTP proxy 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 9090This example removes one FTP proxy port from the list entered in the previous example. Ports 8080 and 9090 remain FTP proxy ports.
ContentEngine(config)# no ftp proxy incoming 8081This example disables all the FTP proxy ports.
ContentEngine(config)# no ftp proxy incomingThis example configures an upstream FTP proxy with the IP address 172.16.76.76 on port 8888.
ContentEngine(config)# ftp proxy outgoing host 172.16.76.76 8888This example specifies an anonymous password string for the Content Engine to use when contacting FTP servers. The default password string is anonymous@hostname.
ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostnameThis example configures the maximum size in kilobytes of an FTP object that the Content Engine will cache. By default, the maximum size of a cacheable object is not limited.
ContentEngine(config)# ftp object max-size 15000This example forces the Content Engine to revalidate all objects for every FTP request.
ContentEngine(config)# ftp reval-each-request allThis example configures a maximum Time To Live of 3 days in the cache for directory listing objects and file objects.
ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3The following examples demonstrate the use of native FTP with the Content Engine.
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: jdoe): jdoe331 Password required for jdoe.Password:230 User jdoelogged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> pwd257 "/home/jdoe" 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#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:jdoe): 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> get(remote-file) /tmp/test.c(local-file) test.clocal: test.c remote: /tmp/test.c227 Entering Passive Mode (128,107,193,244,96,191)550 /tmp/test.c: No such file or directory.ftp>ContentEngine#
Note
