The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure the Web Cache Communication Protocol version 2 (WCCPv2) on Cisco NX-OS devices.
This chapter includes the following sections:
•Licensing Requirements for WCCPv2
•Guidelines and Limitations for WCCPv2
•Verifying WCCPv2 Configuration
WCCPv2 specifies interactions between one or more Cisco NX-OS routers and one or more cache engines. WCCPv2 transparently redirects selected types of traffic through a group of routers. The selected traffic is redirected to a group of cache engines to optimize resource usage and lower response times.
Cisco NX-OS does not support WCCPv1.
This section includes the following topics:
•Virtualization Support for WCCPv2
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 then establishes its own connection out to the original destination server to retrieve the object.
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 needs to connect to a large number of 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.
This section includes the following topics:
•WCCPv2 Designated Cache Engine
A service is a defined traffic type that the router redirects to a cache engine with the WCCPv2 protocol.
You can configure the router to run one of the following cache-related services:
•Well-known —The router and the cache engine know the traffic type, for example the web cache service on TCP port 80 for HTTP.
•Dynamic service—A service in which the cache engine describes the type of redirected traffic to the router.
A service group is a subset of cache engines within a cluster and the routers connected to the cluster that are running the same service. Figure 5-1 shows a service group within a cache cluster. The cache engines and the routers can be a part of multiple service groups.
Figure 5-1 WCCPv2 Cache Cluster and Service Group
You can configure a service group as open or closed. An open service group forwards traffic without redirection if there is no cache engine to redirect the traffic to. A closed service group drops traffic if there is no cache engine to redirect the traffic to.
The service group defines the traffic that will be redirected to individual cache engines in that service group. The service group definition consists of the following:
•Service ID (0-255)
•Service Type
•Priority of the service group
•Protocol (TCP or UDP) of redirected traffic
•Service flags
•Up to eight TCP or UDP port numbers (either all source or all destination port numbers)
WCCPv2 requires that each cache engine be aware of all the routers in the service group. You can configure a list of router addresses for each of the routers in the group on each cache engine.
The following sequence of events details how WCCPv2 configuration works:
Step 1 You configure each cache engine with a list of routers.
Step 2 Each cache engine announces its presence and a list of all routers with which it has established communications.
Step 3 The routers reply with their view (list) of cache engines in the group.
The cache engines and routers exchange control messages every 10 seconds by default.
WCCPv2 designates one cache engine as the lead. If there is a group of cache engines, the one seen by all routers and the one that has the lowest IP address becomes the designated cache engine. The designated cache engine determines how traffic should be allocated across cache engines. The traffic assignment method is passed to the entire service group from the designated cache engine so that the routers of the group can redirect the packets and the cache engines of the group can manage their traffic load better.
Cisco NX-OS uses the mask method to assign traffic. The designated cache engine assigns the mask and value sets to the router in the WCCP Redirect Assignment message. The router matches these mask and value sets to the source IP address, destination IP address, source port, and destination port of each packet. The router redirects the packet to the cache engine if the packet matches an assigned mask and value set. If the packet does not match an assigned mask and value set, the router forwards the packet without any redirection.
You can use an IP access list as a redirect list to specify a subset of traffic to redirect with WCCPv2. You can apply this access list for ingress or egress traffic on an interface. Figure 5-2 shows how redirection applies to ingress or egress traffic.
Figure 5-2 WCCP Redirection
You can also exclude ingress traffic on an interface but allow egress redirection on that interface.
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.
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 the following forwarding method:
•Layer 2 Destination MAC rewrite—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 Layer 2 adjacent.
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 following forwarding method:
•Destination MAC rewrite—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 Layer 2 adjacent.
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 instances (VRFs). 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 happens within a VRF. The WCCP cache engine must be configured such that the forward and return traffic to and from the cache engine happens from interfaces that are a part of the same VRF.
The VRF used for 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, Release 4.x. and see Chapter 14 "Configuring Layer 3 Virtualization."
The following table shows the licensing requirements for this feature:
WCCPv2 has the following prerequisites:
•You must globally enable the WCCPv2 feature (see the "Enabling the WCCPv2 Feature" section).
•You can only configure WCCPv2 on Layer 3 or VLAN interfaces (see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 4.x).
•If you configure VDCs, install the Advanced Services license and enter the desired VDC (see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 4.x).
WCCPv2 has the following 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 servicing 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 will detect the inconsistency and the cache engine will not be 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.
•Do not configure policy-based routing and WCCPv2 on the same interface.
•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.
•Wildcard masks are not supported for the WCCPv2 redirect list.
•Cisco NX-OS does not support WCCPv2 on tunnel interfaces.
•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.
To configure WCCPv2, follow these steps:
Step 1 Enable the WCCPv2 feature. See the "Enabling the WCCPv2 Feature" section.
Step 2 Configure a service group. See the "Configuring a WCCPv2 Service Group" section.
Step 3 Apply WCCPv2 redirection to an interface. See the "Applying WCCPv2 Redirection to an Interface" section.
This section includes the following topics:
•Configuring a WCCPv2 Service Group
•Applying WCCPv2 Redirection to an Interface
Note 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.
You must enable the WCCPv2 feature before you can configure WCCPv2.
Ensure that you are in the correct VDC (or use the switchto vdc command).
To enable the WCCPv2 feature, use the following command in global configuration mode:
|
|
---|---|
feature wccp
Example: switch(config)# feature wccp |
Enables the WCCPv2 feature in a VDC. |
To disable the WCCPv2 feature in a VDC and remove all associated configuration, use the following command in global configuration mode:
|
|
---|---|
no feature wccp
Example: switch(config)# no feature wccp |
Disables the WCCPv2 feature in a VDC and removes all associated configuration. |
You can configure a WCCPv2 service group. You can optionally configure the following:
•Open or closed mode (with a service list)—Controls the traffic type that this service group handles.
•WCCPv2 authentication—Authenticates the WCCPv2 messages using an MD5 digest. WCCPv2 discards messages that fail authentication.
Note You must configure the same authentication on all members of the WCCPv2 service group.
•Redirection limits—Controls the traffic that is redirected to the cache engine.
Closed mode for dynamic service groups requires a service list ACL that specifies the protocol and port information that will be used for the service group. If there are no members in the service group, packets matching the service-list ACL will be dropped.
Note The service-list keyword ACL must have only protocol and port information. To restrict traffic that is considered for redirection, use the redirect-list keyword.
Note You must enter the ip wccp command with all your required parameters. Any subsequent entry of the ip wccp command overwrites the earlier configuration.
Ensure that you are in the correct VDC (or use the switchto vdc command).
Enable the WCCPv2 feature (see the "Enabling the WCCPv2 Feature" section).
To configure a WCCPv2 service group, use the following command in global configuration mode:
To apply WCCPv2 redirection on an interface, use the following commands in interface configuration mode:
This example shows how to configure a router to redirect web-related packets without a destination of 19.20.2.1 to the web cache:
switch(config)# access-list 100
switch(config-acl)# deny ip any host 192.0.2.1
switch(config-acl)# permit ip any any
switch(config-acl)# exit
switch(config)# ip wccp web-cache redirect-list 100
switch(config)# interface ethernet 2/1
switch(config-if)# ip wccp web-cache redirect out
You can configure WCCPv2 redirection on an interface in a VRF.
Note The WCCPv2 VRF must match the VRF configured on the interface.
1. config t
2. vrf-context vrf-name
3. ip wccp {service-number | web-cache} [mode {open [redirect-list acl-name] | closed service-list acl-name}]] [password [0-7] pwstring]
4. show ip wccp [vrf vrf-name]
5. copy running-config startup-config
The following example shows how to configure WCCPv2 in VRF Red on interface Ethernet 2/1:
switch# config t
switch(config)# vrf context Red
switch(config-vrf)# ip wccp web-cache password Test1 redirect-list httpTest
switch(config-vrf)# interface ethernet 2/1
switch(config-if)# vrf member Red
switch(config-if)# ip wccp web-cache redirect out
To display WCCPv2 configuration information, perform one of the following tasks:
To clear WCCPv2 statistics, use the clear ip wccp command.
This example shows how to configure WCCPv2 authentication on router redirect web-related packets without a destination of 192.0.2.1 to the web cache:
access-list 100
deny ip any host 192.0.2.1
permit ip any any
feature wccp
ip wccp web-cache password 0 Test1 redirect-list 100
interface ethernet 1/2
ip wccp web-cache redirect out
no shutdown
Note See the Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 4.x for information about IP access lists.
Table 5-1 lists the default settings for WCCPv2 parameters.
|
|
---|---|
Authentication |
no authentication |
WCCPv2 |
disable |
For additional information related to implementing WCCPv2, see the following sections:
|
|
---|---|
WCCPv2 CLI commands |
Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference |
|
|
---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
— |
Table 5-2 lists the release history for this feature.
|
|
|
---|---|---|
WCCPv2 |
4.2(1) |
This feature was introduced. |