This section describes some of the fundamental concepts for configuring WCCP. This section includes the following topics:

A central concept of WCCP is the service group. The service group logically consists of up to 32 WCCP routers and 32 WCCP clients that work together to redirect and optimize traffic. WCCP routers are Cisco routers or switches capable of forwarding traffic meeting defined criteria. WCCP clients are the devices receiving this traffic. RiOS v6.1 or later includes multiple in-path WCCP (for details, see Multiple In-Path WCCP). The same WCCP routers and clients can participate in one or more service groups.

Service groups are differentiated by a service group number. The service group number is local to the site where WCCP is used. The service group number is not transmitted across the WAN.

When a router participates in a WCCP service group, it is configured to monitor traffic passing through a user-defined set of interfaces. When a router receives traffic of interest, it redirects the IP packets to be transmitted to a designated interface in another system in the WCCP service group.

Routers redirect traffic to the SteelHead interfaces in their WCCP service group. The assignment method and the load-balancing configuration determine which SteelHead interface the router redirects traffic to.

This section describes WCCP assignment methods. This section includes the following topics:

Routers participating in WCCP support two assignment methods. The assignment method affects how a router redirects traffic when multiple target systems are specified in a service group. Assignment methods are important when two or more SteelHeads are deployed at the same site for high availability or load balancing. The assignment methods are as follows:

The hash assignment method redirects traffic based on a hashing scheme and the weight of the SteelHead interfaces. A hashing scheme is a combination of the source IP address, destination IP address, source port, or destination port. The hash assignment method is commutative: a packet with a source IP address X, and a destination IP address Y, hashes to the same value as a packet with a source IP address Y, and a destination IP address X.

The weight of a SteelHead is determined by the number of connections the SteelHead supports. The default weight is based on the SteelHead model number. The more connections a SteelHead model supports, the heavier the weight of that model. You can modify the weight for each in-path interface to manually tune the proportion of traffic a SteelHead interface receives.

The hash assignment method supports failover and load balancing. In a failover configuration, you configure one or more SteelHead interfaces to be used only if no other SteelHead interfaces within the WCCP service group are operating. To configure a SteelHead interface for failover, set the SteelHead interface weight to 0 on the desired service group.

If a SteelHead interface has a weight of 0, and another SteelHead interface in the same WCCP service group has a nonzero weight, the SteelHead interface with the 0 weight does not receive redirected traffic. If all of the operating SteelHeads interfaces have a weight of 0, traffic is redirected equally among them.

The mask assignment method redirects traffic based on administrator-specified bits pulled, or masked, from the IP address and TCP port fields. Unlike the hash assignment method, these bits are not hashed. Instead, the Cisco switch concentrates the bits to construct an index into the load-balancing table.

You must carefully choose these bits. Mask assignment uses up to seven bits, which allows for a maximum of 128 buckets (2^7=128) for load balancing across SteelHead interfaces in the same service group. RiOS v6.1 or later supports load balancing and redundancy per interface by configuring each SteelHead interface with the appropriate service groups and router bindings (for details, see Multiple In-Path WCCP).

The mask assignment method processes the first packet for a connection in the router hardware. To force mask assignment, use the assign-scheme option for the wccp service-group CLI command:

Some Cisco platforms, such as the Catalyst 4500 and the Catalyst 3750, only support the mask assignment method.

When you use the mask assignment method, you configure failover in the same manner as you do with the hash assignment method.

The mask assignment method requires that, for every connection, packets are redirected to the same SteelHead or interface in both directions (client-to-server and server-to-client). To achieve redirection, you configure the following:

Figure 11‑1 shows the reversed mask redirection technique.

For information about mask assignment method parameters, see the Riverbed Command-Line Interface Reference Manual.

Unless otherwise specified in the SteelHead interface WCCP service group setting, and if the router supports it, choose the hash assignment method. The hash assignment method generally achieves better load distribution, and mask assignment provides more user controlled configuration, including the ability to distribute traffic based on subnet mask values.

The following scenarios are instances when the mask assignment method is preferable:

This section described the WCCP redirection and return methods. It includes the follow sections:

WCCP supports two methods for transmitting packets between a router or switch and SteelHead interfaces: the GRE encapsulation method and the Layer-2 method. SteelHeads support both the Layer-2 and GRE encapsulation methods, in both directions, to and from the router or switch.

The Layer-2 method is generally preferred from a performance standpoint because it requires fewer resources from the router or switch than the GRE encapsulation does. The Layer-2 method modifies only the destination Ethernet address. However, not all combinations of Cisco hardware and IOS revisions support the Layer-2 method. Also, the Layer-2 method requires the absence of Layer-3 hops between the router or switch and the SteelHead.

The GRE encapsulation method appends a GRE header to a packet before it is forwarded. This can cause fragmentation and imposes a performance penalty on the router and switch, especially during the GRE packet deencapsulation process. This performance penalty can be too great for production deployments.

If your deployment requires the use of GRE return, the SteelHead automatically changes the maximum segment size (MSS) for connections to 1432 bytes. You can overwrite this option with the command no wccp adjust-mss enable, although Riverbed does not recommend it.

You can avoid using the GRE encapsulation method for the traffic return path from the SteelHead by using the SteelHead wccp override-return route-no-gre or wccp override-return sticky-no-gre CLI commands. The wccp override-return route-no-gre command enables the SteelHead to return traffic without GRE encapsulation to a SteelHead in-path gateway, determined by the in-path routing table. The wccp override-return sticky-no-gre command enables the SteelHead to return traffic without GRE encapsulation to the router that forwarded the traffic. Both commands accomplish a similar goal of forcing the SteelHead to return packets through Layer 2, but the wccp override-return sticky-no-gre command is generally used because returning packets to the originating router is often most often preferred.

Use the wccp override-return route-no-gre or wccp override-return sticky-no-gre commands only if the SteelHead is no more than a Layer-2 hop away from the potential next-hop routers, and if the unencapsulated traffic does not pass through an interface that redirects the packet back to the SteelHead (that is, there is no WCCP redirection loop). For information about the wccp override-return route-no-gre or wccp override-return sticky-no-gre commands, see the Riverbed Command-Line Interface Reference Manual.

The following table summarizes Cisco hardware platform support for redirection and return methods.

When a SteelHead in a WCCP cluster transmits packets for optimized or pass-through connections, how it decides to address those packets depends on the RiOS version, WCCP configuration, and its in-path routing table. RiOS v6.0 or later includes more techniques to statefully track the originating router, both for Layer­ 2 and GRE methods.

Riverbed recommends the following best practices for determining your redirection and return method:

WCCP clustering refers to two or more SteelHeads participating in the same service group. A single service group can support 32 WCCP clients, counting a single SteelHead interface as a client. However, a single SteelHead with multiple interfaces is typically not considered a cluster, even though each interface is considered a client.

Load balancing and redundancy is provided across all participating SteelHeads in a WCCP cluster by default. You can adjust the weight per each in-path interface to modify behavior for load balancing and redundancy. For example, you can configure a second in-path interface connected to a redundant device, with a smaller weight to be given a smaller proportion of traffic.

Certain timers in the WCCPv2 implementation directly affect failover time and are not adjustable. Every 10 seconds, the SteelHead and router exchange WCCP Here I Am and I See You messages (Hello messages). The router declares a client failed after missing three messages. This means that if a SteelHead or SteelHead interface fails, the router always waits between 20 to 30 seconds before declaring the SteelHead down. If there are buckets (traffic distribution) assigned to the failed client, the router forwards traffic to the failed client during this interval, potentially black-holing that traffic. Traffic to other WCCP clients is redirected and optimized as normal. After the WCCP client is declared failed, buckets are recalculated. The buckets belonging to the failed device are distributed among the remaining WCCP clients. The hello and failure time intervals cannot be adjusted in the current WCCPv2 implementation.

In high-availability environments, optimization redundancy refers to the ability to quickly fail over to another appliance to continue application acceleration with minimal impact to users. However, no matter what deployment method is chosen, optimized connections to one SteelHead are never statefully failed to a different SteelHead. This is because the SteelHeads optimizing the connection act as TCP proxies and therefore are fully aware of the connection state. Although connection forwarding allows a SteelHead to inform neighbors what connections are current, it does not exchange the full state of each connection, because this requires extensive and continuous updates with all neighbors. Without knowing the full state of a connection, a new device cannot safely resume the optimization of an existing connection. The majority of applications resend a SYN to establish a new connection with a redundant peer, transparent to the user. However, not all applications behave in this manner. Be aware that loss of a SteelHead requires the client to reestablish a new TCP connection, which is usually transparent to the user.

In RiOS v6.5 or later, you must enable connection forwarding in a WCCP cluster. With connection forwarding enabled, the WCCP load balancing algorithm accounts for the total number of in-path interfaces of all neighbors in the service group when balancing the load across the interfaces. If you do not enable connection forwarding, the SteelHead with the lowest IP address assigns all traffic flows to itself.

RiOS v6.1 or later provides additional WCCP configuration, allowing each individual SteelHead in-path interface to be configured as a WCCP client. Each configured in-path interface participates in WCCP service groups as an individual WCCP client, providing flexibility to determine load-balancing proportions and redundancy.

Prior to RiOS v6.1, WCCP was configured with the wccp service group command. This command now includes the interface as a mandatory parameter, making the command wccp interface <interface> service group.

For details, see the Riverbed Command-Line Interface Reference Manual.