Your software release might not support all the features documented in this module. For the latest caveats and feature information, see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "New and Changed Information"chapter or the Feature History table in this chapter.

WCCPv2 enables the Cisco NX-OS router to transparently redirect packets to cache engines. WCCPv2 does not interfere with normal router operations. Using WCCPv2, the router can redirect requests on configured interfaces to cache engines rather than to intended host sites. With WCCPv2, the router can balance traffic loads across a cluster of cache engines (cache cluster) and ensure fault-tolerant and fail-safe operation in the cluster. As you add or delete cache engines from a cache cluster, WCCPv2 dynamically redirects the packets to the currently available cache engines.

WCCPv2 accepts the traffic at the cache engine and establishes the connection with the traffic originator (the client). The cache engine acts as if it were the original destination server. If the requested object is not available on the cache engine, the cache engine establishes its own connection out to the original destination server to retrieve the object.

Until Release 8.1(2), WCCPv2 is supported only on the Layer3 or SVI interfaces, for Cisco Nexus 7000 Series Switches.

Beginning from Release 8.2(1), WCCPv2 feature is supported on L3VNI BDI interfaces as an ingress feature. This feature is supported on Cisco Nexus 7000 Series and 7700 Series Switches on M3 and F3 modules only.

WCCPv2 communicates between routers and cache engines on UDP port 2048.

By allowing a cache cluster to connect to multiple routers, WCCPv2 provides redundancy and a distributed architecture for instances when a cache engine must connect to many interfaces. In addition, WCCPv2 allows you to keep all the cache engines in a single cluster, which avoids the unnecessary duplication of web pages across several clusters.

WCCPv2 can authenticate a device before it adds that device to the service group. Message Digest (MD5) authentication allows each WCCPv2 service group member to use a secret key to generate a keyed MD5 digest string that is part of the outgoing packet. At the receiving end, a keyed digest of an incoming packet is generated. If the MD5 digest within the incoming packet does not match the generated digest, WCCP ignores the packet.

WCCPv2 rejects packets in any of the following cases:

• The authentication schemes differ on the router and in the incoming packet.

• The MD5 digests differ on the router and in the incoming packet.

You must configure the same authentication on all members of a WCCPv2 service group.

WCCPv2 negotiates the packet redirection method between the router and the cache engine. Cisco NX-OS uses this traffic redirection method for all cache engines in a service group.

WCCPv2 redirects packets using Layer 2 Destination MAC rewrite method, where WCCPv2 replaces the destination MAC address of the packet with the MAC address of the cache engine that needs to handle the packet. The cache engine and the router must be adjacent to Layer 2.

You can also configure an access control list (ACL), called a redirect list, for a WCCPv2 service group. This ACL can either permit a packet to go through the WCCPv2 redirection process or deny the WCCP redirection and send the packet through the normal packet forwarding procedure.

WCCPv2 filters packets to determine which redirected packets have been returned from the cache engine and which packets have not. WCCPv2 does not redirect the returned packets, because the cache engine has determined that these packets should not be cached. WCCPv2 returns packets that the cache engine does not service to the router that transmitted them.

A cache engine may return a packet for one of the following reasons:

• The cache engine is overloaded and cannot service the packets.

• The cache engine is filtering certain conditions that make caching packets counterproductive, for example, when IP authentication has been turned on.

WCCPv2 negotiates the packet return method between the router and the cache engine. Cisco NX-OS uses this traffic return method for all cache engines in a service group.

WCCPv2 returns packets using the Destination MAC rewrite method, where WCCPv2 replaces the destination MAC address of the packet with the MAC address of the router that originally redirected the packet. The cache engine and the router must be adjacent to Layer 2.

WCCPv2 supports stateful restarts and stateful switchovers. A stateful restart occurs when the WCCPv2 process fails and is restarted. A stateful switchover occurs when the active supervisor switches to the standby supervisor. Cisco NX-OS applies the running configuration after a switchover.

WCCPv2 supports virtual routing and forwarding (VRF) instances. VRFs exist within virtual device contexts (VDCs). By default, Cisco NX-OS places you in the default VDC and default VRF unless you specifically configure another VDC and VRF.

WCCP redirection occurs within a VRF. You must configure the WCCP cache engine so that the forward and return traffic to and from the cache engine occurs from interfaces that are a part of the same VRF.

The VRF used for the WCCP on an interface should match the VRF configured on that interface.

If you change the VRF membership of an interface, Cisco NX-OS removes all layer 3 configuration, including WCCPv2.

For more information, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide.

The Service Policy Manager (SPM) supervisor component acts as a data path manager for the WCCP Manager. The WCCP manager is shielded from the underlying platform specifics by the SPM and is portable to platform variations. The WCCP manager has a set of SPM APIs to pass the configurations that are mapped and programmed in the hardware. These APIs can process and parse the application data that is implemented and maintained in one single handler.

The interface redirects that failed to be programmed by the SPM are stored until there is a service group configuration change through the CLI or an RA message. The WCCP manager retries programming policies that failed previously.

The WCCP manager sends policy updates to the SPM in intervals to program TCAM entries in the hardware. These policy updates can be triggered by the CLI or through RA (Redirect-Assign) messages. When the WCCP is notified of an SPM error, a syslog message appears.

WCCPv2 has the following prerequisites:

• You must globally enable the WCCPv2 feature.

• You can only configure WCCPv2 on Layer 3 or VLAN interfaces (see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide).

WCCPv2 has the following configuration guidelines and limitations:

• A WCCPv2 service group supports up to 32 routers and 32 cache engines.

• All cache engines in a cluster must include all routers that service the cluster in its configuration. If a cache engine within a cluster does not include one or more of the routers in its configuration, the service group detects the inconsistency and the cache engine is not allowed to operate within the service group.

• The cache engine cannot be on the same SVI with a redirect out statement.

• WCCPv2 works with IPv4 networks only.

• Any traffic that is coming from an M1-Series or M2-Series I/O module interface and going towards a Traffic Engineering (TE) Class-based Tunnel Selection (CBTS) tunnel will be dropped if you have configured the ip wccp redirect exclude in command on the inbound M1-Series or M2-Series I/O module interface or Switch Virtual Interface (SVI).

• WCCPv2 supports multiple service groups in the same direction (either inbound or outbound) on any Layer 3 interface, under the following conditions:

  • The access-list used must not have deny ip any any entry.

  • The access-list used for multiple service groups must not contain overlapping entries.

    The following is an example of an overlapping entry:

    ip access-list wccp_acl1
    	permit tcp 10.0.0.0/8 10.0.0.0/8
    ip access-list wccp_acl2
    	permit tcp 10.10.10.1/32 10.10.10.10/32

• Cisco NX-OS removes all Layer 3 configuration on an interface when you change the VDC, interface VRF membership, port-channel membership, or the port mode to Layer 2.

• Cisco NX-OS does not support WCCPv2 on tunnel interfaces.

• WCCPv2 is supported on all types of FEX devices.

• WCCP requires the client, server, and WCCP client to be on separate interfaces. If you migrate a topology from a Cisco Catalyst 6500 Series switch deployment, it might not be supported.

• F2 Series, F2e Series, M1 Series, and M2 Series modules support WCCPv2. However, F2 and F2e Series modules do not support egress WCCPv2 on an SVI including “exclude in” on SVI. F1 Series modules do not support WCCPv2.

• WCCPv2 redirect-in and redirect-out is fully supported in Cisco NX-OS Release 6.2 in non-mixed module VDCs. WCCPv2 is also support in mixed module VDC scenarios for most module combinations.

• For egress WCCPv2, traffic is not redirected when the ingress includes F2 series modules, and the next-hop is pointing to an SVI interface or subinterface of any module. If the egress WCCP policy is applied on a SVI or subinterface and if the packet ingresses on a F2 module, the same limitation applies.

• Beginning with Cisco NX-OS Release 5.2(4), policy-based routing and WCCPv2 are supported on the same interface. However, policy-based routing with statistics and WCCPv2 is supported on the same interface only if bank chaining is disabled.

• GRE redirection/return and hash assignment are not supported on a Cisco Nexus 7000 Series switch.

• Traffic might encounter a vPC loop and drop if you have Web Cache Control Protocol (WCCP) and vPC on your Cisco Nexus 7000 Series switch and the traffic migrates from a Cisco Nexus 65xx switch to your switch. Traffic that comes from a vPC member port and crosses a vPC peer-link is not permitted to egress any vPC member port. However, it can egress any other type of port, such a Layer 3 port or an orphan port. This behavior is expected.

  If traffic drops after you configure WCCP and vPC on your Nexus 7000 Series switch and based on your design, you can perform one of the following tasks to avoid the vPC loop:

  • Configure a Layer 2 trunk to carry the traffic in question.

  • Enable a peer gateway.

  • Shut down one of the member ports in the vPC.

• If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

• The following restrictions apply to the redirect-list, ACL:

  • Permit statements in the redirect ACL will consume more security TCAM entries compared to deny statements. Ensure the TCAM does not become oversubscribed.

  • The ACL must be an IPV4 simple ACL.

  • The protocol must be IP or TCP.

  • Only individual source or destination port numbers may be specified; port ranges cannot be specified.

  • The use of fragments or options is not permitted.

• From Cisco NX-OS Release 8.2(1), the following guidelines and limitations are applicable for WCCPv2:

  • WCCPv2 is supported for the L3 Virtual Network Identifier (VNI) Bridge Domain Interface (BDI), if it is applied on the ingress traffic only by using the ip wccp service redirect in command.

  • WCCPv2 is not supported for the L2VNI BDI.

  • The commands ip wccp service redirect out and ip wccp redirect exclude in are not supported on L3VNI BDI.

  • ip wccp web-cache redirect out command is not supported in WCCP on BDI interface.