Cisco ACNS Software Caching Configuration Guide, Release 4.2 - Chapter 5: Transparent Caching [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Transparent Caching

Transparent Caching Through WCCP

Transparent Caching and WCCP Service Group Features

Configuration Tasks

Prerequisites

Configuring the Content Engine

Enabling WCCP on the Router

Basic WCCP Router Configurations for Web Cache Applications

Web Cache Service Configuration with Clients and Content Engine on Same Subnet

Configuring the Content Engine for Web Cache Service—Clients and Content Engine on Same Subnet

Configuring the Router for Web Cache Service—Clients and Content Engine on Same Subnet

Configuration Examples—Web Cache Service with Clients and Content Engine on the Same Subnet

Web Cache Service Configuration with Clients and Content Engine on Different Subnets

Configuring the Content Engine for Web Cache Service—Clients and Content Engine on Different Subnets

Configuring the Router for Web Cache Service—Clients and Content Engine on Different Subnets

Configuration Examples—Web Cache Service with Clients and Content Engine on Different Subnets

Disabling Transparent Caching Services on the Content Engine

Verifying the Software Configuration

Removing or Replacing a Content Engine

Advanced Transparent Caching Features

Authentication Traffic Bypass

Dynamic Traffic Bypass

Scenario 1—Dynamic Bypass upon Receiving a Web Server Error

Scenario 2—Dynamic Bypass upon Receiving an Unsupported Protocol

Overload Bypass

Static Bypass

Examples

Multiport Transparent Redirection

Modifying Multiport Configurations

WCCP Flow Protection

IP Spoofing

Configuring the Content Engine for IP Spoofing

Configuring the Router for IP Spoofing

Configuration Examples—IP Spoofing

Accelerated WCCP Layer 2 Support

Configuring Transparent Caching with the Cisco CSS 11000 Series Switch

Content Engine CLI Commands

Enabling Transparent Caching Using the CSS Switch

Transparent Caching Sample Configuration Output

Transparent Caching

This chapter explains transparent caching using a WCCP-enabled router and a Layer 4 switch. This chapter also shows configuration examples and advanced transparent caching features relevant to the Content Engine. This chapter contains the following sections:

•Transparent Caching Through WCCP

•Advanced Transparent Caching Features

•IP Spoofing

•Accelerated WCCP Layer 2 Support

•Configuring Transparent Caching with the Cisco CSS 11000 Series Switch

Transparent Caching Through WCCP

In transparent caching through WCCP, the user is unaware that the request made to an origin server is redirected to the Content Engine by a WCCP-enabled router. A request to a WCCP-enabled router allows for traffic interception on any port number for traffic that traverses the WCCP-enabled router or switch. WCCP contains many fail-safe mechanisms to ensure that the caching solution remains entirely transparent to the end user.

A Content Engine transparently caches as follows. (See Figure 5-1.)

1. A user requests a web page from a browser.

2. The WCCP-enabled router analyzes the request, and based on TCP destination port number, the router determines whether it should transparently redirect the request to a Content Engine. Access lists are used to control which requests can be redirected.

3. If the Content Engine does not have the requested content, it sets up a separate TCP connection to the end server to retrieve the content (3a). The content returns to, and is stored on, the
Content Engine (3b).

4. The Content Engine sends the content to the client. Upon subsequent requests for the same content, the Content Engine transparently fulfills the request from its local storage.

Figure 5-1 Transparent Caching Through WCCP

WCCP can also handle asymmetric packet flows and always maintains a consistent mapping of web servers to Content Engines regardless of the number of switches or routers used in a WCCP service group (up to 32 routers or switches communicating with up to 32 Content Engines in a cluster).

There are some significant advantages to deploying Content Engines in transparent mode:

•No end user configuration—The user does not have to point to the Content Engine.

•Fail-safe—Content Engines are automatically fault-tolerant and fail-safe. Any cache failure does not cause denial of service to the end user.

•Scalable—Cache services can be scaled by deploying multiple Content Engines.

•Automatic bypass—Sites which depend on end user authentication or which fail to conform to HTTP standards will automatically bypass a transparent cache.

Transparent Caching and WCCP Service Group Features

A transparent request is a request redirected to the Content Engine from a router. 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 Real-Time Streaming Protocol (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 the RTSP user agent criteria are met). If a proxy-style URL is received, HTTP, HTTP over Secure Socket Layer (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.

Table 5-1 lists the service group features supported by a WCCP-enabled router.

Table 5-1 WCCP Service Groups

Service Group Number

Description of Services

0

Web cache

50

Boomerang

80

HTTP, RTSP

81

MMST

82

MMSU

90-97

User-configurable

98

Custom

99

Reverse proxy

Note All service group numbers listed in Table 5-1 except for web cache services (service group 0) require WCCP Version 2.

The hash parameters specify how traffic should be load-balanced among the different service groups. Specifically, hashing maps items from one item set to another, such as mapping destination IP addresses to different Content Engines in a service group from the WCCP-enabled router for load-balancing purposes.

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.

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. In Figure 5-2 the two Content Engines on the left handle only HTTP traffic through port 80 and are defined as members of service group 90. The two Content Engines on the right handle only Microsoft Media Server (MMS) requests and are defined as members of service group 91.

Figure 5-2 WCCP Service Group Feature

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.

Configuration Tasks

Use the following configuration tasks to help you configure the Content Engine in transparent mode using a WCCP-enabled router. To learn about transparent caching with a Layer 4 switch, see the "Configuring Transparent Caching with the Cisco CSS 11000 Series Switch" section.

Prerequisites

To use a WCCP-enabled router, an IP address must be configured on the interface connected to the Internet and the interface must be visible to the Content Engine on the network.

Configuring the Content Engine

To use WCCP, the Content Engine must be properly configured. Keep these important points in mind:

•The IP address of the router must be configured as the home router for the Content Engine. In this scenario, this router is the device that performs all the IP packet redirection for the Content Engine.

•Versions of software on the Content Engines must be compatible with those installed on the router.

•The Content Engines must not have their packets encrypted or compressed and should be part of the "inside" Network Address Translation if one is present.

•Placing a Content Engine beyond a web cache redirect-enabled interface and along the route to the server will not cause the IP route cache to be populated with an entry.

Enabling WCCP on the Router

To enable an interface to redirect web traffic to the Content Engine using WCCP Version 2, perform the following tasks beginning in global configuration mode on the router:
Command

Purpose
Step 1
ip wccp enable
Enables the router to use WCCP.
Step 2
ip wccp redirect-list [number | name]
(Optional.) Specifies the redirect access list. Only packets that match this access list are redirected. If you do not configure this command, all packets are redirected.

Note If you are using a redirect access list with dCEF on the Cisco 7500 Series, then you must use a numbered access list instead of a named access list.
Step 3
interface type number
Enters interface configuration mode.
Step 4
ip web-cache redirect
Configures the interface connected to the Internet to redirect web traffic to the Content Engine.
Step 5
ip route-cache same-interface
(Optional.) If the client and a Content Engine are located on the same network, configures the router to use the fast switching path on the interface.
Step 6
end
Exits configuration mode.
Step 7
copy running-config startup-config
Saves the configuration.
For more information on how to configure a WCCP-enabled router for transparent caching, see "Web Cache Communication Protocol Version 1," and "Web Cache Communication Protocol Version 2."

Basic WCCP Router Configurations for Web Cache Applications

A router with the proper configuration is required for transparent caching services. The router must be running a version of Cisco IOS software that supports the Web Cache Communication Protocol (WCCP) Version 1 or Version 2. In this section we use WCCP Version 2 to illustrate the sample configurations.

When caching support is enabled on the router, and WCCP support is enabled on the Content Engines, the devices can communicate and deliver the services for which they are configured. To suspend caching services, you can disable caching support on the router rather than powering off or otherwise disabling individual Content Engines. (For instance, use the no ip wccp router command to disable caching.)

Many WCCP Version 2 features also require a configuration of the appropriate Cache application wccp global configuration command. Refer to the Cisco ACNS Software Command Reference, Release 4.2 and release notes for more details.

If you do not know how to configure a router or a switch, refer to the software documentation supplied with the devices. Further information on WCCP Version 2 commands and router configuration examples are in the Cisco IOS software online documentation as well as in "Web Cache Communication Protocol Version 2."

Web Cache Service Configuration with Clients and Content Engine on Same Subnet

In this scenario, the Content Engine and the requesting clients are on the same subnet, as shown in Figure 5-3.

A router running WCCP Version 2 transparently redirects client HTTP traffic bound for router interface s0/0 to the Content Engine. The web cache service redirects HTTP traffic on port 80 only.

Figure 5-3 Web Cache Service with Clients and Content Engine on Same Subnet

Configuring the Content Engine for Web Cache Service—Clients and Content Engine on Same Subnet

To configure the Content Engine for web cache service, perform the following steps while logged in to the Cache software in global configuration mode:
Command

Purpose
Step 1
contentengine(config)# wccp version 2
Ensures that Content Engine is running WCCP Version 2.
Step 2
contentengine(config)# wccp router-list 1 10.10.10.1
Configures a router list.
Step 3
contentengine(config)# wccp web-cache 
router-list-num 1
Informs the routers in the specified router list that the Content Engine is accepting web cache service.
Step 4
contentengine(config)# exit
Exits global configuration mode.
Step 5
contentengine# write memory
Writes running configurations to nonvolatile memory.
Configuring the Router for Web Cache Service—Clients and Content Engine on Same Subnet

To configure the router for web cache service, perform the following steps while logged in to the router in global configuration mode:
Command

Purpose
Step 1
router(config)# ip wccp web-cache 
Instructs the router to run the web cache service.
Step 2
router(config)# interface Ethernet0 
Specifies which router interface to configure. In this scenario, Ethernet0 is the router interface to which the Content Engine and clients are connected.
Step 3
router(config-if)# ip route-cache 
same-interface 
Enables fast switching of redirected packets back through the interface on which they were received. Without this command, the router does not use the high-speed switching cache, and the packets are process-switched, a much slower method.
Step 4
router(config)# interface Serial0 
Specifies which router interface to configure. In this scenario, Serial0 is the router interface to the Internet.
Step 5
router(config-if)# ip wccp web-cache redirect 
out 
Instructs the router to redirect web cache traffic bound for the specified interface to Content Engines that accept web cache service. In this scenario there is only one router. Web cache traffic is defined as TCP port 80 traffic.
Step 6
router(config-if)# exit 
Exits global configuration mode.
Configuration Examples—Web Cache Service with Clients and Content Engine on the Same Subnet

This example shows a Content Engine and router configured for web cache service with the topology illustrated in Figure 5-3:

Content Engine
hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cu.net
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
. . . 
WCCP-Enabled Router
Building configuration...
Current configuration:
!
version 12.0
!
hostname WCCP-Router
!
!
ip wccp web-cache         
!
interface Ethernet0
 ip address 10.10.10.1 255.255.255.0
 ip route-cache same-interface
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
 !
end
Web Cache Service Configuration with Clients and Content Engine on Different Subnets

In this scenario, the Content Engine and the requesting clients are on different subnets, as shown in Figure 5-4.

A router running WCCP Version 2 transparently redirects client HTTP traffic bound for router interface s0/0 to the Content Engine. The web cache service redirects HTTP traffic on port 80 only.

Figure 5-4 Web Cache Service with Content Engine and Clients on Different Subnets

Configuring the Content Engine for Web Cache Service—Clients and Content Engine on Different Subnets

To configure the Content Engine for web cache service, perform the following steps while logged in to the Cache software in global configuration mode:
Command

Purpose
Step 1
contentengine(config)# wccp version 2
Ensures that the Content Engine is running WCCP Version 2.
Step 2
contentengine(config)# wccp router-list 1 
10.10.20.1 
Configures a router list.
Step 3
contentengine(config)# wccp web-cache 
router-list-num 1
Informs the routers in the specified router list that the Content Engine is accepting web cache service.
Step 4
contentengine(config)# exit
Exits global configuration mode.
Step 5
contentengine# write memory
Writes running configurations to nonvolatile memory.
Configuring the Router for Web Cache Service—Clients and Content Engine on Different Subnets

To configure the router for web cache service, perform the following steps while logged in to the router in global configuration mode:
Command

Purpose
Step 1
router(config)# ip wccp web-cache
Instructs the router to run the web cache service.
Step 2
router(config)# interface Serial0 
Specifies which router interface to configure. In this scenario, Serial0 is the router interface to the Internet.
Step 3
router(config-if)# ip wccp web-cache redirect out 
Instructs the router to redirect web cache traffic bound for the specified interface to Content Engines that accept web cache service. In this scenario there is only one router. Web cache traffic is defined as HTTP packets on port 80.
Step 4
router(config-if)# exit 
Exits global configuration mode.
Configuration Examples—Web Cache Service with Clients and Content Engine on Different Subnets

This example shows a Content Engine and router configured for web cache service with the topology illustrated in Figure 5-4:

Content Engine Configuration
. . .
hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cisco.com
!
exec-timeout 20
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
...
WCCP-Enabled Router Configuration
Building configuration...
Current configuration:
!
hostname WCCP-Router
!
!
ip subnet-zero
!
ip wccp web-cache         
!
interface Ethernet0
 ip address 10.10.10.1 255.255.255.0
!
interface Ethernet1
 ip address 10.10.20.1 255.255.255.0
!
interface Serial0
 ip address 192.168.1.2 255.255.255.252
 no ip directed-broadcast
 no ip mroute-cache
ip wccp web-cache redirect out
 !
end
Disabling Transparent Caching Services on the Content Engine

To disable transparent caching on a Content Engine in a WCCP environment without powering it down, disable the running version of WCCP on the Content Engine by issuing the Cache software
no wccp version 2 global configuration command. The Content Engine will still service proxy-style requests, if so configured, and preserve its configuration settings.

Further information about the Content Engine commands used to configure the Content Engine for the deployment scenarios provided in this chapter can be found in the Cisco ACNS Software Command Reference, Release 4.2. Refer to this document for more information about the Content Engine commands.

Verifying the Software Configuration

Once you have installed and configured the Content Engine and enabled WCCP caching services on the router, verify that the Cache application is working properly.

Step 1 Start a web browser and open various web pages on the Internet or your intranet. The web servers you connect to must be on a different subnet, so that the request goes through either a home router running WCCP Version 1 or Version 2, or a cluster of routers running WCCP Version 2. Request the same pages more than once, to ensure that pages you request are in the cache. For more information on WCCP, see "Web Cache Communication Protocol Version 1," and "Web Cache Communication Protocol Version 2."

Step 2 From the CLI, enter the following command to display the Content Engine HTTP caching saving statistics:
show statistics http savings
Step 3 Open a console or Telnet session on the home router or routers, and enter the show ip wccp commands to display statistics and status information about the Content Engine.

The statistics should show a number greater than 0 for packets redirected. Also, check for hash assignments, which indicate at the very least that the Content Engines are registered and communicating with the routers.

If the router shows that no packets are being redirected to the Content Engine, you must troubleshoot your setup.

Removing or Replacing a Content Engine

Refer to the Content Engine hardware documentation for instructions on physically removing a Content Engine from an active network.

The router and the Content Engine are in constant communication when WCCP is enabled; thus, when the router notices that the engine is no longer responding to it, the router stops sending requests to the engine. This is transparent to users. If other Content Engines are attached to the router, the router continues sending requests to the other engines.

Advanced Transparent Caching Features

One of the fundamental principles of transparent network caching is that the Content Engine must remain transparent to the end user at all times. A transparent caching solution must not introduce any possible failure conditions or side effects in a network.

The Cisco caching solution uses a WCCP-enabled router and various advanced techniques to ensure that the Content Engine remains transparent, even if web browsers are nonoperational or web servers are not HTTP-compliant.

The following features ensure that customers do not encounter unexpected problems while deploying Cisco caching solutions:

•Authentication Traffic Bypass

•Dynamic Traffic Bypass

•Overload Bypass

•Static Bypass

•Multiport Transparent Redirection

•WCCP Flow Protection

Note When bypass is enabled, the client itself tries to reach the origin server. You must make sure to disable all bypass options at this point to eliminate an unnecessary burden on the network.

Authentication Traffic Bypass

Because of IP authentication, some websites do not allow the Content Engine to connect directly on behalf of the client. In order to preserve cache transparency and avoid disruption of service, the Content Engine can use authentication traffic bypass to automatically generate a dynamic access list for the selected client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in the case of hierarchical caching.

To enable transparent error handling and dynamic authentication bypass, and to configure static bypass lists, use the bypass global configuration command. To disable the bypass feature, use the no form of the command.

For example, when a client/server pair performs authentication bypass, it is bypassed for a configurable amount of time, which is set by the global configuration bypass timer command (10 minutes by default).

This example forces all authenticated HTTP traffic to bypass the Content Engine for 24 hours:
ContentEngine(config)# bypass auth-traffic enable
ContentEngine(config)# bypass timer 1440 
Dynamic Traffic Bypass

The following two scenarios describe typical dynamic traffic bypass situations.

Scenario 1—Dynamic Bypass upon Receiving a Web Server Error

A user issues an HTTP request from a web browser. The request is transparently intercepted and redirected to the Content Engine. The Content Engine accepts the incoming TCP connection from the web browser, determines that the request is for an object not in storage (cache-miss), and issues a request for the object from the origin web server, but receives some kind of error (for instance, a protocol or authentication error) from the web server.

The Content Engine has already accepted the TCP connection from the web browser and the three-way TCP handshake has taken place. The Content Engine detects that the transaction with the web server is failed, but it does not know the cause (the origin web server is performing authentication based on user source IP address, incompatibility between the TCP stacks, and so forth).

Dynamic client bypass in this case means that the Content Engine returns an HTTP response code 200 (200 Temporarily Moved) to the browser with the exact same URL again. The Content Engine closes the TCP connection between the web browser and the Content Engine by issuing a "Connection: close" HTTP response header to the web browser. The browser then automatically retries the connection.

On the connection retry, the Content Engine does not accept the connection. It passes the request back to the WCCP-enabled router or switch unintercepted. The router then sends the flow toward the origin web server directly from the web browser, thereby bypassing the Content Engine. (See Figure 5-5.)

Figure 5-5 Dynamic Traffic Bypass

Scenario 2—Dynamic Bypass upon Receiving an Unsupported Protocol

When the Content Engine receives non-HTTP requests over TCP port 80, the Content Engine issues a "retry" response, closes the connection, and does not accept subsequent connections in the same manner as in Scenario 1. A "retry" response is a normal HTTP response which states that the response needs a refresh or another try.

Note Non-HTTP includes nonconforming HTTP as well as different protocols such as Secure Shell (SSH), Simple Mail Transfer Protocol (SMTP), or Network News Transport Protocol (NNTP). An example of nonconforming HTTP is the failure of a web server to issue two carriage returns and line feeds at the end of the HTTP header section.

These two scenarios implement the WCCP return-path functionality, which is a mechanism whereby a Content Engine can return traffic to the WCCP-enabled router or switch, telling the router or switch to forward the packets as if the Content Engine were not present.

It is typical for about 3 percent of all HTTP traffic flows to fail. These failed flows are automatically retried using authentication bypass or dynamic client bypass, demonstrating that the failure conditions were preexisting and not due to the deployment of transparent caching.

Overload Bypass

If a Content Engine becomes overwhelmed with traffic, it can use the overload bypass feature to reroute the overload traffic.

When the Content Engine is overloaded and the bypass load command is enabled, the Content Engine refuses additional requests and forwards them to the origin servers. If the load remains too high, more traffic is bypassed to the servers, and so on until the Content Engine can handle the load. The time interval between one bucket being bypassed and the next is set by the out-interval option. The default is 4 seconds. (See Figure 5-6.)

Figure 5-6 Overload Bypass

When the first bucket bypass occurs, a set interval must elapse before the Content Engine begins to again service the bypassed buckets. The duration of this interval is set by the time-interval option. The default is 10 minutes.

When the Content Engine begins to service the bypassed traffic again, it begins with a single bypassed bucket. If the load is serviceable, it picks up another bypassed bucket, and so on. The time interval between picking up one bucket and the next is set by the in-interval option. The default is 60 seconds.

Static Bypass

The bypass static command permits traffic from specified sources to bypass the Content Engine. The type of traffic sources are as follows:

•Specific web client to a specific web server

•Specific web client to any web server

•Any web client to a specific web server

Wildcards in either the source or the destination field are not supported.

To clear all static configuration lists, use the no form of the command.

Note You can also configure the router with access lists (ACLs) to increase static bypass performance.

Examples

This example forces HTTP traffic from a specified client to a specified server to bypass the Content Engine:
ContentEngine(config)# bypass static 10.1.17.1 172.16.7.52
This example forces all HTTP traffic destined to a specified server to bypass the Content Engine:
ContentEngine(config)# bypass static any-client 172.16.7.52
This example forces all HTTP traffic from a specified client to any web server to bypass the Content Engine:
ContentEngine(config)# bypass static 10.1.17.1 any-server
This example forces all authenticated HTTP traffic to bypass the Content Engine for 24 hours:
ContentEngine(config)# bypass auth-traffic enable
ContentEngine(config)# bypass timer 1440
A static list of source and destination addresses helps to isolate instances of problem-causing clients and servers.

To display static configuration list items, use the show bypass list command.
ContentEngine# show bypass list
Client              Server          Entry type
------              ------          ----------
10.1.17.1:0         172.16.7.52:0   static-config
any-client:0        172.16.7.52:0   static-config
10.1.17.2:0         any-server:0    static-config 
The total number of entries in the bypass list is reported by the show bypass summary command.
Total number of HTTP connections bypassed = 0
        Connections bypassed due to system overload               = 0
        Connections bypassed due to authentication issues         = 0
        Connections bypassed due to facilitate error transparency = 0
        Connections bypassed due to static configuration          = 0
Total number of entries in the bypass list = 3
        Number of Authentication bypass entries = 0
        Number of Error bypass entries          = 0
        Number of Static Configuration entries  = 3                   
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, MMS, and RTSP).

•Proxy-style requests in HTTP, FTP, HTTPS, MMS, 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 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 Domain Name System (DNS) must be configured in order to support all incoming proxy requests.

Modifying Multiport Configurations

To disable HTTP, HTTPS FTP, RTSP, and MMS incoming proxy services use the 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
WCCP Flow Protection

WCCP flow protection is a mechanism which ensures that no existing flows are broken when a new Content Engine is brought online.

When transparent traffic interception or redirection first commences, WCCP flow protection ensures that no existing HTTP flows are broken by allowing those preexisting HTTP flows already established to continue on.

WCCP flow protection also ensures that when a new Content Engine joins an existing Content Engine cluster, existing flows serviced by preexisting Content Engines in the cluster will continue to receive those existing flows.

The mechanisms used by WCCP flow protection result in all of the benefits of maintaining per flow state information in a centralized location but without the overhead, scaling issues, and redundancy or resiliency issues (for example, asymmetrical traffic flows) associated with keeping per flow state information in the switching layer.

Use the wccp flow-redirect command to implement WCCP flow protection. This command works with WCCP Version 2 only. This flow protection feature is designed to keep the TCP flow intact as well as to not overwhelm Content Engines when they are first started up or are reassigned new traffic. This feature also has a slow start mechanism whereby the Content Engines try to take a load appropriate for their capacity.

This example shows how to enable WCCP flow protection in a Content Engine.
ContentEngine(config)# wccp flow-redirect enable
IP Spoofing

With typical transparent caching, a user issues an HTTP request from a web browser. The request is transparently intercepted and redirected to the Content Engine. The Content Engine accepts the incoming TCP connection from the web browser, determines that the request is for an object not in storage (cache miss), and issues a request for the object from the origin web server. When the Content Engine contacts the origin web server, it uses the Content Engine's own IP address instead of the client's IP address on behalf of which the Content Engine is making the request.

In contrast, with IP spoofing, the transparent redirection process can enable the Content Engine to send out the client's IP address for authentication purposes on origin web servers. You can enable this feature with the wccp spoof-client-ip enable global configuration command. You can disable this feature with the no wccp spoof-client-ip enable command.

IP spoofing is recommended in the following scenarios:

•Logging of user IP addresses

•Filtering based on user IP addresses

•Policy-based routing to provide some users better service than others

Note The Content Engine can also use authentication traffic bypass to automatically generate a dynamic access list and connect to a server with the user's IP address for selected client/server pairs. See the "Authentication Traffic Bypass" section for more information.

Note You can also forward the client's IP address without turning IP spoofing on by using the http append x-forwarded-for-header command on the Content Engine serving the request.

In normal transparent redirection using a WCCP-enabled router, the router intercepts packets sent by the client only. It then forwards the request to the Content Engine. With IP spoofing, the router also intercepts packets from the server that are destined for the client's IP address while redirecting them to the Content Engine.

Note To enable IP spoofing, the clients and Content Engines must be on separate subnets.

You must disable traffic redirection on the router interface connected to the Content Engine to avoid loopbacks as the router tries to send the packet with the source IP address back to the Content Engine. You must also enable traffic redirection on the router interface connected to the clients.

See the "Configuring the Content Engine for IP Spoofing" section and the "Configuring the Router for IP Spoofing" section for more information on the configuration steps needed to configure IP spoofing. In this configuration scenario, the Content Engine and the requesting clients are on different subnets, as shown in Figure 5-7.

Note In the scenario shown in Figure 5-7, web-cache service (service number 0) and a user-configurable service (service number 95), are used. The user-configurable service numbers range from 90 to 97. See Table B-1 of "Web Cache Communication Protocol Version 2," for a list of configurable services in the Content Engine.

Figure 5-7 Content Engine and Clients on Different Subnets for IP Spoofing

Configuring the Content Engine for IP Spoofing

To configure the Content Engine for IP spoofing, perform the following steps while logged in to the Cache software in global configuration mode:
Command

Purpose
Step 1
contentengine(config)# wccp version 2
Ensures that the Content Engine is running WCCP Version 2.
Step 2
contentengine(config)# wccp router-list 1 
10.10.20.1 
Configures a router list.
Step 3
contentengine(config)# wccp port-list 1 80
Configures port list 1 to be associated with a WCCP service group through port 80.
Step 4
contentengine(config)# wccp service-number 95 
router-list-num 1 port-list-num 1 application 
cache hash-source-ip match-source-port
Configures service number 95, associates router list, port list 1, and hashing parameters with the source IP address and the source port.
Step 5
contentengine(config)# wccp web-cache 
router-list-num 1
Informs the routers in the specified router list that the Content Engine is accepting web cache service.
Step 6
contentengine(config)# wccp spoof-client-ip enable
Enables client IP spoofing.
Step 7
contentengine(config)# exit
Exits global configuration mode.
Step 8
contentengine# write memory
Writes running configurations to nonvolatile memory.
Note If you have a Content Engine farm and you are using weight asssignments within this farm, you must make sure that these weight assignments for the services assigned to IP spoofing for both outbound and inbound packets are equal on all Content Engines to prevent a break in the TCP connection. Use the wccp service-number servnumber router-list-num num port-list-num port application cache weight percentage command to establish a weight for these services if needed. By default, the Content Engine farm hashes appropriately with IP spoofing turned on, so assigning weights to services is not needed.

Configuring the Router for IP Spoofing

To configure the router for IP spoofing, perform the following steps while logged in to the router in global configuration mode:
Command

Purpose
Step 1
router(config)# ip wccp web-cache
Instructs the router to run the web cache service.
Step 2
router(config)# ip wccp 95
Enables service group 95 on the router.
Step 3
router(config-if)# ip wccp web-cache redirect out
Enables WCCP redirection on the interface going out to the origin web server with the service that hashes on the destination IP address. (See Figure 5-7.)
Step 4
router(config-if)# ip wccp 95 redirect out
Enables WCCP redirection on the interface going out to the clients with the service that hashes on the source IP address. (See Figure 5-7.)
Step 5
router(config-if)# ip wccp redirect exclude in
Disables WCCP redirection on the interface connected to the Content Engine. (See Figure 5-7.)
Step 6
router(config-if)# exit 
Exits global configuration mode.
Configuration Examples—IP Spoofing

This example shows a Content Engine and a router configured for IP spoofing.

Content Engine Configuration

:
ContentEngine# show running-config
hostname ContentEngine
!
http proxy incoming 8080
!
ip domain-name cisco.com
!
primary-interface FastEthernet 0/0
!
interface FastEthernet 0/0
 ip address 10.20.0.2 255.255.0.0
 exit
interface FastEthernet 0/1
 shutdown
 exit
!
!
ip default-gateway 10.20.0.1
!
logging console priority debug
!
wccp router-list 1 10.20.0.1
wccp port-list 1 80
wccp web-cache router-list-num 1
wccp service-number 95 router-list-num 1 port-list-num 1 application cache hash-source-ip 
match-source-port
wccp version 2
wccp spoof-client-ip enable
!
username admin password 1 XTPu6hUoZVYxQ
username admin privilege 15
!
authentication login local enable primary
authentication configuration local enable primary
A sample configuration of the commands needed on the WCCP-enabled router is as follows:
Router# show running-config
Building configuration...
Current configuration : 1240 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname rtr
!
boot system flash:flash-is-mz.122-6
enable password xxxxxx
!
ip subnet-zero
ip wccp 95
ip wccp web-cache
no ip domain-lookup
ip domain-name cisco.com
!
interface Ethernet0
 no ip address
 media-type 10BaseT
!
interface Ethernet1                                    
<<<*** Interface connected to the external gateway.
 ip address 10.1.1.203 255.255.255.0
 ip wccp web-cache redirect out
media-type 10BaseT
!
interface Ethernet2                                     
<<<*** Interface connected to the clients.
 ip address 10.20.210.1 255.255.255.0
 ip wccp 95 redirect out
 media-type 10BaseT
!
interface Ethernet3
 no ip address
 media-type 10BaseT
!
interface Ethernet4
 no ip address
 shutdown
 media-type 10BaseT
!
interface Ethernet5
 no ip address
 shutdown
 media-type 10BaseT
!
interface FastEthernet0                                     
<<<*** Interface connected to the Content Engines.
 ip address 10.20.0.1 255.255.255.0
 ip wccp redirect exclude in
 full-duplex
!
ip default-gateway 10.1.1.1
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip http server
ip pim bidir-enable
!
!
line con 0
 exec-timeout 0 0
line aux 0
 exec-timeout 0 0
line vty 0 4
 exec-timeout 0 0
 password xxxxxx
 no login
line vty 5 7
 login
!
end
Router#
Accelerated WCCP Layer 2 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 Policy Feature Card (PFC) Redirection and has been available since Cisco IOS Release 12.1(1)E. 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
Configuring Transparent Caching with the Cisco CSS 11000 Series Switch

The Cisco CSS 11000 series switch (hereafter called the CSS switch) can support transparent caching and conventional proxy caching. It also supports web acceleration through intelligent reverse proxy caching. The CSS switch provides several load-balancing methods depending on how you want to distribute data over the Content Engines (for example, entire URL, URL string, entire domain name, or domain string). The CSS switch also builds a list of known cacheable objects. The list may be modified, but much of the work is reduced by the Content Engine caching capabilities.

Transparent caching deploys Content Engines that act as cache servers which are transparent to the browsers. You do not have to configure browsers to point to a cache server. Cache servers duplicate and store inbound Internet data previously requested by clients.

When you configure transparent caching on the CSS switch, the switch intercepts and redirects outbound client requests for Internet data to the cache servers on your network. The cache either returns the requested content if it has a local copy or sends a new request to the origin server for the information. If all cache servers are unavailable in a transparent cache configuration, the CSS switch allows all client requests to progress to the origin servers.

A CSS switch is introduced between the user and the Content Engine. (See Figure 5-8.) You can configure the CSS switch to dynamically analyze the content and determine if it is cacheable or not. If it is cacheable, the CSS switch directs it to the cache service. If it is not cacheable, the CSS switch sends it directly to the origin server.

Figure 5-8 Transparent Caching Network Diagram with the CSS 11000 Series Switch

The transparent cache servers will be stocked with static data (that is, HTML, Audio Video Interleaved [AVI], Joint Photographic Experts Group [JPEG], or Graphics Interchange Format [GIF]) files. Any files that are not cacheable will be passed directly to the server.

Requests for cacheable content are load-balanced over the two cache servers based on the URL. In a real-world scenario, they could also be balanced based on the domain name.

Content Engine CLI Commands

The http l4-switch enable command permits the Content Engine to transparently receive Layer 4 redirected traffic from Layer 4-enabled switches such as the CSS switch. See the "Transparent Caching Sample Configuration Output" section for specific configuration information.

Enabling Transparent Caching Using the CSS Switch

Use the following commands to help you configure serv1 as a transparent caching service using the CSS switch. Ensure that you have configured interfaces, services, owners, VLANs and content rules prior to configuring caching with the CSS switch. Refer to the Content Services Switch Basic Configuration Guide for further information on how to configure these attributes.

For a complete description of each command, refer to the Content Services Switch Command Reference.

Step 1 Add service serv1 reserved for transparent caching
CS150(config)# add service serv1
CS150(config-service[serv1])#
Step 2 Specify transparent caching service type for serv1.
CS150(config-service[serv1])# type transparent cache
Step 3 Create an extension qualifier list (EQL) in which you specify which content types the CSS switch is to cache.
CS150(config)# eql graphics
CS150(config-eql[graphics]# 
Step 4 Describe the EQL by entering a quoted text string with a maximum length of 64 characters.
CS150(config-eql[graphics]# description "This EQL specifies cacheable graphic files"
Step 5 Specify the extension for content you that want the CSS switch to cache. Enter a text string containing from 1 to 8 characters.
CS150(config-eql[graphics]# extension jpeg
You can also provide here a description of the extension type. Enter a quoted text string with a maximum length of 64 characters.
CS150(config-eql[graphics]# extension jpeg "This is a graphics file"
CS150(config-eql[graphics]# exit
CS150(config)#
Step 6 Specify the EQL in a content rule to match all content requests with the desired extension.
CS150(config-owner-content[cisco.com-rule1])# url "/*" eql graphics
Step 7 Configure the load-balancing method for the cache content rule. The default is round-robin.
CS150(config-owner-content[cisco.com-rule1])# balance domain
Step 8 Specify a failover type (bypass, linear, next) to define how the CSS switch handles content requests when a service fails. The default is linear.
CS150(config-owner-content[cisco.com-rule1])# failover bypass
Step 9 Display the EQL configuration.
CS150(config-owner-content[cisco.com-rule1])# show eql
Step 10 Display the content rule to show the cache configuration.
CS150(config-owner-content[cisco.com-rule1])# show rule
Transparent Caching Sample Configuration Output

The following is a very basic CSS switch configuration output for transparent caching using CLI commands. Use the show running-config CLI command to display the switch configuration parameters after provisioning the CSS switch.
!Generated MAY 19 15:36:34
!Active version: ap0310029s
prompt TransCache
configure
!************************* INTERFACE *************************
interface ethernet-12	
  bridge vlan 2
!************************** CIRCUIT **************************
circuit VLAN1
  ip address 10.1.1.254 255.255.255.0
circuit VLAN2
  ip address 192.168.1.254 255.255.255.0
!************************** SERVICE **************************
service Origin1		 
  ip address 10.1.1.1	
  keepalive frequency 60 
service TCacheServer1
  ip address 10.1.1.11
  type transparent-cache	
  port 80
  active
service TCacheServer2
  ip address 10.1.1.12
  type transparent-cache	
  port 80
  active
!**************************** EQL ****************************
eql Cacheable
  description "This EQL contains extensions of cacheable content"
  extension pdf "Acrobat"
  extension fdf "Acrobat Forms Document"
  extension au "Sound audio/basic"
  extension bmp "Bitmap Image"
  extension z "Compressed data application/x-compress"
  extension gif "GIF Image image/gif"
  extension html "Hypertext Markup Language text/html"
  extension js "Java script application/x-javascript"
  extension mocha
  extension jpeg "JPEG image image/jpeg"
  extension jpg
  extension jpe
  extension jfif
  extension pjpeg
  extension pjp
  extension mp2 "MPEG Audio audio/x-mpeg"
  extension mpa
  extension abs
  extension mpeg "MPEG Video video/mpeg"
  extension mpg
  extension mpe
  extension mpv
  extension vbs
  extension m1v
  extension pcx "PCX Image"
  extension txt "Plain text text/plain"
  extension text
  extension mov "QuickTime video/quicktime"
  extension tiff "TIFF Image image/tiff"
  extension tar "Unix Tape Archive application/x-tar"
  extension pcx "PCX Image"
  extension txt "Plain text text/plain"
  extension text
  extension mov "QuickTime video/quicktime"
  extension tiff "TIFF Image image/tiff"
  extension tar "Unix Tape Archive application/x-tar"
  extension avi "Video for Windows video/x-msvideo"
  extension wav "Wave File audio/x-wav"
  extension gz "application/x-gzip"
  extension zip "ZIP file application/x-zip-compressed"
!*************************** OWNER ***************************
owner cisco.com
  content L5_Transparent
    protocol tcp			
    port 80				
    url "/*" eql Cacheable		
    balance urlhash			
    add service TCacheServer1	
    add service TCacheServer2	
    active
Note There is no virtual IP address because the switch is transparent (not visible to the client).

Note Anything that is cacheable should be load balanced using the URL and sent to the cache servers.