Cache Software Feature Configurations

Table 3-1 lists the principal features of Cache software, Release 3.1, with the associated command-line interface (CLI) commands. Release notes may contain updates to this information.

Table 3-1: Cisco Cache Software Release 3.1 Feature Set

Cisco Cache Software, Release 3.1 Feature	Related CLI Commands	Section and Page
Cache hierarchy features
Parent proxy failover	http proxy outgoing	Parent Proxy Failover
Outgoing proxy	http proxy outgoing proxy-protocols
ICP	icp
Cache parameter settings
Cache freshness	http min-ttl http max-ttl http age-multiplier http reval-each-request	Cache Freshness
Caching of binary content with cookies	http cache-cookies	Caching of Binary Content with Cookies
Object size capping	http object	Object Size Capping
Selective abort of object downloading on client-abort (also called "quick_abort")	http cache-on-abort
Content preloading	pre-load pre-load force	Content Preloading
Logging
Squid-style transaction logging	transaction-logs
Sanitized transaction logs	transaction-logs sanitize
Pushing of log files	transaction-logs export
Management features
Administration from GUI	gui-server
Administration from CLI	trusted-host user
Boot from Flash memory	copy install reload write
SNMP agent (MIB II & CE-MIB support)	snmp-server community
SNMP traps	snmp-server enable traps snmp-server host
Syslog	logging
NTP time syncing	ntp
Proxy-style caching (nontransparent operation)
HTTP proxy caching	http proxy incoming
FTP proxy caching	ftp proxy incoming
SSL tunneling	https proxy incoming
RealProxy 8.0 support	disk mediafs rtsp proxy wccp media-cache	RealProxy 8.0 Support
Rules Template	rule	Rules Template
Transparent caching
Transparent caching with the Cisco CSS11000 series switch	http l4-switch enable
Transparency through WCCP	wccp
Accelerated WCCP Layer 2 support	wccp custom-web-cache wccp media-cache wccp reverse-proxy wccp service-number wccp web-cache	Accelerated WCCP Support
Authentication bypass	bypass auth-traffic bypass timer
Overload bypass	bypass load
Static bypass	bypass static
Multiport transparent redirection	proxy-protocols wccp port-list wccp service-number	Multiport Transparent Redirection
WCCP flow protection	wccp slow-start wccp flow-redirect
TCP stack parameters
User-configurable TCP parameters	tcp
TCP-over-satellite extensions	tcp client-satellite tcp server-satellite
Miscellaneous features
Embed client information in HTTP headers	http append
Microsoft NT LAN Manager (NTLM) authentication transparency	http authenticate-strip-ntlm	Microsoft NT LAN Manager Authentication Transparency
Multiple network interface support	interface fastethernet interface gigabitethernet	Multiple Network Interfaces

The following features were added in the Cisco Cache software, Release 3.1 (from Release 3.0):

The Cache software can be tuned to balance HTTP and FTP object freshness with cache hit rate. The Cache software default parameters are weighted to ensure fresh content over maximizing the cache hit rate (to avoid the undesirable scenario of increasing the cache hit rate by serving stale content).

Table 3-2 explains the cache freshness features.

Table 3-2: Release 3.1 Cache Freshness Settings

Configurable Cache Freshness Feature	Function
Minimum Time to Live Maximum Time to Live	Limits duration of objects in the cache.
Age multiplier	Determines at what percentage of an object's maximum Time To Live the Cache software issues an if-modified-since (IMS) to the origin web server to validate the freshness of the object.
Revaluate each request	Forces the Cache software to revalidate all requests to the origin web server using an IMS request. The reval-each-request option enables the Content Engine to revalidate all objects requested from the cache, text objects only, or none at all.
Serve-IMS	Controls the ability of the cache to answer authoritatively on receiving an IMS request from the web browser.

Minimum and Maximum Time To Live Settings

The minimum and maximum Time To Live (TTL) settings permit the administrator to limit the duration of HTTP and FTP objects in the cache. By default, HTTP cachable objects are kept for 5 minutes minimum and 3 to 7 days maximum (3 days for text-type objects, 7 days for binary). If an object is marked with expiry information from the web server different from the administrator settings, then the web server values take precedence.

For HTTP and FTP objects, use the http min-ttl and ftp min-ttl global configuration commands to set the minimum Time To Live, and the http max-ttl and ftp max-ttl command to set maximum Time To Live. The command syntax is as follows:

ftp max-ttl days directory-listing dlmax_days file fmax_days

ftp max-ttl hours directory-listing dlmax_hours file fmax_hours

ftp max-ttl minutes directory-listing dlmax_ min file fmax_min

ftp max-ttl seconds directory-listing dlmax_ sec file fmax_sec

ftp min-ttl min_minutes

http max-ttl days text textdays binary bindays

http max-ttl hours text texthours binary binhours

http max-ttl minutes text textminutes binary binminutes

http max-ttl seconds text textseconds binary binseconds

http min-ttl minutes

The following example configures the Cache software to keep HTTP and FTP objects in the cache for a minimum of 10 minutes, and a maximum of 24 hours (1 day).

ContentEngine(config)# http min-ttl 10

ContentEngine(config)# ftp min-ttl 10

ContentEngine(config)# http max-ttl days text 1 binary 1

ContentEngine(config)# ftp max-ttl hours directory-listing 24 file 24

Caching of Binary Content with Cookies

The Cache software can cache binary objects that were served with cookies attached. Use the
http cache-cookies global configuration command to enable this feature.

Object Size Capping

The Cache software can specify the maximum size of an FTP or HTTP object that can be stored in the cache. The maximum size limit for an FTP object is 1,048,576 kilobytes; the maximum HTTP object size is 204,799 kilobytes.

The following example sets the maximum size for an HTTP object as 500 kilobytes, and the maximum FTP object size as 2 megabytes.

ContentEngine(config)# ftp object max-size 2000
ContentEngine(config)# http object max-size 500

Cache Hierarchy Features

Parent Proxy Failover

Note The proxy failover feature supports HTTP only, not HTTPS or FTP.

The http proxy outgoing option can configure up to eight Content Engines as outgoing proxy servers. One outgoing proxy server functions as the primary server to receive and process all cache-miss traffic. If the primary outgoing proxy server fails to respond to the HTTP CONNECT, the server is noted as failed and the requests are redirected to the next outgoing proxy server until one of the proxies services the request. To explicitly designate a proxy as primary, use the http proxy outgoing host hostname primary command. If several hosts are configured with the primary keyword, the last one configured becomes the primary failover host. Failover occurs in the order the proxy servers were configured. If all of the configured proxy servers fail, the Content Engine can optionally redirect HTTP requests to the origin server specified in the HTTP header with the http proxy outgoing origin-server command, If the origin-server option is not enabled, the client receives an error message. Response errors and read errors are returned to the client because it is not possible to detect whether these errors are generated at the origin server or at the proxy.

A background process monitors the state of the proxy servers. A monitoring interval is configured with the http proxy outgoing monitor command. This monitor interval is the interval of time over which the proxy servers are polled. If one of the proxy servers is unavailable, the polling mechanism waits for the connect timeout (300 milliseconds) before polling the next server. The state of the proxy servers can be viewed in syslog NOTICE messages and with the show http proxy command.

Requests with a destination specified in the proxy-protocols outgoing-proxy exclude command bypass the Content Engine, the primary outgoing proxy, and the failover proxies.

When an HTTP request intended for another proxy server is intercepted by the Content Engine in transparent mode, the Content Engine forwards the request to the intended proxy server if the proxy-protocols transparent original-proxy command was entered.

Examples

In this example, the host 10.1.1.1 on port 8088 is designated the primary outgoing proxy server, and host 10.1.1.2 is a backup proxy server.

ContentEngine(config)# http proxy outgoing host 10.1.1.1 8088 primary 

ContentEngine(config)# http proxy outgoing host 10.1.1.2 220

In this example, the Content Engine is configured to redirect requests directly to the origin server if all of the proxy servers fail.

ContentEngine(config)# http proxy outgoing origin-server

In this example, the Content Engine is configured to monitor the proxy servers every 120 seconds.

ContentEngine(config)# http proxy outgoing monitor 120

To disable any of the above commands, use the no version of the command.

Proxy Failover show Commands

ContentEngine# show http proxy Incoming Proxy-Mode: Servicing Proxy mode HTTP connections on ports: 8080 Outgoing Proxy-Mode: Primary proxy server: 172.11.63.150 port 1 Failed Backup proxy servers: 172.11.236.151 port 8005 172.11.236.152 port 123 172.11.236.153 port 65535 Failed 172.11.236.154 port 10 Monitor Interval for Outgoing Proxy Servers is 60 seconds Use of Origin Server upon Proxy Failures is disabled.

Statistics

ContentEngine# show statistics http requests Statistics - Requests Total % of Requests --------------------------------------------------- Total Received Requests: 49103 - Forced Reloads: 109 0.2 Client Errors: 23 0.0 Server Errors: 348 0.7 URL Blocked: 0 0.0 Sent to Outgoing Proxy: 0 0.0 Failures from Outgoing Proxy: 0 0.0 Excluded from Outgoing Proxy: 0 0.0 ICP Client Hits: 0 0.0 ICP Server Hits: 0 0.0 HTTP 0.9 Requests: 2 0.0 HTTP 1.0 Requests: 49101 100.0 HTTP 1.1 Requests: 0 0.0 HTTP Unknown Requests: 0 0.0 Non HTTP Requests: 0 0.0 Non HTTP Responses: 46 0.1 Chunked HTTP Responses: 0 0.0 Http Miss Due To DNS: 0 0.0 Http Deletes Due To DNS: 0 0.0 Objects cached for min ttl: 2674 5. ContentEngine# show statistics http proxy outgoing HTTP Outgoing Proxy Statistics IP PORT ATTEMPTS FAILURES --------------------------------------------------- 172.16.23.150 8000 0 0 172.16.23.151 8080 0 0 172.16.23.152 9000 0 0 172.16.23.153 9001 0 0 172.16.23.154 9005 0 0 Requests when all proxies were failed: 0

Related Commands

proxy-protocols

rule no-proxy

rule use-proxy

show http

show http proxy

show statistics http requests

show statistics http proxy outgoing

Content Preloading

Cisco Cache software, Release 3.1, can read a file of URLs and download the specified content to the Content Engine. This preloading can be scheduled with the pre-load schedule global configuration command, or triggered immediately with the pre-load force EXEC command.

A list file of URLs to be preloaded (URL list) is maintained by the administrator. The URL list must be created on a remote system and transferred to a sysfs volume on the Content Engine. The path of the URL list is specified by the pre-load url-list-file option. The URL list is a list of URLs, each with an optional depth parameter. The depth parameter specifies how many levels down the preloading will be performed. For example: http://www.espn.com 3 would mean download http://www.espn.com and all content three levels deep. If the depth level is not specified, then the CLI-configured depth level is used. The URLs are delimited with a carriage return as follows:

<cr>
. . . 
http://www.cnn.com   3 <cr>
ftp://ftp.lehigh.edu/  2 <cr>
http://www.yahoo.com  <cr>
. . .
<cr>

Use the pre-load schedule command to specify the time intervals at which the preload event executes, or use the pre-load force EXEC command to launch a preload event at any time.

If the content to be preloaded is already in the Content Engine, then the Content Engine revalidates the freshness of the stored copy.

A preload request process (wget) is spawned for every URL in the list. These processes operate concurrently. Use the pre-load concurrent-requests option to configure the maximum number of preload processes to run at the same time. If the number of URLs in the URL list file is less than the number of specified concurrent requests, then the lesser number is active.

All configured HTTP parameters and rules apply to the preloaded objects.

Examples

This example enables the preload feature:

ContentEngine(config)# pre-load enable

This example specifies the path name of the preload URL list file:

ContentEngine(config)# pre-load url-list-file /local1/myurllist

This example specifies the depth level for URL retrieval at 4:

ContentEngine(config)# pre-load depth-default 4

This example creates a filter for the objects to be excluded:

ContentEngine(config)# pre-load no-fetch suffix .mil .su .ca

This example specifies a filter for the domain to be fetched:

ContentEngine(config)# pre-load fetch domain cisco.com

This example specifies that other domains in an HTML page should be traversed (by default, other domains in an HTML page are not traversed):

ContentEngine(config)# pre-load traverse-other-domain

This example specifies the maximum number of concurrent connections:

ContentEngine(config)# pre-load concurrent-requests 5

This example specifies a daily interval for scheduling the preload:

ContentEngine(config)# pre-load schedule every-day start-time 01:00 end-time 02:00

This example specifies an hourly interval for scheduling the preload:

ContentEngine(config)# pre-load schedule every-hour start-time 8 end-time 20

The pre-load schedule every-week option, permits configuring a preload on more than one day of the week. This example specifies a biweekly interval for scheduling the preload:

ContentEngine#(config)# pre-load schedule every-week Sun Wed start-time 01:00 end-time 
06:00

The default start time for the preloading operation is 00:00 (that is, the start of the day). If the end time is not specified, the preload operation is completed after all the objects have been downloaded.

The following are examples of preload-related show commands:

ContentEngine# show statistics pre-load

Statistics of last Preloading operation
---------------------------------------
 
Preloading was initiated by cron.
Preloading started at Sat Feb 10 21:00:01 2001
Preloading ended   at Sun Feb 11 00:45:25 2001
 
Number of invalid entries in URL list file  =          0
Total number of preloaded objects           =      44178
Total number of preloaded bytes             =  895723727 
 
 
ContentEngine# show pre-load

Preloading is enabled
Number of concurrent sessions: 10
Depth level: 3
URL List File: /local1/preload/preload.txt
Preload will not traverse other domains.
 
Fetch Domains:
Fetch Suffix:
Fetch Directory:
No-fetch Domain:
No-Fetch Suffix:
No-Fetch Directory:
Scheduling on:
Sunday
        Start Time: 00:00
        End Time  : Till completion

Microsoft NT LAN Manager Authentication Transparency

The Cache software can strip Microsoft NT LAN Manager (NTLM) authentication headers to allow fallback to a basic-style authentication challenge against Microsoft Internet Information System (IIS) servers.

This feature is designed to allow browsers to authenticate against a Microsoft IIS web server that issues an NTLM-based challenge. NTLM is proprietary and undocumented. Removing the NTLM headers allows the browser to fall back on the basic authentication method. If IIS is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security. Use the http authenticate-strip-ntlm global configuration command to enable this feature.

Multiple Network Interfaces

All Ethernet interfaces on the Content Engine are ready to use. Table 3-3 summarizes the interface allocations for the Cisco Content Engines.

Table 3-3: Ethernet Interface Distribution by Content Engine Model

Platform Operating with Cache Software 3.1	Number and Type of Network Interfaces
Content Engine 500 Series	2 10/100 Ethernet interfaces (RJ-45connectors)
Content Engine 7300 Series	4 10/100 Ethernet interfaces (RJ-45 connectors) 2 Gigabit Ethernet interfaces (SC connectors)

Multiple network interfaces can be used in the following contexts:

Creating a redundant connection for traffic interception and redirection
Load balancing if aggregate traffic load exceeds the physical speed of a single port
Out-of-band network interface for intercache communication
Out-of-band access for management of the Content Engine

In deploying a transparent network cache (using WCCP, a Content Services CSS11000 series switch, or a Layer 4 switch), incoming requests can be load balanced across multiple interfaces.

Outbound connections from the cache can be load balanced using Hot Router Standby Protocol (HSRP) or Virtual Router Redundancy Protocol (VRRP) on the router or switch to which the default route points.

A Content Engine cannot route packets between its interfaces.

Subinterfaces through IEEE standard 802.1Q or Inter-Switch Link (ISL) VLANs are not supported.

EtherChannel and GigabitEtherChannel are not supported.

RealProxy 8.0 Support

Note The RealNetworks, Inc. RealProxy product is licensed software. To activate the RealProxy, you must have a license keyword, which is supplied on a certificate shipped with the Content Engine. If you are downloading the Release 3.1 software, you can purchase a RealProxy license though the Cisco.com website.

The RealProxy software from RealNetworks, Inc., included as a software option to Release 3.1, supports both stream splitting (distributing "live" feeds) and streaming media caching (on-demand content) in the Real-Time Streaming Protocol [RTSP]-based format.

When performing stream splitting, the RealProxy accepts a "live" stream from a RealServer and re-serves the stream to multiple requesting RealPlayer clients, thus eliminating multiple connections to the RealServer. The RealServer is preconfigured to act as a RealMedia transmitter and the RealProxy is preconfigured to act as a RealMedia receiver.

Streaming media caching provides content on demand. If one user has viewed a cached streaming media file, it can be served to subsequent users without the requirement to connect with the origin server. Live broadcasts are not files and are not cached.

Table 3-4 describes the features and benefits of RealProxy software.

Table 3-4: RealProxy Features and Benefits

RealProxy Feature	Description	Benefits
Proxy for RealPlayer 8.0	The RealProxy makes requests for content on behalf of client RealPlayer users.	Manages traffic inside the firewall by coordinating requests for similar content. Masks end user IP addresses.
Splitting support for live broadcasts	The RealProxy "splits" a single inbound live broadcast feed to multiple client RealPlayers.	Reduces inbound bandwidth usage to a single stream of content during a live event. Improves RealPlayer quality of experience.
Caching of RealSystem G2 and PNM content	The RealProxy caches all proxied streaming media traffic from RealNetworks servers. RealProxy caches content locally after authentication with origin RealNetworks server.	Significantly reduces inbound bandwidth usage by eliminating redundant file transmissions across the network.
Authentication/accounting	The RealProxy authenticates every content request with the origin RealNetworks server before delivering the cached content to the client	Broadcaster retains access to general usage data. Users are appropriately authenticated. End users are guaranteed the freshest content.
Aggregate bandwidth thresholds	Setting thresholds caps inbound and outbound bandwidth to the ReaProxy.	Provides control over aggregate bandwidth usage within the network and prevents stress on mission-critical applications.
Proxy Routing	Ability to tier proxies and manage bandwidth at lower nodes in the network. "Parent" proxies can be chosen based on logical sets of rules on the downstream proxy.	Allows network administrators to proxy route requests, providing an additional level of control.

Configuring the RealProxy Software

The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RealPlayer client software. The redirection of RTSP traffic to the Content Engine media cache is enabled with the Content Engine CLI. The RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy page of the Content Engine management GUI.

Detailed configuration, statistics, and reporting of RealProxy status are obtained through the RealAdministrator GUI. Table 3-5 lists RealProxy-related CLI commands.

Table 3-5: RealProxy-Related CLI Commands

CLI Command	Function
disk manufacture diskname mediafs	Partitions, formats, and mounts an entire disk as a mediafs partition.
disk partition partition partition_size mediafs	Creates a mediafs partition on a disk.
disk prepare diskname mediafs	Partitions and formats an entire disk as a mediafs partition.
disk recover	Creates an swfs partition at disk00/00.
rtsp proxy incoming port	Specifies the port on which to listen for RSTP proxy-style requests.
rtsp proxy l4-switch enable	Enables redirection with a Layer 4 switch, such as a Cisco Content Services 11000 series switch.
rtsp proxy media-real enable	Enables the RealProxy.
rtsp proxy media-real ip-address ipaddress	Specifies the IP address of the RealProxy.
rtsp proxy media-real license-key keyword	Specifies the license keyword to unlock the RealProxy software.
wccp media-cache . . .	Registers the Content Engine for WCCP RTSP redirection services with the router.

Use the rtsp proxy global configuration command to configure the Content Engine to accept redirected RTSP traffic, or to configure the Content Engine as a media proxy to receive RTSP proxy-style requests from RealPlayer clients. RTSP requests not from RealPlayer clients are directed to the specified origin server. The wccp media-cache global configuration command registers the Content Engine with WCCP Version 2-enabled routers that can transparently redirect RTSP traffic to the Content Engine. Streaming media objects are cached in the media file system (mediafs) disk partitions. The RealProxy software is copied to the software file system (swfs) partition as part of the installation procedure. For further information on disk partitions (swfs, mediafs, sysfs, and cfs), see the "Maintaining the Hard Disk Storage" section.

The RTSP proxy redirector listens to port 554 traffic, and if the player is a RealPlayer, it redirects the RTSP request to use the RealProxy for RealMedia traffic. For traffic that it does not support (for instance, QuickTime), the Content Engine bypasses the traffic.

RealProxy software is configured with the RealSystem administrator GUI, accessed from the RealProxy page of the Content Engine management GUI.

Procedure to Enable Transparent RTSP Proxy Service

Requirements

Content Engine running Cache software Release 3.1 or later
RealProxy software installed with mediafs partitions mounted
RealMedia Networks Inc., license key
IP addresses of the RealProxy and routers

Complete the followings steps to enable transparent redirection of RTSP traffic to the RealProxy:

Step 1 On the WCCP Version 2 routers, configure the outbound interfaces to the Internet.

In the following example the outbound interface is the Ethernet 0 device.

router(config)# ip wccp 80

router(config)# interface Ethernet 0

router(interface)# ip wccp 80 redirect out

Step 2 Set the WCCP Version 2 parameters on the Content Engine.

In the following example, the WCCP Version 2-enabled routers have the IP addresses 172.16.25.25 and 172.16.24.24.

ContentEngine(config)# wccp version 2

ContentEngine(config)# wccp router-list 1 172.16.25.25 172.16.24.24

ContentEngine(config)# wccp media-cache router-list-num 1

Step 3 Set the IP address for the RealProxy. Make sure that the IP address of the RealProxy is visible to the RealPlayers that use it.

ContentEngine(config)# rtsp proxy media-real ip-address 172.16.16.16

Step 4 Enter the RealProxy license number.

ContentEngine(config)# rtsp proxy media-real license-key mylicense

Step 5 Enable the RealProxy.

ContentEngine(config)# rtsp proxy media-real enable

Step 6 Save the new configuration.

ContentEngine# copy running-config startup-config

Step 7 Configure the RealProxy parameters with the RealSystem administrator GUI, shown in Figure 3-3.

A RealProxy page has been added to the management GUI. To access the RealSystem administrator, click the Admin button on the RealProxy page. The Admin button is active when the RealProxy software is installed and enabled.

Step 8 Use the following commands to display RealProxy statistics:

ContentEngine# show statistics mediacache real requests

ContentEngine# show statistics mediacache real savings

Note The mediacache real statistics relate only to objects transported over RTSP that were requested by a RealPlayer client. Objects transported over HTTP are counted in the HTTP statistics. Streaming objects requested by other clients or transported over other protocols, bypass the Content Engine.

Procedure to Enable Conventional RTSP Proxy Service

To configure the Content Engine to service RealPlayer clients with the RealProxy on the Cisco Content Engine, perform the following steps:

Step 1 Set the IP address for the RealProxy. Make sure that the IP address of the RealProxy is visible to the RealPlayers that use it.

ContentEngine(config)# rtsp proxy media-real ip-address 172.16.16.16

Step 2 Enter the RealProxy license number shipped with the Content Engine.

ContentEngine(config)# rtsp proxy media-real license-key mylicense

Step 3 Enable the RealProxy.

ContentEngine(config)# rtsp proxy media-real enable

Step 4 Configure the Content Engine to listen for RTSP traffic on a specified port. The default RTSP port is 554.

ContentEngine# rtsp proxy incoming 554

Step 5 Configure RealPlayer clients to use the RealProxy on the Content Engine.

a. Open RealPlayer.

b. Choose View > Preferences from the menu bar.

c. Click the Proxy tab.

d. Click the Use RTSP proxy check box.

e. Enter the IP address of Cisco Content Engine in the Use RTSP proxy address field.

f. Specify the port number that you entered with the Cache software rtsp proxy global configuration CLI command.

g. Click OK.

The RealPlayer configuration is shown in Figure 3-1.

Figure 3-1: RealPlayer Configured to Use Content Engine as Traditional Proxy for RTSP Traffic

RealPlayer is now be able to use the Cisco Content Engine's RealProxy to fetch streaming objects.

For more information on setting up the Real Player, refer to the RealProxy readme "Setting Up RealServer" and "Setting Up RealPlayer" sections at the following URL:

http://service.real.com/help/library/guides/p roxy/readme.htm#5

Step 6 Save the Content Engine configuration to Flash memory.

ContentEngine# copy running-config startup-config

Step 7 Use the following commands to display RealProxy statistics:

ContentEngine# show statistics mediacache real requests

ContentEngine# show statistics mediacache real savings

RealProxy and RealServer Considerations

Disabling RealMedia Caching

To prevent caching of all material from all clients and the RealProxy, complete the following procedure:

Step 1 Access the RealSystem Administrator GUI page by clicking the Admin button on the RealProxy page of the Content Engine management GUI.

Step 2 Choose Configure > Cache.

Step 3 In the Enable Caching field, choose Disabled.

Step 4 Click Apply.

Streaming On-Demand Clips and RealProxy

All on-demand clips are automatically available to the Content Engine. If there is content served by your RealServer that you do not want to be cached, you can mark it as noncachable on a per file or per folder basis.

Unicasting, Splitting, Multicasting, and RealProxy

Live clips are not available to caching software; the RealProxy will still proxy the live broadcasts for clients. RealServer acts as a source for pull splitting, and the RealProxy acts as a splitter.

RealProxy and Access Control

If a client requests a cached stream, the RealProxy sends the request to the source RealServer for permission before allowing the client to play the stream. If RealServer denies the request, the RealProxy does not allow the client to receive the stream.

You can block a single RealProxy from caching the material served by your RealServer by creating an access rule that prohibits the IP address of that RealProxy from connecting to your RealServer.

The RealProxy cannot cache live broadcasts, because there is no actual file to cache. However, the RealProxy includes an ability to "share" live streams among clients and thus reduce the bandwidth required from a transmitter. RealServer and the RealProxy communicate through pull splitting; RealServer is preconfigured to act as a transmitter, and the RealProxy is automatically set up to act as a receiver.

A description of the Real-Time Streaming Protocol (RTSP) is available as IETF RFC 2326.

RealProxy Administration Page

A RealProxy page has been added to the Caching menu of the Cache software management GUI. (See Figure 3-2.) To configure the RealProxy software, click the Admin button to access the RealSystem administrator GUI, as shown in Figure 3-3.

Note The Admin button appears only when the RealProxy software is installed, configured, and started.

Figure 3-2: Cache Software Management GUI—RealProxy Page

Figure 3-3: Cache Software Management GUI—RealProxy Administration Page

Rules Template

The Rules Template feature allows for requests to be matched using an arbitrary number of parameters with an arbitrary number of policies applied against the matches. Requests can be matched against regular expressions symbolizing domain names, source IP addresses and network masks, destination IP addresses and network masks, destination port numbers, MIME-types, or regular expressions symbolizing a URL.

Policies that can be applied include:

Blocking the request
Using a specific object freshness calculation factor
Not caching an object
Bypassing an upstream proxy for the request
Redirecting the request to a different URL
Revalidating the object with the origin server
Rewriting the URL
Selectively caching the object
Using a specific upstream proxy
Using a specific server for the request

The options freshness-factor, redirect, rewrite, and use-server are introduced in Cache software, Release 3.1.

Support for streaming protocols (RTSP, RTP, and so forth) is not implemented in Release 3.1, although RealProxy can use source-IP-based block and allow configurations to restrict client access.

Proxy protocols such as HTTP, FTP, and HTTPS are supported, but not on a per protocol basis.

Patterns and Actions

A rule is a pattern and an action. If an HTTP request matches the pattern, the corresponding action is performed on the request.

A pattern defines the limits of an HTTP request; for instance, a pattern may specify that the source IP address fall in the subnet range 172.16.*.*.

An action is something that the Content Engine performs when processing an HTTP request, for instance, blocking the request, using an alternative proxy, and so forth.

Rules can be dynamically added, displayed, or deleted from the Content Engine. The rules are preserved across reboots because they are written into persistent storage such as NVRAM. Only the system resources limit the number of rules that the Content Engine can support. Because rules consume resources, the more rules there are defined, the more Content Engine performance may be affected.

Actions

The Rules Template feature supports ten actions as follows:

Block—Blocks this request.
Freshness-factor—If the request's URL matches a specified regular expression, then use the freshness factor to determine the Time To Live. The refresh configuration takes priority over freshness-factor configurations.
No-cache—Does not cache this object. If both no-cache and selective-cache actions are matched, no-cache takes precedence.
No-proxy—For a cache miss, does not use the configured upstream proxy but rather contacts the server directly.
Redirect—Redirects the original request to a specified URL.
Refresh—For a cache hit, forces an object freshness check with the server.
Rewrite—Rewrites the original request as a specified URL.The Content Engine searches for the rewritten URL in cache and then on cache miss, fetches the rewritten URL, and returns the object transparently to the client. It is preferable to use a redirect rule than rewrite because of possible performance impacts.

: The URL rewrite could change the domain name of the URL, which necessitates a DNS lookup to find the dst (destination) IP address of the new rewritten server to which the request must be sent. The original dst IP address derived from the WCCP redirect packet cannot be used.

Selective-cache—Caches this object only if it is a match and is allowed to be cached by HTTP. If one or more rules specify this action, an object is cached if and only if it matches at least one of the selective-cache rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check. If the object does not match any of the selective-cache rules, the object is not cached.
Use-proxy—For a cache miss, uses a specific upstream proxy. Specify the upstream proxy's IP address (or domain name) and port number. If both no-proxy and use-proxy are matched, no-proxy takes precedence.
Use-server—The Content Engine sends server-style HTTP requests to the specified IP address and port on a cache miss.

Among use-server, no-proxy, and use-proxy rules, the use-server rule is the first one to be checked. If it results in a rule miss, no-proxy and use-proxy rules are executed in succession (use-proxy will not be checked if a no-proxy rule matches).

If a rule is configured with a fully qualified domain name (FQDN) and a request is received with the partial domain name in transparent mode, the rule is not executed, because the FQDN is not in the request URL. In transparent mode, if a request is destined for a particular domain (for which a domain rule is configured) and does not contain the Host header, the rule pattern match fails.

Note The commands rule no-proxy and rule use-proxy take precedence over https proxy outgoing, http proxy outgoing, and ftp proxy outgoing commands.

Rules are ORed together. Multiple rules may all match a request; then all actions are taken, with precedence among conflicting actions. Each rule contains one pattern; patterns cannot be ANDed together. In future releases, ANDed patterns may be supported.

Note Because the MIME type exists only in the response, only the actions freshness-factor, refresh, no-cache, refresh, and selective-cache apply to a rule of MIME type.

It is possible to circumvent some rules. For example, to circumvent a rule with the domain pattern, just enter the web server IP address instead of the domain name in the browser. A rule may have unintended effects. For instance, a rule with the domain pattern specified as "ibm" that is intended to match "www.ibm.com" can also match domain names like www.ribman.com.

A src-ip rule may not apply as intended to requests that are received from another proxy because the original client IP address is in an X-forwarded-for header.

Patterns

The Rules Template feature supports the following types of patterns.

Domain—Matches the domain name in the URL or the Host header against a regular expression. For example, ".*ibm.*" matches any domain name that contains the "ibm" substring. "\.foo\.com$" matches any domain name that ends with the ".foo.com" substring.
Dst-ip—Matches the request's destination IP address and netmask. Specify an IP address and a netmask. In proxy mode, the Content Engine does a DNS lookup to resolve the destination IP address of the HTTP request, making the response time longer, and possibly negating the benefit of setting a dst-ip rule. When an outgoing proxy is configured, cache miss requests are forwarded by the Content Engine to the outgoing proxy without examination of the destination server IP address, making the dst-ip rule unenforceable on the first Content Engine.
Dst-port—Matches the request's destination port number. Specify a port number.
MIME-type—Matches the MIME type of the response. Specify a MIME type string, for example, "image/gif," as defined in RFC 2046 (http://info.internet.isi.edu/in-notes/rfc/files/rfc2046.txt). The administrator can specify a substring, for example, "java" and have it apply to all MIME types with the "java" substring, such as "application/x-javascript."
Src-ip—Matches the request's source IP address and netmask. Specify an IP address and a netmask.
URL-regex—Matches the URL against a regular expression. The match is case insensitive. Specify a regular expression whose syntax can be found at the following URL: http://yenta.www.media.mit.edu/projects/Yenta/Releases/Documentation/regex-0.12/.
URL-regsub—For the rewrite and redirect actions, matches the URL against a regular expression to form a new URL per pattern substitution specification. The match is case insensitive. The valid substitution index range is from 1 to 9.

Examples

Multiple patterns can be input on the same line. If any of them matches the incoming HTTP request, the corresponding action is taken.

ContentEngine(config)# rule block domain \.foo.com ?

 LINE    <cr>    

ContentEngine(config)# rule block domain \.foo.com bar.com

ContentEngine(config)#
 
ContentEngine(config)# rule no-cache url-regex \.*cgi-bin.* ?

 LINE     <cr>
ContentEngine(config)# rule no-cache url-regex \.*cgi-bin.*

ContentEngine(config)#
 
ContentEngine(config)# rule no-cache dst-ip 172.77.120.0 255.255.192.0

Most actions do not have any parameters, as in the preceding examples. Exceptions to this are use-server, freshness-factor, and use-proxy, as in the following example.

ContentEngine(config)# rule use-proxy ?

 Hostname or A.B.C.D. IP address of the specific proxy
ContentEngine(config)# rule use-proxy CE.foo.com ?

<1-65535>  Port number of the specific proxy 
ContentEngine(config)# rule use-proxy CE.foo.com 8080 ?

  domain     Regular expression to match with the domain name
  dst-ip     Destination IP address of the request
  dst-port   Destination port number
  src-ip     Source IP address of the request
  url-regex  Regular expression to substring match with the URL
ContentEngine(config)# rule use-proxy CE.foo.com 8080 url-regex ?

 LINE  Regular expression to substring match with the URL
ContentEngine(config)# rule use-proxy CE.foo.com 8080 url-regex .*\.jpg$ ?

 LINE     <cr>
ContentEngine(config)# rule use-proxy CE.foo.com 8080 url-regex .*\.jpg$ .*\.gif$ .*\.pdf$ 

ContentEngine(config)#

Other branches of the rule command work similarly to the above examples.

To delete rules, use no in front of the rule creation command.

ContentEngine(config)#no rule block url-regex .*\.jpg$ .*\.gif$ .*\.pdf$

ContentEngine(config)# rule block domain cisco.com

ContentEngine(config)# rule block dst-ip ?

  A.B.C.D  Destination ip address of the request
ContentEngine(config)# rule block dst-ip 10.1.1.1 ?

  A.B.C.D  IP subnet mask
ContentEngine(config)# rule block dst-ip 10.1.1.1 255.255.255.0 ?

  <cr>
ContentEngineconfig)# rule block dst-ip 10.1.1.1 255.255.255.0

ContentEngine(config)# rule use-proxy 1.1.1.1 80 url-regex \ http://www\.netscape\.com\/

The following example sets the freshness factor for MIME-type images.

ContentEngine(config)# rule freshness-factor 75 mime-type image/.*

The following example redirects a request for old-domain-name, which has been changed to new-domain-name.

ContentEngine(config)# rule redirect url-regsub http://old-domain-name/  
http://new-domain-name/

The following example redirects requests from an IETF site to one that is locally mirrored:

ContentEngine(config)# rule redirect url-regsub http://www.ietf.org/rfc/(.*)  
http://wwwin-eng.cisco.com/RFC/RFC/\1

For the preceding example, if the request URL is http://www.ietf.org/rfc/rfc1111.txt, the Content Engine rewrites the URL as http://wwwin-eng.cisco.com/RFC/RFC/rfc1111.txt and sends a 302 Temporary Redirect response with the rewritten URL in the Location header to the client. The browser automatically initiates a request to the rewritten URL.

The following example redirects all requests for linux.org to a local server in India that is closer to where the Content Engine is located:

ContentEngine(config)# rule redirect url-regsub http://linux.org/(.*)  
http://linux.org.in/\1

The following example rewrites requests from an IETF site to one that is locally mirrored:

ContentEngine(config)# rule rewrite url-regsub http://www.ietf.org/rfc/.*  
http://wwwin-eng.cisco.com/RFC/$1

Related Commands

bypass static

clear statistics rule

http proxy outgoing

https proxy outgoing

ftp proxy outgoing

proxy-protocols outgoing exclude

show rule

show statistics rule

Transparent Caching

Accelerated WCCP Support

Accelerated WCCP is a generic term for a deployment in which WCCP on a router or switch can take advantage of switching hardware that either partially or fully implements the traffic interception and redirection functions of WCCP in hardware at Layer 2. Accelerated WCCP is currently supported only with the Cisco Catalyst 6000 and 6500 Family switches.

The Content Engine must have a Layer 2 connection with the switch. Because there is no requirement for a generic routing encapsulation (GRE) tunnel between the switch and the Content Engine, the switch can use a cut-through method of forwarding packets. For the Catalyst 6000 and 6500 Family switches, this feature is called WCCP Layer 2 PFC Redirection and has been available since Cisco IOS Release 12.1(1)E in July 2000. This method is intended to achieve forwarding performance of up to 3 gigabits per second using a combination of the Supervisor Engine 1A and the Multilayer Switch Feature Card 2 (MSFC2).

Related Cache software commands are wccp custom-web-cache, wccp media-cache, wccp reverse-proxy, wccp service-number, and wccp web-cache.

The following example configures a Content Engine to receive Layer 2 redirected traffic from a Catalyst 6500 Series switch with a Multilayer Switch Feature Card and Supervisory Engine 1 (MSFC/SUP 1). (Multiple caching services are configured for informational purposes only.)

ContentEngine(config)# wccp version 2

ContentEngine(config)# wccp router-list 1 172.16.55.1

ContentEngine(config)# wccp port-list 1 80

ContentEngine(config)# wccp web-cache router-list-num 1 l2-redirect

ContentEngine(config)# wccp media-cache router-list-num 1 l2-redirect

ContentEngine(config)# wccp web-cache router-list-num 1 l2-redirect

ContentEngine(config)# wccp reverse-proxy router-list-num 1 l2-redirect

ContentEngine(config)# wccp service-number 90 router-list-num 1 port-list-num 1 

                       application cache l2-redirect

Multiport Transparent Redirection

The multiport feature can be summarized as follows:

Up to eight incoming proxy ports are supported for each proxy protocol (FTP, HTTP, HTTPS, and RTSP).
Proxy-style requests in HTTP, FTP, HTTPS, and RTSP protocols can be received on the same incoming proxy port.
Both transparent and proxy-style requests can be serviced on the same port.
Transparent traffic is disallowed on invalid ports.
Nonsupported protocols are disallowed over incoming ports.

The proxy incoming option of the http, https, ftp, and rtsp global configuration commands now supports up to eight ports per protocol.

The multiport feature requires Web Cache Communication Protocol, Version 2 (WCCP Version 2), and requires the configuration of the wccp port-list and the wccp service-number global configuration commands. The application cache option of the wccp service-number global configuration command redirects traffic to the Cache software conventional caching processes, whereas the application streaming option redirects traffic to the Content Engine media caching processes.

Note DNS must be configured in order to support incoming HTTPS proxy requests

Proxy Mode Operation

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, and RTSP proxy modes. To proxy RTSP requests, the Cache software, Release 3.1 optional software must be installed and enabled. The incoming proxy ports can be the same ports that are used by the 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 farm.

In proxy mode, the Content Engine services any protocols for which it has been configured. The supported protocols are HTTP, HTTPS, FTP, 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.

Transparent Mode Operation

A transparent request is a request redirected to the Content Engine from a router. Transparent requests have a different destination IP address than the Content Engine. The style of the URL within a transparent request is usually server-style but can be proxy-style when the Content Engine intercepts a request destined for another proxy server. Server-style requests do not include the protocol and host name, but RTSP requests are the same for server-style and for proxy-style. If a server-style URL is received, only HTTP and RTSP are supported (if RTSP user-agent criteria are met). If a proxy-style URL is received, HTTP, HTTPS, FTP, and RTSP are supported when the respective proxy services are configured.

The wccp service-number global configuration command can enable up to eight dynamic WCCP redirection services (90 to 97) on a Content Engine, provided that the services are also configured on the router. Each wccp service-number command specifies a router list, single port list (containing up to eight ports), application type, hash parameters, password, and weight. With eight dynamic services using a maximum number of eight ports each, the maximum number of ports that can be specified for transparent redirection is 64.

The legacy custom web cache and reverse proxy services (service numbers 98 and 99) can be configured with only one port each. If only one legacy service is configured, the total maximum number of transparent redirection ports is 57. If both legacy services are configured, the maximum port total is 50.

All ports receiving HTTP that are configured as members of the same WCCP service share the following characteristics:

They have the same hash parameters as configured with the wccp service-number command.
The service on individual ports cannot be stopped or started individually (WCCP Version 2 restriction).

With Content Engines in a farm, the following restrictions apply:

All Content Engines that use the same WCCP service are required to configure the same list of ports and the same hash parameters.
A Content Engine that tries to join the farm with the same WCCP service using a different list of ports or different hash parameters is rejected by the router.
To change the port list for a particular WCCP service, WCCP service must be stopped on all involved Content Engines, and then all must be restarted with the new parameters.

The Content Engine WCCP implementation currently allows global settings that apply to all WCCP services, such as healing parameters, slow start, and others. The multiple service model does not change that, and the settings in question remain global for the whole WCCP system.

Modifying Multiport Configurations

To disable HTTP, HTTPS FTP, and RTSP incoming proxy services use no protocol proxy incoming command. To add or remove ports in proxy mode, issue a new command that specifies all the ports to be used.

In transparent mode, to add or remove ports for a WCCP service, modify the port list or create a new port list for the WCCP service. A no wccp service-number command disables the specified service.

In the following example, ports 200, 3000, 110, 220, 330, 440, and 40000 are added to port list 3.

ContentEngine(config)# wccp port-list 3 10 

ContentEngine(config)# wccp port-list 3 10 200 3000 110 220 330 440 40000

In this example, the Content Engine is configured to accept FTP, HTTP, and HTTPS proxy requests on ports 81, 8080, and 8081:

ContentEngine(config)# http proxy incoming 81 8080 8081

ContentEngine(config)# https proxy incoming 81 8080 8081

ContentEngine(config)# ftp proxy incoming 81 8080 8081

HTTP Range Request Caching

The Content Engine operating Cache software, Release 3.1, serves HTTP Range requests from the cache if the requested range exists in the Content Engine cache. Specifically, the Content Engine handles range requests with the following logic:

lookup the object in the cache; 
if object in the cache 
{ 
            check whether the requested ranges are in the cache; 
            if the requested ranges are in cache then serve the request from cache; 
            else pipe through the request; 
} 
else pipe through the request;

Note The If-Range header is not fully supported. If a request has an If-Range header, it is piped through to the server even if the requested object is in the cache.

The http cache-on-abort feature must be disabled for this feature to operate. Some client applications close the server connection immediately after receiving the response header for the normal GET request (for example, to a .pdf file ). If the http cache-on-abort command is configured to not cache aborted objects, later range requests to that object will not hit in the cache at all.

Table of Contents

Cache Software Feature Configurations

Requirements