Configuring WCCP

WCCP uses Cisco Content Engines (or other content engines running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time.

WCCP enables Cisco IOS XE routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users do not need to configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a content engine. The word "transparent" in this case means that the end user does not know that a requested file (such as a web page) came from the content engine instead of from the originally specified server.

When a content engine receives a request, it attempts to service it from its own local cache. If the requested information is not present, the content engine issues its own request to the originally targeted server to get the required information. When the content engine retrieves the requested information, it forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs.

WCCP enables a series of content engines, called a content engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their content engines to manage heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cluster member to work in parallel, resulting in linear scalability. Clustering content engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 content engines to scale to your desired capacity.

WCCP uses either generic routing encapsulation or Layer 2 (L2) to redirect or return IP traffic. When WCCP forwards traffic via GRE, the redirected packets are encapsulated within a GRE header. The packets also have a WCCP redirect header. When WCCP forwards traffic using L2, the original MAC header of the IP packet is overwritten and replaced with the MAC header for the WCCP client.

Using L2 as a forwarding method allows direct forwarding to the content engine without further lookup. Layer 2 redirection requires that the router and content engines are directly connected, that is, on the same IP subnetwork.

When WCCP returns traffic via GRE, the returned packets are encapsulated within a GRE header. The destination IP address is the address of the router and the source address is the address of the WCCP client. When WCCP returns traffic via L2, the original IP packet is returned without any added header information. The router to which the packet is returned will recognize the source of the packet and prevent redirection.

The WCCP redirection method does not have to match the return method.

L2 forwarding, return, or redirection are typically used for hardware accelerated platforms. On Cisco ASR 1000 Series Routers, both the GRE and L2 forward/return methods use the hardware, so there is not any significant performance degradation between them.

For content engines running Application and Content Networking System (ACNS) software, use the wccp custom-web-cache command with the l2-redirect keyword to configure L2 redirection. For content engines running Cisco Wide Area Application Services (WAAS) software, use the wccp tcp-promiscuous command with the l2-redirect keyword to configure L2 redirection.

For more information on Cisco ACNS commands used to configure Cisco Content Engines, see the Cisco ACNS Software Command Reference, Release 5.5.13.

For more information on WAAS commands used to configure Cisco Content Engines, see the Cisco Wide Area Application Services Command Reference (Software Versions 4.2.1).

The WCCP Mask Assignment feature enables mask assignment as the load-balancing method for a WCCP service.

For content engines running Application and Content Networking System (ACNS) software, use the wccp web-cache command with the mask-assignkeywords to configure mask assignment. For content engines running Cisco Wide Area Application Services (WAAS) software, use the wccp tcp-promiscuouscommand with the mask-assign keyword to configure mask assignment.

For more information on Cisco ACNS commands used to configure Cisco Content Engines, see the Cisco ACNS Software Command Reference, Release 5.5.13.

For more information on WAAS commands used to configure Cisco Content Engines, see the Cisco Wide Area Application Services Command Reference (Software Versions 4.2.1).

WCCP implementation on the Cisco ASR 1000 Series Routers is hardware accelerated by default.

You do not need to configure the ip wccp web-cache accelerated command on Cisco ASR routers to enable hardware acceleration.

Multiple routers can use WCCPv2 to service a content engine cluster. The figure below illustrates a sample configuration using multiple routers.

Figure 1

Cisco Content Engine Network Configuration Using WCCPv2

The subset of content engines within a cluster and routers connected to the cluster that are running the same service is known as a service group . Available services include TCP and UDP redirection.

WCCPv2 requires that each content engine be aware of all the routers in the service group. To specify the addresses of all the routers in a service group, you must choose the following method:

• Unicast--A list of router addresses for each of the routers in the group is configured on each content engine. In this case the address of each router in the group must be explicitly specified for each content engine during configuration.
• Multicast--A single multicast address is configured on each content engine. In the multicast address method, the content engine sends a single-address notification that provides coverage for all routers in the service group. For example, a content engine could indicate that packets should be sent to a multicast address of 224.0.0.100, which would send a multicast packet to all routers in the service group configured for group listening using WCCP (see the ip wccp group-listen interface configuration command for details).

The multicast option is easier to configure because you need only specify a single address on each content engine. This option also allows you to add and remove routers from a service group dynamically, without needing to reconfigure the content engines with a different list of addresses each time.

The following sequence of events details how WCCPv2 configuration works:

1. Each content engine is configured with a list of routers.
2. Each content engine announces its presence and a list of all routers with which it has established communications. The routers reply with their view (list) of content engines in the group.
3. When the view is consistent across all content engines in the cluster, one content engine is designated as the lead and sets the policy that the routers need to deploy in redirecting packets.

WCCPv2 allows redirection of traffic other than HTTP (TCP port 80 traffic), including a variety of UDP and TCP traffic. WCCPv2 supports the redirection of packets intended for other ports, including those used for proxy-web cache handling, File Transfer Protocol (FTP) caching, FTP proxy handling, web caching for ports other than 80, and Real Audio, video, and telephony applications.

To accommodate the various types of services available, WCCPv2 introduces the concept of multiple service groups. Service information is specified in the WCCP configuration commands using dynamic services identification numbers (such as 98) or a predefined service keyword (such as web-cache). This information is used to validate that service group members are all using or providing the same service.

The content engines in a service group specify traffic to be redirected by protocol (TCP or UDP) and up to eight source or destination ports. Each service group has a priority status assigned to it. The priority of a dynamic service is assigned by the content engine. The priority value is in the range of 0 to 255 where 0 is the lowest priority. The predefined web cache service has an assigned priority of 240.

WCCPv2 allows multiple routers to be attached to a cluster of cache engines. The use of multiple routers in a service group allows for redundancy, interface aggregation, and distribution of the redirection load. WCCPv2 supports up to 32 routers per service group. Each service group is established and maintained independently.

WCCPv2 provides optional authentication that enables you to control which routers and content engines become part of the service group using passwords and the HMAC MD5 standard. Shared-secret MD5 one-time authentication (set using the ip wccp [password [0 | 7] password] global configuration command) enables messages to be protected against interception, inspection, and replay.

If a content engine is unable to provide a requested object it has cached due to error or overload, the content engine will return the request to the router for onward transmission to the originally specified destination server. WCCPv2 provides a check on packets that determines which requests have been returned from the content engine unserviced. Using this information, the router can then forward the request to the originally targeted server (rather than attempting to resend the request to the content engine cluster). This process provides error handling transparency to clients.

Typical reasons why a content engine would reject packets and initiate the packet return feature include the following:

• Instances when the content engine is overloaded and has no room to service the packets
• Instances when the content engine is filtering for certain conditions that make caching packets counterproductive (for example, when IP authentication has been turned on)

The WCCP VRF Support feature enhances the existing WCCPv2 protocol by implementing support for virtual routing and forwarding (VRF). Inter-VRF redirection is not supported.

The WCCP VRF Support feature allows service groups to be configured on a per VRF basis in addition to those defined globally.

Along with the service identifier, the VRF of WCCP protocol packets arriving at the router is used to associate cache-engines with a configured service group.

The interface on which redirection is applied, the interface which is connected to cache engine, and the interface on which the packet would have left if it had not been redirected must be in the same VRF.

In Cisco IOS XE releases that support the WCCP VRF Support feature, the use of GRE redirection results in the creation of new tunnel interfaces. You can display these tunnel interfaces by entering the show ip interface brief | include tunnel command:

Router# show ip interface brief | include tunnel
  
Tunnel0                172.16.0.1      YES unset  up                    up      
Tunnel1                172.16.0.1      YES unset  up                    up      
Tunnel2                172.16.0.1      YES unset  up                    up      
Tunnel3                172.16.0.1      YES unset  up                    up      
Router#

The tunnel interfaces are automatically created in order to process outgoing GRE-encapsulated traffic for WCCP. The tunnel interfaces appear when a content engine connects and requests GRE redirection. The tunnel interfaces are not created directly by WCCP, but are created indirectly via a tunnel application programming interface (API). WCCP does not have direct knowledge of the tunnel interfaces, but can redirect packets to them, resulting in the appropriate encapsulation being applied to the packets. After the appropriate encapsulation is applied, the packet is then sent to the content engine.

Note	The tunnel interfaces are not used to connect with incoming WCCP GRE return packets.

One tunnel is created for each service group that is using GRE redirection. One additional tunnel is created to provide an IP address that allows the other tunnel group interfaces to be unnumbered but still enabled for IPv4.

You can confirm the connection between the tunnels and WCCP by entering the show tunnel groups wccp command:

Router# show tunnel groups wccp

WCCP : service group 0 in "Default", ver v2, assgnmnt: hash-table 
   intf: Tunnel0, locally sourced
 WCCP : service group 317 in "Default", ver v2, assgnmnt: hash-table 
   intf: Tunnel3, locally sourced
 WCCP : service group 318 in "Default", ver v2, assgnmnt: hash-table 
   intf: Tunnel2, locally sourced

You can display additional information about each tunnel interface by entering the show tunnel interface interface-number command:

Router# show tunnel interface t0

Tunnel0
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 10.1.1.80
   Application ID 2: WCCP : service group 0 in "Default", ver v2, assgnmnt: hash-table 
   Linestate - current up
   Internal linestate - current up, evaluated up

Router# show tunnel interface t1

Tunnel1
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 172.16.0.1
   Application ID 2: unspecified
   Linestate - current up
   Internal linestate - current up, evaluated up

Router# show tunnel interface t2

Tunnel2
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 10.1.1.80
   Application ID 2: WCCP : service group 318 in "Default", ver v2, assgnmnt: hash-table 
   Linestate - current up
   Internal linestate - current up, evaluated up

Router# show tunnel interface t3

Tunnel3
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 10.1.1.80
   Application ID 2: WCCP : service group 317 in "Default", ver v2, assgnmnt: hash-table 
   Linestate - current up
   Internal linestate - current up, evaluated up
Router#

Note that the service group number shown in the examples is the internal tunnel representation of the WCCP service group number. Group 0 is the web-cache service. To determine the dynamic services, subtract 256 from the displayed service group number to convert to the WCCP service group number. For interfaces that are used for redirection, the source address shown is the WCCP router ID.

You can display information about the connected content engines and encapsulation, including software packet counters, by entering the show adjacency [tunnel-interface] [encapsulation] [detail] [internal] command:

Router# show adjacency t0  
           
Protocol Interface                 Address
IP       Tunnel0                   10.1.1.82(3)

Router# show adjacency t0 encapsulation 

Protocol Interface                 Address
IP       Tunnel0                   10.1.1.82(3)
  Encap length 28
  4500000000000000FF2F7D2B1E010150
  1E0101520000883E00000000
  Provider: TUNNEL
  Protocol header count in macstring: 3
    HDR 0: ipv4
       dst: static, 10.1.1.82
       src: static, 10.1.1.80
      prot: static, 47
       ttl: static, 255
        df: static, cleared
      per packet fields: tos ident tl chksm
    HDR 1: gre
      prot: static, 0x883E
      per packet fields: none
    HDR 2: wccpv2
       dyn: static, cleared
      sgID: static, 0
      per packet fields: alt altB priB

Router# show adjacency t0 detail 

Protocol Interface                 Address
IP       Tunnel0                   10.1.1.82(3)
                                   connectionid 1
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 1
                                   Encap length 28
                                   4500000000000000FF2F7D2B1E010150
                                   1E0101520000883E00000000
                                   Tun endpt
                                   Next chain element:
                                    IP adj out of Ethernet0/0, addr 10.1.1.82
Router# show adjacency t0 internal

Protocol Interface                 Address
IP       Tunnel0                   10.1.1.82(3)
                                   connectionid 1
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 1
                                   Encap length 28
                                   4500000000000000FF2F7D2B1E010150
                                   1E0101520000883E00000000
                                   Tun endpt
                                   Next chain element:
                                    IP adj out of Ethernet0/0, addr 10.1.1.82
                                    parent oce 0x4BC76A8
                                    frame originated locally (Null0)
                                   L3 mtu 17856
                                   Flags (0x2808C4)
                                   Fixup enabled (0x40000000)
                                         GRE WCCP redirection
                                   HWIDB/IDB pointers 0x55A13E0/0x35F5A80
                                   IP redirect disabled
                                   Switching vector: IPv4 midchain adj oce
                                   IP Tunnel stack to 10.1.1.82 in Default (0x0)
                                    nh tracking enabled: 10.1.1.82/32
                                    IP adj out of Ethernet0/0, addr 10.1.1.82
                                   Adjacency pointer 0x4BC74D8
                                   Next-hop 10.1.1.82
Router#

WCCP intercepts IP packets and redirects those packets to a destination other than the destination that is specified in the IP header. Typically the packets are redirected from a web server on the Internet to a web cache that is local to the destination.

Occasionally a web cache cannot manage the redirected packets appropriately and returns the packets unchanged to the originating router. These packets are called bypass packets and are returned to the originating router using either Layer 2 forwarding without encapsulation (L2) or encapsulated in generic routing encapsulation (GRE). The router decapsulates and forwards the packets normally. The VRF associated with the ingress interface (or the global table if there is no VRF associated) is used to route the packet to the destination.

GRE is a tunneling protocol developed by Cisco that encapsulates packet types from a variety of protocols inside IP tunnels, creating a virtual point-to-point link over an IP network.

In applications where packet flows are intercepted and redirected by a Cisco IOS router to external WCCP client devices, it may be necessary to block the packet flows for the application when a WCCP client device is not available. This blocking is achieved by configuring a WCCP closed service. When a WCCP service is configured as closed, WCCP discards packets that do not have a WCCP client registered to receive the redirected traffic.

By default, WCCP operates as an open service, wherein communication between clients and servers proceeds normally in the absence of an intermediary device.

The ip wccp service-list command can only be used for closed-mode services. Use the service-list keyword and service-access-list argument to register an application protocol type or port number.

When there is a mismatch between the service-list ACL and the definition received from a cache engine, the service is not allowed to start.

When WCCP is enabled for redirection on an ingress interface, the packets are redirected by WCCP and instead egress on an interface other than the destination that is specified in the IP header. The packets are still subject to ACLs configured on the ingress interface. However, redirection can cause the packets to bypass the ACL configured on the original egress interface. Packets that would have been dropped because of the ACL configured on the original egress interface can be sent out on the redirect egress interface. This poses a possible security problem. Enabling the WCCP Outbound ACL check feature ensures that redirected packets are subject to any ACL conditions configured on the original egress interface.

WCCP is a component of Cisco IOS XE software that redirects traffic with defined characteristics from its original destination to an alternative destination. The typical application of WCCP is to redirect traffic bound for a remote web server to a local web cache to improve response time and optimize network resource usage.

The nature of the selected traffic for redirection is defined by service groups specified on content engines and communicated to routers by using WCCP. The current implementation of WCCP in Cisco IOS XE software allows for a maximum of 256 service groups across all VRFs.

WCCPv2 supports up to 32 routers per service group. Each service group is established and maintained independently.

WCCPv2 uses service groups based on logical redirection services, deployed for intercepting and redirecting traffic. The standard service is web cache, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the content engines. This service is referred to as a well-known service, because the characteristics of the web cache service are known by both the router and content engines. A description of a well-known service is not required beyond a service identification. To specify the standard web cache service, use the ip wccp command with the web-cache keyword.

Note	More than one service can run on a router at the same time, and routers and content engines can be part of multiple service groups at the same time.

Figure 2

WCCP Service Groups

The dynamic services are defined by the content engines; the content engine instructs the router which protocol or ports to intercept, and how to distribute the traffic. The router itself does not have information on the characteristics of the dynamic service group's traffic, because this information is provided by the first content engine to join the group. In a dynamic service, up to eight ports can be specified within a single protocol.

Cisco Content Engines, for example, use dynamic service 99 to specify a reverse-proxy service. However, other content engine devices may use this service number for some other service. The configuration information in this document deals with enabling general services on the Cisco ASR 1000 Series Routers.

An interface may be configured with more than one WCCP service. When more than one WCCP service is configured on an interface, the precedence of a service depends on the relative priority of the service compared to the priority of the other configured services. Each WCCP service has a priority value as part of its definition. When an interface is configured with more than one WCCP service, the precedence of the packets is matched against service groups in priority order.

Note	The priority of a WCCP service group cannot be configured via Cisco IOS software.

With the ip wccp check services all command, WCCP can be configured to check all configured services for a match and perform redirection for those services if appropriate. The caches to which packets are redirected can be controlled by a redirect ACL as well as by the service priority.

If no WCCP services are configured with a redirect ACL, the services are considered in priority order until a service is found that matches the IP packet. If no services match the packet, the packet is not redirected. If a service matches the packet and the service has a redirect ACL configured, then the IP packet will be checked against the ACL. If the packet is rejected by the ACL, the packet will not be passed down to lower priority services unless the ip wccp check services all command is configured. When the ip wccp check services all command is configured, WCCP will continue to attempt to match the packet against any remaining lower priority services configured on the interface.

WCCP uses a router ID in its control messages and the router ID serves as a means by which a WCCP client can identify a particular WCCP server. The router ID is treated as an IPv4 address and may also be used as the source address of any WCCP-generated GRE frames. Prior to the WCCP Configurable Router ID feature, WCCP selects a router ID using an automatic mechanism; the highest reachable IPv4 address on the system is used as the WCCP router ID. The highest IPv4 address on the system is not always the best choice as the router ID or as the source address of GRE frames. A change in addressing information on the system may cause the WCCP router ID to change unexpectedly. During this changeover period, WCCP clients briefly advertise the existence of two routers (the old router ID and the new Router ID) and GRE frames are sourced from a different address.

The WCCP Configurable Router ID feature enables you to define a WCCP source interface. The IP address of this configured source interface is then used as the preferred WCCP router ID and WCCP GRE source address. When a WCCP router ID is manually configured, router IDs are not automatically generated when the current router ID is no longer valid and the router ID does not change when another IP address is added to the system. The router ID changes only when a new router ID is manually configured using the ip wccp source-address command.

To redirect traffic using WCCP to a router running WAAS software that is also configured with NAT, enable the ip nat inside command on the WAAS interface. If you are not able to configure the ip nat inside command on the WAAS interface, disable Cisco Express Forwarding. You must also update the WCCP redirect ACL to include a private address to ensure that pretranslated traffic is redirected.

The WCCP Fast Timers feature enables WCCP to establish redirection more quickly when a WCCP client is added to a service group or when a WCCP client fails.

WCCP routers and WCCP clients exchange keepalive messages at a fixed interval. Prior to the introduction of the WCCP Fast Timers feature, the WCCP message interval is fixed at 10 seconds. The WCCP Fast Timers feature enables use of message intervals ranging from .5 seconds to 60 seconds and a timeout value scaling factor of 1 to 5.

The WCCP message interval capability introduced by the WCCP Fast Timers feature defines the transmission interval that WCCP clients and WCCP routers use when sending keepalive messages and defines a scaling factor used when calculating the timeout value. The WCCP router uses the timeout value to determine if a WCCP client is no longer available and to redirect traffic as a result.

The WCCP router enforces a single message interval per service group. WCCP clients with incompatible message intervals are prevented from joining a service group.

If a default message interval that is smaller than the default 10 seconds is used, there will be an increase in CPU usage.

You can use the show ip wccp service -number detail command to display information about the message interval settings being used in a WCCP service group. No output is displayed if the default 10-second message interval is used.

If the counters suggest that the level of bypass traffic is high, the next step is to examine the bypass counters in the content engine and determine why the content engine is choosing to bypass the traffic. You can log in to the content engine console and use CLI to investigate further. The counters allow you to determine the percent of traffic being bypassed.

Perform this task to configure WCCP.

Until you configure a WCCP service using the ip wccp {web-cache | service-number} global configuration command, WCCP is disabled on the router. The first use of a form of the ip wccp command enables WCCP. By default WCCPv2 is used for services.

Using theip wccp web-cache password command, you can set a password for a router and the content engines in a service group. MD5 password security requires that each router and content engine that wants to join a service group be configured with the service group password. The password can consist of up to eight characters. Each content engine or router in the service group will authenticate the security component in a received WCCP packet immediately after validating the WCCP message header. Packets failing authentication will be discarded.

Note	WCCPv1 is not supported on the Cisco ASR 1000 Series Routers.

1.    enable

2.    configure terminal

3.    ip wccp [vrf vrf-name] {web-cache | service-number} | [group-address group-address] [redirect-list access-list] [group-list access-list] [password password]

4.    ip wccp [vrf vrf-name] source-interface source-interface

5.    interface type number

6.    ip wccp [vrf vrf-name] {web-cache | service-number} redirect {out | in}

7.    exit

8.    interface type number

9.    ip wccp redirect exclude in

1.    enable

2.    configure terminal

3.   Enter one of the following commands:

4.    ip wccp check services all

5.    ip wccp [vrf vrf-name ] {web-cache | service-number}

6.    exit

1.    enable

2.    configure terminal

3.    ip multicast-routing [vrf vrf-name] [distributed]

4.    ip wccp [vrf vrf-name] {web-cache | service-number} group-address multicast-address

5.    interface type number

6.    ip pim {sparse-mode | sparse-dense-mode | dense-mode [proxy-register {list access-list | route-map map-name}]}

7.    ip wccp [vrf vrf-name] {web-cache | service-number} group-listen

1.    enable

2.    configure terminal

3.    access-list access-list-number remark remark

4.    access-list access-list-number permit {source [source-wildcard] | any} [log]

5.    access-list access-list-number remark remark

6.    access-list access-list-number deny {source [source-wildcard] | any} | [log]

7.    Repeat some combination of Steps 3 through 6 until you have specified the sources on which you want to base your access list.

8.    ip wccp [vrf vrf-name] web-cache group-list access-list

9.    ip wccp [vrf vrf-name] web-cache redirect-list access-list

1.    enable

2.    configure terminal

3.    ip wccp [vrf vrf-name] {web-cache | service-number} [group-address multicast-address] [redirect-list access-list] [group-listaccess-list] [password password]

4.    ip wccp check acl outbound

5.    exit

1.    enable

2.    configure terminal

3.    interface type number

4.    ip nat inside

5.    ip wccp service-number redirect in

6.    exit

7.    interface type number

8.    ip nat outside

9.    ip wccp service-number redirect in

10.    exit

11.    interface type number

12.    ip nat inside

13.    ip wccp redirect exclude in

1.    enable

2.    debug ip wccp {default | vrf vrf-name {events | packets [control]} | events | packets [bypass | control | redirect] | platform | subblocks}

3.    debug platform hardware qfp active feature wccp {{client | lib-client {all | error | info | trace | warning}} | datapath all}

4.    debug platform software wccp {configuration | counters | detail | messages}

5.    show platform software wccp [service-number counters | [slot [service-number [access-list] | cache-info | interface | statistics | web-cache [access-list]] | vrf vrf-identifier {service-number [access-list] | web-cache [access-list]}]] | interface counters | statistics | [vrf vrf-identifier {service-number counters | web-cache counters}] | web-cache counters]

6.    show platform hardware qfp active feature wccp [vrf vrf-id] service id service-id

7.    show ip wccp global [counters]

8.    show ip interface

9.    more system:running-config

10.    configure terminal

11.    platform trace runtime slot slot bay bay process forwarding-manager module wccp level {level}