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 PasswordConfiguring Multicast GroupsConfiguring Group Lists to Limit Service Group MembersConfiguring Access Control ListsConfiguring Load Balancing in WCCPSpecifying 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. 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 <your_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 <your_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
You must set the same password on the SteelHead interface and the Cisco router.
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.
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.
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
You must save your changes or they are lost upon reboot. Restart the optimization service for the changes to take effect.
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.
The following router command is 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:
Using Access Control Lists for Specific Traffic RedirectionCisco Access Control List Command ParametersUsing Access Control Lists with WCCP
When you configure ACLs, consider the following:
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.
The following router command is 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
If you have defined fixed‑target rules, redirect traffic in one direction as shown this example.
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 | Specifies the number from 1-199 that identifies the access control list. Standard access control lists are numbered 1-99; extended access control lists are numbered 100-199. 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|deny | Specifies whether the redirect list allows or stops traffic redirection. Specify permit to allow traffic redirection; specify deny to stop 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 | Specifies the 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 | Specifies the 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 | Specifies the 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 | Specifies the 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.
The following router command is 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.
Enter configuration commands, one per line. Enter 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 MethodConfiguring Load Balancing Using the Mask Assignment MethodUsing the Weight ParameterConfiguring 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
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
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.
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 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). This 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 <the 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 bucketsUsing 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, 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, SteelHead A has a single in-path interface, inpath0_0, with a weight of 25 and SteelHead B has a single in-path interface, inpath0_0, with a weight of 50.
8 buckets
Total SteelHead interface weight: 25 + 50 = 75
SteelHead A inpath0_0 weight is 25
(8/75) * 25 = 2.7 buckets
SteelHead B 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 SteelHead B inpath0_0.
Example: Bucket Allocation for 16 Buckets and 3 different SteelHead Models, Each with Two In-Path Interfaces
In this example, SteelHead A 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. SteelHead B 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. SteelHead C 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:
SteelHead A inpath0_0 (10.1.1.1): (12.5/150) * 16 buckets = 1.33 = 1 bucket
SteelHead A inpath0_1 (10.1.1.2): (12.5/150) * 16 buckets = 1.33 = 1 bucket
SteelHead B inpath0_0 (10.1.1.3): (25/150) * 16 buckets = 2.66 = 2 buckets
SteelHead B inpath0_1 (10.1.1.4): (25/150) * 16 buckets = 2.66 = 2 buckets
SteelHead C inpath0_0 (10.1.1.5): (37.5/150) * 16 buckets = 4 = 4 buckets
SteelHead C inpath0_1 (10.1.1.6): (37.5/150) * 16 buckets = 4 = 4 buckets