WCCP Virtual In-Path Deployments
This chapter describes how to configure WCCP to redirect traffic to one or more SteelHeads. This chapter includes the following sections:
This chapter provides basic information about WCCP network deployments and examples for configuring WCCP deployments. Use this chapter as a general guide to WCCP deployments.
For information about the factors you must consider before you design and deploy the SteelHead in a network environment, see
Choosing the Right SteelHead Model.
Overview of WCCP
This section provides an overview of WCCP. WCCP Version 1 was originally implemented on Cisco routers, multilayer switches, and web caches to redirect HTTP requests to local web caches.
WCCP Version 2, which SteelHeads support, can redirect any type of connection from multiple routers to multiple WCCP clients (also referred to as caches or engines). SteelHeads deployed with WCCP can interoperate with remote SteelHeads deployed in any way, such as WCCP, PBR, in-path, and out-of-path.
WCCP requires either a Cisco router or a Cisco switch.
The most important factors in a successful WCCP implementation are the Cisco hardware platform and the IOS revision you use. There are many possible combinations of Cisco hardware and IOS revisions, and each combination has different capabilities.
Cisco platforms and IOS do not support all assignment methods, redirection methods, use of ACLs to control traffic, and interface interception directions. You can expect the Cisco minimum recommended IOS to change as WCCP becomes more widely used and new IOS technical issues are discovered.
Cisco recommends the following minimum IOS releases for specific hardware platforms.
Cisco Hardware | Cisco IOS |
ASR 1000 | 2.2XE |
ISR and 7200 Routers | 12.1(14), 12.2(26), 12.3(13), 12.4(10), 12.1(3)T, 12.2(14)T, 12.3(14)T5, 12.4(15)T8, 12.4(24)T |
ISR G2 | 15.0(1)M1 |
Catalyst 6500 with Sup720 or Sup32 | 12.2(18)SXF16, 12.2(33)SXI |
Catalyst 6500 with Sup2 | 12.2(18)SXF16 |
Catalyst 7600 | 12.2(18)SXF16, 12.2(33)SXI |
Catalyst 4500 | 12.2(46)SG |
Catalyst 3750 | 12.2(46)SE |
Nexus 7000 | 4.2.4 |
Regardless of how you configure a SteelHead, if the Cisco IOS version on the router or switch is below the current Cisco minimum recommendations, it might be impossible to have a functioning WCCP implementation or the implementation might not have optimal performance.
WCCP Fundamentals
This section describes some of the fundamental concepts for configuring WCCP. This section includes the following topics:
Service Groups
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 6.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.
Note: Riverbed recommends that you use WCCP service groups 61 and 62.
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.
Assignment Methods
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:
• Hash assignment - Uses the software to calculate part of the load distribution, placing a significant load on the switch CPU.
• Mask assignment - Processes traffic entirely in hardware, so that the impact on the switch CPU is minimal. Mask assignment was specifically designed for hardware-based switches and routers.
Note: Do not confuse assignment methods with forwarding methods. Assignment methods determine how packets are distributed across multiple SteelHeads (through mask or hash), and forwarding methods determine how intercepted packets are forwarded from the router or switch to the SteelHead (through GRE or Layer 2).
Hash Assignment
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.
Mask Assignment
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 7 bits, which allows for a maximum of 128 buckets (2^7=128) for load balancing across SteelHead interfaces in the same service group. RiOS 6.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 command:
wccp interface inpath0_0 service-group 61 routers 10.0.0.1 assign-scheme mask
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 settings:
• Because only one set of masks can be used per service group, Riverbed recommends that you use two different service groups for inbound traffic from the client (group 61) and inbound traffic from the server (group 62).
• Configure the Cisco switch to redirect packets to a WCCP service group in the client-to-server direction and to redirect packets to another WCCP group in the server-to-client direction. In most cases, service group 61 is placed on the inbound interface closest to the client and service group 62 is placed on the inbound interface closest to the server. Generally when you use a mask, service group 61 is configured based on the source IP, and service group 62 is configured for the destination IP to maintain consistent assignment in either direction.
Figure: Mask Assignment Method Packet Redirection
For information about mask assignment method parameters, see the Riverbed Command-Line Interface Reference Manual.
Choosing an Assignment Method
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:
• Certain lower-end Cisco switches (3750, 4000, 4500 series, among others) do not support hash assignment.
• The hash assignment method uses a NetFlow table entry on the switch for every connection. The NetFlow table entry can support up to 256K connections, depending on the hardware. However, when the switch runs out of NetFlow table entries, every WCCP-redirected packet is process switched, which has a crippling effect on the switch CPU, and very large WCCP deployments are constrained to the mask assignment load distribution method.
• The hash assignment method processes the first packet of every new redirected connection using the switch CPU. The switch CPU installs the NetFlow table entry that is used to hardware-switch subsequent packets for a given connection. This process limits the number of connection setups a switch can perform per unit of time. Thus, in WCCP deployments where the connection setup rate is very high, the mask assignment method is the only option.
• In multiple SteelHead environments, it is often desirable to send all users in subnet range to the same SteelHead. Mask assignment provides a basic ability to leverage a branch subnet and SteelHead to the same SteelHead in a WCCP cluster.
Redirection and Return Methods
This section describes the WCCP redirection and return methods. It includes the follow topics:
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 method 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 no wccp adjust-mss enable command, 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 command. 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 command 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.
Cisco Hardware | Redirection and Return Method |
Nexus 7000 | Layer 2 |
ASR 1000 | GRE or Layer 2 |
ISR and 7200 routers | GRE or Layer 2 (Layer 2 requires 12.4(20)T or later) |
Catalyst 6500 with Sup720 or Sup32 | GRE or Layer 2 |
Catalyst 6500 with Sup2 | GRE or Layer 2 |
Catalyst 4500 | Layer 2 |
Catalyst 3750 | Layer 2 |
WCCP Return Router Determination
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 6.0 or later includes more techniques to statefully track the originating router, both for Layer‑2 and GRE methods.
Best Practices for Determining a Redirection and Return Method
Riverbed recommends the following best practices for determining your redirection and return method:
• Design your WCCP deployment so that your SteelHeads are no more than a Layer-2 hop away from the router or switch performing WCCP redirection.
• Do not configure a specific redirection or assignment method on your SteelHead. Allow the SteelHead to negotiate these settings with the router unless one of the reasons for using mask assignment applies to your deployment.
• Use the wccp override-return route-no-gre or wccp override-return sticky-no-gre commands only if the following conditions are both met:
– The SteelHead is no more than a Layer-2 hop away from the router or switch.
– Unencapsulated traffic going to the next-hop router or switch does not pass through an interface that redirects the packet back to the SteelHead (that is, there is no WCCP redirection loop). If this condition is not met, traffic redirected by the SteelHead is continually returned to the same SteelHead.
WCCP Clustering and Failover
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. 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. 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 doing 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 6.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.
Multiple In-Path WCCP
RiOS 6.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 6.1, WCCP was configured with the wccp service group command. This command now includes the interface as a mandatory parameter, changing the command syntax to wccp interface <interface> service group.
For details, see the Riverbed Command-Line Interface Reference Manual.
Advantages and Disadvantages of WCCP
Physical in-path deployments require less initial and ongoing configuration and maintenance than out-of-path or virtual in-path deployments. Physical in-path SteelHeads are placed at the points in your network where data already flows. Thus, with in-path deployments you do not need to alter your existing network infrastructure.
For information about physical in-path deployments, see
Physical In-Path Deployments.
Virtual in-path techniques, such as WCCP, require more time to configure because the network infrastructure must be configured to redirect traffic to the SteelHeads.
WCCP also has the following advantages:
• No rewiring required - You do not need to move any wires during installation. At large sites with multiple active links, you can adjust wiring by moving individual links, one at a time, through the SteelHeads.
• An option when no other is available - At sites where a physical in-path deployment is not possible, WCCP might achieve the integration you need. For example, if your site has a WAN link terminating directly into a large access switch, there is no place to install a physical in-path SteelHead.
WCCP has the following disadvantages:
• Network design changes required - WCCP deployments with multiple routers can require significant network changes (for example, spanning VLANs and GRE tunnels).
• Hardware and IOS upgrades required - To avoid hardware limitations and IOS issues, you must keep the Cisco platform and IOS revisions at the current minimum recommended levels. Otherwise, it might be impossible to create a stable deployment, regardless of how you configure the SteelHead. For future IOS feature planning you must consider compatibility with WCCP.
• Additional evaluation overhead - It can take more time to evaluate the integration of the SteelHeads. This overhead is in addition to evaluating SteelHead performance gains. You might need Riverbed Professional Services to test and perform network infrastructure upgrades before any optimization can be performed, especially when WCCP is deployed at numerous sites.
• Additional configuration management - You must create access control lists and manage them on an ongoing basis. At small sites, it might be feasible to redirect all traffic to the SteelHeads. However, at larger sites, access control lists might be required to ensure that traffic that cannot be optimized (for example, LAN-to-LAN traffic) is not sent to the SteelHeads.
• GRE encapsulation - If your network design does not support the presence of the SteelHeads and the Cisco router or switch interface in a common subnet, you must use GRE encapsulation for forwarding packets. SteelHeads can accommodate the subsequent extra performance utilization, but your existing router or switch might experience large resource utilization.
Configuring WCCP
This section describes how to configure WCCP and provides example deployments. This section includes the following topics:
Basic Steps for Configuring WCCP
This section describes the basic steps to set up WCCP.
To perform the basic steps to configure WCCP
1. Configure the SteelHead as an in-path device and enable in-path support.
You can use the
in-path enable and
in-path oop enable commands, or you can use In-Path Settings page shown in
Figure: In-Path Settings.
Figure: In-Path Settings
2. Enable WCCP on the router by creating a service group on the router.
3. Set the router to use WCCP to redirect traffic to the WCCP SteelHead.
4. Attach the desired SteelHead in-path interface WAN interface to the network. The WAN interface must be able to communicate with the switch or router on which WCCP is configured and where WCCP redirection takes place.
5. Add the service group on the WCCP SteelHead interface.
6. Enable WCCP on the WCCP SteelHead.
Configuring a Simple WCCP Deployment
Figure: A Single SteelHead and a Single Router shows a WCCP deployment that is simple to deploy and administer and achieves high performance. This example includes a single router and a single SteelHead.
Figure: A Single SteelHead and a Single Router
In this example:
• The router and the SteelHead use WCCP service groups 61 and 62. In this example, as long as the SteelHead interface is a member of all of the service groups, and the service groups include all of the interfaces on all of the paths to and from the WAN, it does not matter whether a single service group or multiple service groups are configured.
• The SteelHead wan0_0 interface is directly attached to the router, using a crossover cable.
• The SteelHead virtual inpath0_0 interface uses the IP information that is visible to the router and the remote SteelHeads for data transfer.
• The SteelHead does not have an encapsulation scheme in the WCCP service group configuration. Therefore, the SteelHead informs the router that it supports both the GRE and the Layer-2 redirection methods. The method negotiated and used depends on the methods that the router supports.
• You can force the SteelHead to perform Layer-2 return of packets, regardless of the negotiated method of return, by using either of the following commands: wccp override-return route-no-gre or wccp override-return-sticky-no-gre. Enabling one of these commands potentially decreases the resource utilization on the router, especially with Layer-3 switches that must perform de-encapsulation of GRE packets in software.
• The router uses the ip wccp redirect exclude command on the router interface connected to the SteelHead wan0_0 interface. This command configures the router to never redirect packets arriving on this interface, even if they are later sent out of an interface with an ip wccp redirect out command. Unless you configure the router with the ip wccp redirect out command on an interface, then you do not need to configure the ip wccp redirect exclude command. Almost all Cisco WCCP capable Layer-3 switches prefer the ip wccp redirect in command, so using the ip wccp redirect exclude command serves no purpose and, furthermore, can add overhead to the switch CPU.
Although the primary interface is not included in this example, Riverbed recommends that you connect the primary interface for management purposes. For information about configuring the primary interface, see the SteelHead Management Console User’s Guide.
To configure WCCP on the SteelHead
• On the SteelHead, connect to the CLI and enter the following commands:
enable
configure terminal
interface primary ip address 10.0.0.2 /24
ip default-gateway 10.0.0.1
interface inpath0_0 ip address 10.0.1.2 /24
ip in-path-gateway inpath0_0 10.0.1.1
in-path enable
in-path oop enable
wccp enable
wccp interface inpath0_0 service-group 61 routers 10.0.1.1
wccp interface inpath0_0 service-group 62 routers 10.0.1.1
write memory
restart
Note: You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
In the following example, only traffic to or from IP addresses 192.168.1.1 is sent to the SteelHead.
To configure WCCP on the Cisco router
• On the router, at the system prompt, enter the following commands:
enable
configure terminal
ip access-list extended wccp_acl_61
deny tcp 10.0.1.0 0.0.0.255 any
deny tcp any 10.0.1.0 0.0.0.255
permit tcp <client-subnets> <server-subnets>
ip access-list extended wccp acl 62
deny tcp 10.0.1.0 0.0.0.255 any
deny tcp any 10.0.1.0 0.0.0.255
permit tcp <server-subnets> <client-subnets>
ip wccp version 2
ip wccp 61 redirect-list wccp_acl_61
ip wccp 62 redirect-list wccp_acl_62
interface f0/0
ip wccp 62 redirect in
interface s0/0
ip wccp 61 redirect in
interface f0/1
ip wccp redirect exclude in
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
For information about how to verify the WCCP configuration,
Verifying and Troubleshooting WCCP Configurations.
Configuring WCCP using the mask assignment method is very similar to the standard WCCP configuration. The following example uses the mask of 0x3 that creates four buckets.
To configure WCCP on the SteelHead using the mask assignment method
• On the SteelHead, connect to the CLI and enter the following commands:
enable
configure terminal
interface primary ip address 10.0.0.2 /24
ip default-gateway 10.0.0.1
interface inpath0_0 ip address 10.0.1.2 /24
ip in-path-gateway inpath0_0 10.0.1.1
in-path enable
in-path oop enable
wccp enable
wccp interface inpath0_0 service-group 61 routers 10.0.1.1 assign-scheme mask src-ip-mask 0x3
wccp interface inpath0_0 service-group 62 routers 10.0.1.1 assign-scheme mask dst-ip-mask 0x3
write memory
restart
Adding a SteelHead to an Existing WCCP Deployment
You can have a maximum of 32 SteelHeads in your WCCP deployment. When you add new SteelHeads to an existing deployment, the buckets used by the router for load distribution are recalculated. New connections that were previously directed to one SteelHead might be redirected, resulting initially in cold performance after you restart service.
Note: Adding a configuration to the existing SteelHeads requires a service restart during a performance window.
Figure: Adding a SteelHead to an Existing WCCP Deployment
To add an additional SteelHead to an existing WCCP deployment
1. On SteelHead1, connect to the CLI and enter the following commands:
enable
configure terminal
interface inpath0_0 ip address 10.0.1.2 /24
ip in-path-gateway inpath0_0 10.0.1.1
in-path enable
in-path oop enable
wccp enable
wccp interface inpath0_0 service-group 61 routers 10.0.1.1
wccp interface inpath0_0 service-group 62 routers 10.0.1.1
wccp override-return route-no-gre
steelhead communication enable
steelhead name SteelHead2 main-ip 10.0.1.3
steelhead communication allow-failure
steelhead communication advertiseresync
write memory
restart
2. On SteelHead2, connect to the CLI and enter the following commands:
enable
configure terminal
interface inpath0_0 ip address 10.0.1.3 /24.
ip in-path-gateway inpath0_0 10.0.1.1
in-path enable
in-path oop enable
wccp enable
wccp interface inpath0_0 service-group 61 routers 10.0.1.1
wccp interface inpath0_0 service-group 62 routers 10.0.1.1
steelhead communication enable
steelhead name SteelHead1 main-ip 10.0.1.2
steelhead communication allow-failure
steelhead communication advertiseresync
write memory
restart
Configuring a WCCP High Availability Deployment
This section describes configuring a WCCP high availability deployment. This section includes the following topics:
RiOS 6.1 or later supports redundancy across multiple interfaces. Previously, high availability was only available at the appliance level. The following examples show appliances running 6.1 or later with multiple WCCP interfaces. The same configuration concepts apply to versions before 6.1, except that each appliance can have only one WCCP interface configured.
If you use RiOS versions before 6.1, you cannot achieve the high availability shown in
Single SteelHead with Interface High Availability. In
Dual WCCP SteelHeads and Interfaces with High Availability, you can provide appliance redundancy, but each SteelHead does not have interface redundancy.
The examples in
Single SteelHead with Interface High Availability and
Dual WCCP SteelHeads and Interfaces with High Availability show the configuration of SteelHeads for interface high availability. These examples focus solely on setting up multiple SteelHead interfaces to communicate with multiple routers and, therefore omit any best practice recommendations on redirection and assignment method configurations.
Single SteelHead with Interface High Availability
Figure: WCCP with Interface High Availability shows a high availability WCCP deployment in which a single SteelHead with two in-path interfaces and two routers are used in a WCCP configuration. This configuration ensures that traffic continues to optimize in the event of a SteelHead interface, router, or link failure. This example does not provide SteelHead high availability.
Note: This deployment requires multiple in-path WCCP in RiOS 6.1 or later.
Figure: WCCP with Interface High Availability
In this example:
• The WCCP service groups are composed of two routers (Layer-3 switches) redirecting traffic and two SteelHead interfaces acting as the cache engines. The SteelHead is connected to both routers: wan0_0 goes to Switch1, and wan0_1 goes to Switch2.
• If a single SteelHead interface fails, all traffic is forwarded to the remaining SteelHead interface.
To configure WCCP with a single SteelHead with interface high availability
1. On the SteelHead 1, connect to the CLI and enter the following commands:
enable
configure terminal
interface primary ip address 10.10.1.10 /24
ip default-gateway 10.10.1.2
interface inpath0_0 ip address 172.31.1.5 /24
ip in-path-gateway inpath0_0 172.31.1.1
interface inpath0_1 ip address 172.31.1.6 /24
ip in-path-gateway inpath0_1 172.31.1.1
in-path enable
in-path oop enable
wccp enable
wccp interface inpath0_0 service-group 61 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_0 service-group 62 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_1 service-group 61 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_1 service-group 62 routers 172.31.1.2 172.31.1.3
write memory
restart
Note: You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
2. To configure WCCP on Cisco router 1 (Switch1), at the system prompt, enter the following commands:
enable
configure terminal
!--- the server subnets.
ip access-list extended wccp_acl_61
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <client-subnets> <server-subnets>
!--- the client subnets.
ip access-list extended wccp_acl_62
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <server-subnets> <client-subnets>
ip wccp version 2
ip wccp 61 redirect-list wccp_acl_61
ip wccp 62 redirect-list wccp_acl_62
interface vlan 100
interface g0
ip wccp 61 redirect in
interface vlan 200
ip wccp 62 redirect in
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
3. To configure WCCP on Cisco router 2 (Switch2), at the system prompt, enter the following commands:
enable
configure terminal
ip access-list extended wccp_acl_61
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <client-subnets> <server-subnets>
ip access-list extended wccp_acl_62
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <server-subnets> <client-subnets>
ip wccp version 2
ip wccp 61 redirect-list wccp_acl_61
ip wccp 62 redirect-list wccp_acl_62
interface vlan 100
interface g0/0
ip wccp 61 redirect in
interface vlan 200
ip wccp 62 redirect in
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
For information about verifying the WCCP configuration, see
Verifying and Troubleshooting WCCP Configurations.
Dual WCCP SteelHeads and Interfaces with High Availability
Figure: High Availability WCCP with RiOS Data Store Synchronization shows a high availability WCCP deployment where two SteelHeads with two in-path interfaces and two routers are used in a WCCP configuration. This configuration ensures that traffic continues to be optimized in the event of a SteelHead interface or router failure.
This deployment requires multiple in-path WCCP in RiOS 6.1 or later.
RiOS
data store synchronization is commonly used in high availability designs. You can configure RiOS
data store synchronization between any two local SteelHeads, regardless of how they are deployed: physical in-path, virtual in-path, or out-of-path. For information about data store synchronization, see
RiOS Data Store Synchronization.
Figure: High Availability WCCP with RiOS Data Store Synchronization
In this example:
• The SteelHeads are connected to both routers (Layer-3 switches). For each SteelHead, wan0_0 is connected to Switch 1, and wan0_1 is connected to Switch 2.
• The WCCP service groups are composed of two routers redirecting traffic and four SteelHead interfaces acting as the cache engines.
• If a single SteelHead interface fails, all traffic is forwarded to the remaining SteelHead interfaces, including the second interface on the same SteelHead.
• If a single SteelHead fails, all traffic is forwarded to the other SteelHead's two in-path interfaces.
• Because the two SteelHeads synchronize their RiOS data stores, the remaining SteelHead provides the same level of acceleration as the failed SteelHead.
If you are using a cluster of WCCP-attached SteelHeads, all remote client-side SteelHeads must have probe caching disabled using the no in-path probe-caching enable command.
To configure dual WCCP SteelHeads with interfaces with high availability
1. To configure WCCP on SteelHead1, connect to the CLI and enter the following commands:
enable
configure terminal
interface primary ip address 10.10.1.10 /24
ip default-gateway 10.10.1.2
interface inpath0_0 ip address 172.31.1.5 /24
ip in-path-gateway inpath0_0 172.31.1.1
interface inpath0_1 ip address 172.31.1.6 /24
ip in-path-gateway inpath0_1 172.31.1.1
in-path enable
in-path oop enable
steelhead communication enable
steelhead name SH2 main-ip 172.31.1.7
steelhead communication allow-failure
steelhead communication advertiseresync
wccp enable
wccp interface inpath0_0 service-group 61 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_0 service-group 62 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_1 service-group 61 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_1 service-group 62 routers 172.31.1.2 172.31.1.3
datastore sync master
datastore sync peer-ip 10.10.1.13
datastore sync enable
write memory
restart
Note: You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
2. To configure WCCP on SteelHead2, connect to the CLI and enter the following commands:
enable
configure terminal
interface primary ip address 10.1.1.13 /24
ip default-gateway 10.10.1.3
interface inpath0_0 ip address 172.31.1.7 /24
ip in-path-gateway inpath0_0 172.31.1.1
interface inpath0_1 ip address 172.31.1.8 /24
ip in-path-gateway inpath0_1 172.31.1.1
in-path enable
in-path oop enable
steelhead communication enable
steelhead name SH1 main-ip 172.31.1.5
steelhead communication allow-failure
steelhead communication advertiseresync
wccp enable
wccp interface inpath0_0 service-group 61 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_0 service-group 62 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_1 service-group 61 routers 172.31.1.2 172.31.1.3
wccp interface inpath0_1 service-group 62 routers 172.31.1.2 172.31.1.3
no datastore sync master
datastore sync peer-ip 10.10.1.10
datastore sync enable
write memory
restart
Note: You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
3. To configure WCCP on Cisco router 1 (Switch1), at the system prompt, enter the following commands:
enable
configure terminal
ip access-list extended wccp_acl_61
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <client-subnets> <server-subnets>
ip access-list extended wccp_acl_62
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <server-subnets> <client-subnets>
ip wccp version 2
ip wccp 61 redirect-list wccp_acl_61
ip wccp 62 redirect-list wccp_acl_62
interface vlan 100
interface g0/0
ip wccp 61 redirect in
interface vlan 200
ip wccp 62 redirect in
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
4. To configure WCCP on Cisco router 2 (Switch 2), at the system prompt, enter the following commands:
enable
configure terminal
ip access-list extended wccp_acl_61
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <client-subnets> <server-subnets>
ip access-list extended wccp_acl_62
deny tcp 172.31.1.0.0.0.255 any
deny tcp any 172.31.1.0 0.0.0.255
permit tcp <server-subnets> <client-subnets>
ip wccp version 2
ip wccp 61 redirect-list wccp_acl_61
ip wccp 62 redirect-list wccp_acl_62
interface vlan 100
interface g0/0
ip wccp 61 redirect in
interface vlan 200
ip wccp 62 redirect in
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
For information about how to verify the WCCP configuration,
Verifying and Troubleshooting WCCP Configurations.
Configuring a Basic WCCP Router
This section summarizes some of the basic WCCP router configuration commands. For complete information about WCCP router configuration commands, refer to your router documentation.
To enable WCCP and define a service group on the router
• On the router, at the system prompt, enter the following commands:
enable
configure terminal
ip wccp <service-number>
end
write memory
Note: The service group you specify on the router must also be set on the WCCP SteelHead.
Note: The WCCP protocol allows you to add up to 32 SteelHeads and 32 routers to a service group.
To specify inbound traffic redirection for each router interface
• On the router, at the system prompt, enter the following commands:
enable
configure terminal
interface FastEthernet 0/0
ip wccp 61 redirect in
interface serial 0
ip wccp 62 redirect in
end
write memory
To retain information you previously specified with ip wccp, you must enter a new ip wccp command that includes the information you previously specified and whatever you want to configure.
For example, you can configure your router using the following set of commands:
enable
configure terminal
ip wccp 61 redirect-list 100
end
write memory
If you want to specify a password on the router later, the ip wccp 61 password <password> command overwrites the previous redirect list configuration.
To retain the previous redirect list configuration and set a password, you must use the following command:
ip wccp 61 redirect-list 100 password <password>
For example:
enable
configure terminal
ip wccp 61 redirect-list 100 password XXXYYYZZ
end
write memory
Configuring Additional WCCP Features
This section describes additional WCCP features and how to configure them. This section includes the following topics:
Specifying the Service Group Password
You can configure password authentication of WCCP protocol messages between the router and the SteelHead interface:
• The router service group must match the service group password configured on the WCCP SteelHead interface.
• The same password must be configured on the router and the WCCP SteelHead interface.
• Passwords must be no more than eight characters.
Note: The following router commands are not required for the example network configurations in this chapter. Use caution when you enter the
ip wccp [SG] router command because each
ip wccp [SG] router command overwrites the previous
ip wccp [SG] router command. You cannot use an
ip wccp [SG] router command to augment
ip wccp [SG] router commands you previously issued. For details, see
Configuring a Basic WCCP Router.
To specify the service group password on the WCCP router
• On the router, at the system prompt, enter the following commands:
enable
configure terminal
ip wccp <service-group> password <password>
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
To set the service group password on the WCCP SteelHead interface
• Connect to the Riverbed CLI on the WCCP SteelHead and enter the following commands:
enable
configure terminal
wccp interface <interface> service-group <service-id> routers <ip-address> password <password>
write memory
restart
For example, to set the password on inpath0_0, where the router service group is 61 and the router IP address is 10.1.0.1, enter the following command:
wccp inpath0_0 service-group 61 routers 10.1.0.1 password XXXYYYZZ
Note: You must set the same password on the SteelHead interface and the Cisco router.
Note: You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
Configuring Multicast Groups
If you add multiple routers and SteelHead interfaces to a service group, you can configure them to exchange WCCP protocol messages through a multicast group.
Configuring a multicast group is advantageous because if a new router is added, it does not need to be explicitly added on each SteelHead interface.
Note: The following router commands are not required for the example network configurations in this chapter. Use caution when you enter the
ip wccp [SG] router command because each
ip wccp [SG] router command overwrites the previous
ip wccp [SG] router command. You cannot use an
ip wccp [SG] router command to augment
ip wccp [SG] router commands you previously issued. For details, see
Configuring a Basic WCCP Router.
To configure multicast groups on the WCCP router
• On the router, at the system prompt, enter the following commands:
enable
configure terminal
ip wccp 61 group-address 239.0.0.1
interface fastEthernet 0/0
ip wccp 61 redirect in
ip wccp 61 group-listen
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
Note: Multicast addresses must be between 224.0.0.0 and 239.255.255.255.
To configure multicast groups on the WCCP SteelHead interface
• Connect to the Riverbed CLI on the WCCP SteelHead and enter the following commands:
enable
configure terminal
wccp enable
wccp mcast-ttl 10
wccp interface inpath0_0 service-group 61 routers 239.0.0.1
write memory
restart
Note: You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
Note: You must set the same password on the SteelHead interface and the Cisco router.
Configuring Group Lists to Limit Service Group Members
You can configure a group list on your router to limit service group members (for instance, SteelHead interfaces) by IP address.
For example, if you want to allow only SteelHead interfaces with IP addresses 10.1.1.23 and 10.1.1.24 to join the router service group, you create a group list on the router.
Note: The following WCCP router commands are not required for the example network configurations in this chapter. Use caution when you enter the
ip wccp [SG] router command because each
ip wccp [SG] router command overwrites the previous
ip wccp [SG] router command. You cannot use an
ip wccp [SG] router command to augment
ip wccp [SG] router commands you previously issued. For details, see
Configuring a Basic WCCP Router.
To configure a WCCP router group list
• On the WCCP router, at the system prompt, enter the following commands:
enable
configure terminal
access-list 1 permit 10.1.1.23
access-list 1 permit 10.1.1.24
ip wccp 61 group-list 1
interface fastEthernet 0/0
ip wccp 61 redirect in
end
write memory
Tip: Enter configuration commands, one per line. End each command with Ctrl+Z.
Configuring Access Control Lists
This section describes how to configure access control lists (ACLs). This section includes the following topics:
When you configure ACLs, consider the following guidelines:
• ACLs are processed in order, from top to bottom. As soon as a particular packet matches a statement, it is processed according to that statement and the packet is not evaluated against subsequent statements. The order of your access control list statements is very important.
• If port information is not explicitly defined, all ports are assumed.
• By default, all lists include an implied deny all Cisco command at the end, which ensures that traffic that is not explicitly included is denied. You cannot change or delete this implied entry.
Using Access Control Lists for Specific Traffic Redirection
If redirection is based on traffic characteristics other than ports, you can use ACLs on the router to define which traffic is redirected.
If you only want the traffic for IP address 10.2.0.0/16 to be redirected to the WCCP SteelHead, configure the router according to the following example.
Note: The following router commands are not required for the example network configurations in this chapter. Use caution when you enter the
ip wccp [SG] router command because each
ip wccp [SG] router command overwrites the previous
ip wccp [SG] router command. You cannot use an
ip wccp [SG] router command to augment
ip wccp [SG] router commands you previously issued. For details, see
Configuring a Basic WCCP Router.
To configure specific traffic redirection on the router
• On the router, at the system prompt, enter the following commands:
enable
configure terminal
access-list 101 permit tcp any 10.2.0.0 0.0.255.255
access-list 101 permit tcp 10.2.0.0 0.0.255.255 any
ip wccp 61 redirect-list 101
interface fastEthernet 0/0
ip wccp 61 redirect in
end
interface serial0
ip wccp 61 redirect in
end
write memory
Note: If you have defined fixed‑target rules, redirect traffic in one direction as shown this example.
Note: Enter configuration commands, one per line. End each command with Ctrl+Z.
Cisco Access Control List Command Parameters
This section describes the Cisco access-list router command for using ACLs to configure WCCP redirect lists. For information about ACL commands, refer to your router documentation.
The access-list router command has the following syntax:
access-list <access-list-number> [permit | deny] tcp <source-IP/mask> <source-port> <destination-IP/mask> <destination-port>
access-list-number | Number from 1 to 199 that identifies the access control list. Standard access control lists are numbered 1 to 99; extended access control lists are numbered 100 to199. A standard access control list matches traffic based on source IP address. An extended access control list matches traffic based on source or destination IP address. Riverbed recommends that you use extended IP access control lists. |
permit | Allows traffic redirection. |
deny | Stops traffic redirection. |
tcp | Specifies the traffic to redirect. WCCP only redirects TCP traffic. Use this option only when configuring a redirect list for WCCP. |
source-IP/mask | Source IP address and mask. To set the mask, specify 0 or 1, where 0 = match and 1 = does not matter. For example: • any - Matches any IP address. • 10.1.1.0 0.0.0.255 - Matches any host on the 10.1.1.0 network. • 10.1.1.1 0.0.0.0 - Matches host 10.1.1.1 exactly. • 10.1.1.1 - Matches host 10.1.1.1 exactly. This option is identical to specifying 10.1.1.1 0.0.0.0. |
source-port | Source port number or corresponding keyword. For example: • eq 80 or eq www - Identical options that match port 80. • gt 1024 - Matches any port greater than 1024. • lt 1024 - Matches any port less than 1024. • neq 80 - Matches any port except port 80. • range 80 90 - Matches any port between and including 80 through 90. Cisco routers support many keywords. For details, refer to your router documentation. |
destination-IP/mask | Destination IP address and mask. To set the mask, specify 0 or 1, where 0 = match and 1 = does not matter. For example: • any - Matches any IP address. • 10.1.1.0 0.0.0.255 - Matches any host on the 10.1.1.0 network. • 10.1.1.1 0.0.0.0 - Matches host 10.1.1.1 exactly. • 10.1.1.1 - Matches host 10.1.1.1 exactly. This option is identical to specifying 10.1.1.1 0.0.0.0. |
destination-port | Destination port number or corresponding keyword. For example: • eq 80 or eq www - Identical options that match port 80. • gt 1024 - Matches any port greater than 1024. • lt 1024 - Matches any port less than 1024. • neq 80 - Matches any port except port 80. • range 80 90 - Matches any port between and including 80 through 90. Cisco routers support many keywords. For details, refer to your router documentation. |
Using Access Control Lists with WCCP
To avoid requiring the router to do extra work, Riverbed recommends that you create an ACL that routes only traffic that you intend to optimize to the SteelHead.
Suppose your network is structured so that all internet traffic passes through the WCCP-configured router, and all intranet traffic is confined to 10.0.0.0/8. Because it is unlikely that remote internet hosts have a SteelHead, do not redirect internet traffic to the SteelHead. The following is an example ACL that achieves this goal.
Note: The following router commands are not required for the example network configurations in this chapter. Use caution when you enter the
ip wccp [SG] router command because each
ip wccp [SG] router command overwrites the previous
ip wccp [SG] router command. You cannot use an
ip wccp [SG] router command to augment
ip wccp [SG] router commands you previously issued. For details, see
Configuring a Basic WCCP Router.
To configure an ACL to route only intranet traffic to a WCCP-enabled SteelHead interface
• On the WCCP router, at the system prompt, enter the following commands:
enable
configure terminal
access-list 101 deny ip host <wccp-steelhead-ip> any
access-list 101 deny ip any host <wccp-steelhead-ip>
access-list 101 permit tcp 10.0.0.0 0.255.255.255 any
access-list 101 permit tcp any 10.0.0.0 0.255.255.255
access-list 101 deny ip any any
!
ip wccp 61 redirect-list 101
!
end
write memory
Repeat these commands for each WCCP SteelHead in the service group.
Note: Enter configuration commands, one per line. Press Ctrl+Z to end the configuration.
Configuring Load Balancing in WCCP
You can perform load balancing using WCCP. WCCP supports load balancing using either the hash assignment method or the mask assignment method. This section includes the following topics:
Configuring Load Balancing Using the Hash Assignment Method
With the hash assignment method, traffic is redirected based on a hashing scheme and the weight of the SteelHead interfaces. You can hash on a combination of the source IP address, destination IP address, source port, or destination port. The default weight is based on the SteelHead model (for example, for the Model 5000, the weight is 5000). You can modify the weight on an interface per service group.
To change the hashing scheme and assign a weight on a WCCP SteelHead interface
1. Connect to the Riverbed CLI on the WCCP SteelHead interface and enter the following command:
wccp interface inpath0_0 service-group 61 routers 10.1.0.1 flags dst-ip-hash,src-ip-hash
2. To change the weight on the WCCP SteelHead interface, at the system prompt, enter the following command:
wccp interface inpath0_0 service-group 61 routers 10.1.0.1 weight 20
Configuring Load Balancing Using the Mask Assignment Method
Mask assignment uses 7 bits, which allows for a maximum of 128 buckets (2^7 = 128) for load balancing across SteelHead interfaces in the same service group. When deciding the number of bits to use, always keep in mind the number of SteelHead interfaces in the service group. Ensure that you create enough buckets for all the SteelHead interfaces in the service group. For example, with three SteelHeads with two in-path interfaces each in a service group, use at least 3 bits for mask assignment to create 8 buckets (2^3 = 8). Having more buckets than SteelHead interfaces is not a problem; in fact, it might be necessary to do so to distribute the load correctly. However, if there are more SteelHead interfaces than available buckets, some SteelHead interfaces remain idle.
Mask assignments have two subcategories:
• Address mask - A 4-byte value, each byte of which corresponds to each octet of the IP address.
• Port mask - A 2-byte value used to match the port number.
You can combine address masks with port masks as long as the total number of bits used for the mask assignment value does not exceed 7 bits.
Note: The algorithm used for determining bucket allocation and assignment is vendor specific; there is no common standard in the industry. The following explanation is specific to SteelHeads. Other vendors who support load distribution with mask assignment might use a different algorithm to distribute the loads amongst their own devices.
The default mask on the SteelHead is 0x1741. Change this default to suit your network. At a minimum, the number of bits you use in the mask must provide enough buckets to load balance the traffic among the SteelHeads in the cluster. In addition, make sure there are enough buckets created to fairly load balance the traffic.
When determining bucket allocations, mask assignment uses the WCCP weight parameter. The higher the weight, the more buckets are allocated to that SteelHead interface. However, even if all the SteelHead interfaces in the service group share the same weight, the distribution among the SteelHead interfaces might not be perfectly equal if the number of buckets is not divisible by the number of SteelHead interfaces in the service group.
A mask of 0x1 creates two buckets (2^1=2), which is appropriate for a deployment consisting of a single SteelHead or a cluster of two. A mask of 0x3 creates four buckets (2^2=4), but is most likely not appropriate for a three SteelHead deployment because it cannot lead to a fair distribution of the traffic.
When the number of buckets is not divisible by the number of SteelHead interfaces in the service group, the remaining buckets are assigned to the SteelHead interface with the highest effective weight. If all weights are equal, then the interface with the lowest IP address receives the remaining buckets. In other words, the remainder from the following operation is assigned to the SteelHead interface with the highest effective weight:
<number-of-buckets> modulo <number-of-steelhead-interfaces>
Effective weight with multiple in-path WCCP means each of the configured SteelHead interface weights are divided by the number of that SteelHead interfaces participating that service group. For example, a SteelHead has two interfaces participating in service group 61. They have a weight of 100 configured. Their effective weight is 100/2, or 50, per interface. A SteelHead with a single interface participating in a service group with a weight of 100 configured would simply have an effective weight of 100.
Example: Bucket Allocation for 8 Buckets and 3 SteelHead Interfaces of Equal Weight
When there are eight buckets and three SteelHead interfaces of effective equal weight (SteelHead1 inpath0_0 (weight 200): 1.1.1.1, SteelHead1 inpath0_1 (weight 200): 2.2.2.2, and SteelHead2 inpath0_0 (weight 100): 3.3.3.3), the initial bucket allocation is:
• Interface 1.1.1.1 - two buckets
• Interface 2.2.2.2 - two buckets
• Interface 3.3.3.3 - two buckets
Using the expression 8 mod 3 = 2, the remaining two buckets are assigned to Interface 1.1.1.1. The final allocation is:
• Interface 1.1.1.1 - four buckets (50%)
• Interface 2.2.2.2 - two buckets (25%)
• Interface 3.3.3.3 - two buckets (25%)
Example: Bucket Allocation for 16 Buckets and 3 SteelHead Interfaces of Equal Weight
The same operation applies to 16 buckets and 3 SteelHead interfaces of equal effective weight.
Using the expression 16 mod 3 = 1, the final allocation is:
• Interface 1.1.1.1 - six buckets (37.5%)
• Interface 2.2.2.2 - five buckets (31.25%)
• Interface 3.3.3.3 - five buckets (31.25%)
The example shows that the number of bits used for the mask and the number of SteelHead interfaces in the service group affect the accuracy of the load distribution.
Using the Weight Parameter
To assign weight in the mask assignment method, you use the weight parameter in the same way as the hash assignment method: for example,
wccp interface inpath0_0 service-group 61 routers 10.1.0.1 weight 20
You can also assign weight to each SteelHead interfaces so that the larger model SteelHeads are assigned more buckets. However, doing this is generally unnecessary because the SteelHead models have appropriately larger default weight values relative to their higher capacities. WCCP uses the following formula to assign buckets to each SteelHead interface:
Bucket allocation = (bucket/size/sum of effective weight) * configured weight of the SteelHead interface
Example: Bucket Allocation for 8 Buckets and 2 SteelHeads with Single Interfaces with Different Weights
In this example, SteelHeadA has a single in-path interface, inpath0_0, with a weight of 25 and SteelHeadB has a single in-path interface, inpath0_0, with a weight of 50.
8 buckets
Total SteelHead interface weight: 25 + 50 = 75
SteelHeadA inpath0_0 weight is 25
(8/75) * 25 = 2.7 buckets
SteelHeadB inpath0_0 weight is 50
(8/75) * 50 = 5.3 buckets
Because the number of allocated buckets must be integers, the number of buckets is rounded to the nearest integer. In this case, WCCP allocates three buckets to SteelHead A inpath0_0 and five buckets to SteelHeadB inpath0_0.
Example: Bucket Allocation for 16 Buckets and 3 different SteelHead Models, Each with Two In-Path Interfaces
In this example, SteelHeadA has two interfaces, inpath0_0 with IP address of 10.1.1.1 and inpath0_1 with IP address 10.1.1.2, each configured with weight 25. SteelHeadB has two interfaces, inpath0_0 with IP address of 10.1.1.3 and inpath0_1 with 10.1.1.4, each configured with weight 50. SteelHeadC has inpath0_0 with IP address 10.1.1.5 and inpath0_1 with IP address 10.1.1.6, each configured with weight 75. The mask for the service group is 0xE, creating16 buckets.
The total weight equals the effective weight of all SteelHead interfaces. The effective weight of a SteelHead interface is equal to its configured weight divided by the number of that SteelHead interfaces participating in the service group.
Total weight: A-in0_0/2 + A-in0_1/2 + B-in0_0/2 + B-in0_1 + C-in0_0 + C-in0_1
Total weight: (25/2) + (25/2) + (50/2) + (50/2) + (75/2) + (75/2) = 150
Allocation:
SteelHeadA inpath0_0 (10.1.1.1): (12.5/150) * 16 buckets = 1.33 = 1 bucket
SteelHeadA inpath0_1 (10.1.1.2): (12.5/150) * 16 buckets = 1.33 = 1 bucket
SteelHeadB inpath0_0 (10.1.1.3): (25/150) * 16 buckets = 2.66 = 2 buckets
SteelHeadB inpath0_1 (10.1.1.4): (25/150) * 16 buckets = 2.66 = 2 buckets
SteelHeadC inpath0_0 (10.1.1.5): (37.5/150) * 16 buckets = 4 = 4 buckets
SteelHeadC inpath0_1 (10.1.1.6): (37.5/150) * 16 buckets = 4 = 4 buckets
Flow Data in WCCP
In virtual in-path deployments such as WCCP, traffic moves in and out of the same WAN interface. The LAN interface is not used. When the SteelHead exports data to a data flow collector, all traffic has the WAN interface index. Although it is technically correct for all traffic to have the WAN interface index because the input and output interfaces are the same, it is impossible to use the interface index to distinguish between LAN-to-WAN and WAN-to-LAN traffic.
You can configure the fake index feature on your SteelHead to insert the correct interface index before exporting data to a data flow collector.
For information about configuring the fake index feature, see
Configuring Flow Data Exports in Virtual In-Path Deployments.
Verifying and Troubleshooting WCCP Configurations
This section describes the basic commands for verifying WCCP configuration on the router and the WCCP SteelHead.
To verify the router configuration
• On the router, at the system prompt, enter the following commands:
enable
show ip wccp
show ip wccp 61 detail
show ip wccp 61 view
To verify the WCCP configuration on an interface
• On the router, at the system prompt, enter the following commands:
enable
show ip interface
Look for WCCP status messages near the end of the output.
To verify the access control list configuration
• On the router, at the system prompt, enter the following commands:
enable
show access-lists <access-list-number>
To trace WCCP packets and events on the router
• On the router, at the system prompt, enter the following commands:
enable
debug ip wccp events
WCCP events debugging is on
debug ip wccp packets
WCCP packet info debugging is on
term mon
To verify the WCCP SteelHead configuration
• Connect to the Riverbed CLI on the WCCP SteelHead and enter the following command:
show wccp interface <interface> service-group 61 detail
WCCP Support Enabled: yes
WCCP Multicast TTL: 1
WCCP Return via Gateway Override: no
Router IP Address: 89.1.1.1
Identity: 1.1.1.1
State: Connected
Redirect Negotiated: l2
Return Negotiated: l2
Assignment Negotiated: mask
i-see-you Message Count: 20
Last i-see-you Message: 2008/07/06 22:05:16 (1 second(s) ago)
Removal Query Message Count: 0
Last Removal Query Message: N/A (0 second(s) ago)
here-i-am Message Count: 20
Last here-i-am Message: 2008/07/06 22:05:16 (1 second(s) ago)
Redirect Assign Message Count: 1
Last Redirect Assign Message: 2008/07/06 22:02:21 (176 second(s) ago)
Web Cache Client Id: 89.1.1.2
Weight: 25
Distribution: 1 (25.00%)
Mask SrcAddr DstAddr SrcPort DstPort
---- ------- ------- ------- -------
0000: 0x02000000 0x00000000 0x0000 0x0001
Value SrcAddr DstAddr SrcPort DstPort Cache-IP
----- ------- ------- ------- ------- --------
0000: 0x00000000 0x00000000 0x0000 0x0000 89.1.1.2
Web Cache Client Id: 89.1.1.6
Weight: 25
Distribution: 2 (50.00%)
Mask SrcAddr DstAddr SrcPort DstPort
---- ------- ------- ------- -------
0000: 0x02000000 0x00000000 0x0000 0x0001
Value SrcAddr DstAddr SrcPort DstPort Cache-IP
----- ------- ------- ------- ------- --------
0002: 0x00000000 0x00000000 0x0000 0x0001 89.1.1.6
0003: 0x02000000 0x00000000 0x0000 0x0001 89.1.1.6
Web Cache Client Id: 89.1.1.5
Weight: 25
Distribution: 1 (25.00%)
Mask SrcAddr DstAddr SrcPort DstPort
---- ------- ------- ------- -------
0000: 0x02000000 0x00000000 0x0000 0x0001
Value SrcAddr DstAddr SrcPort DstPort Cache-IP
----- ------- ------- ------- ------- --------
0001: 0x02000000 0x00000000 0x0000 0x0000 89.1.1.5
To verify the WCCP bucket allocation
• Connect to the Riverbed CLI on the WCCP SteelHead and enter the show wccp interface <interface> service-group 61 detail command.
This command is available only in RiOS 6.1 or later.
The example shows WCCP bucket allocation details.
– WCCP used 2 bits for the mask, 1 in the Source Address and 1 in the Destination Port:
Mask SrcAddr DstAddr SrcPort DstPort
---- ------- ------- ------- -------
0000: 0x02000000 0x00000000 0x0000 0x0001
– WCCP created four buckets (2^2 = 4) and allocated them to the SteelHead interfaces as follows:
89.1.1.2 was allocated one bucket:
Value SrcAddr DstAddr SrcPort DstPort Cache-IP
----- ------- ------- ------- ------- --------
0000: 0x00000000 0x00000000 0x0000 0x0000 89.1.1.2
89.1.1.5 was allocated one bucket:
Value SrcAddr DstAddr SrcPort DstPort Cache-IP
----- ------- ------- ------- ------- --------
0001: 0x02000000 0x00000000 0x0000 0x0000 89.1.1.5
89.1.1.6 was allocated two buckets because it has the highest IP address of the attached SteelHead interfaces:
Value SrcAddr DstAddr SrcPort DstPort Cache-IP
----- ------- ------- ------- ------- --------
0002: 0x00000000 0x00000000 0x0000 0x0001 89.1.1.6
0003: 0x02000000 0x00000000 0x0000 0x0001 89.1.1.6
The following table lists some of the configurations that the show wccp service-group <num> details CLI command displays.
Configuration | Example |
Redirection Method | Redirect Negotiated: l2 |
Return Method | Return Negotiated: l2 |
Assignment Method | Assignment Negotiated: mask |
GRE Encapsulation | WCCP Return via Gateway Override: no |
WCCP Control Messages | i-see-you Message Count: 20 |
For information about troubleshooting WCCP and other deployments, see
Troubleshooting SteelHead Deployment Problems.