Understanding WCCP

Load Balancing and High Availability

WCCP has built-in capabilities that greatly enhance your redundancy and fault tolerance.

Multiple Secure Web Gateway appliances can connect to the same router to support load balancing and failover. Configure the appliances with Central Management and make sure that all appliances have the same value in the WCCP Router Definition field.

The first Secure Web Gateway appliance to come up and establish contact with the router will assign “buckets". Buckets control how load is distributed when using more than one appliance. When a Secure Web Gateway comes on or off line, buckets are reassigned. If the “bucket assigner” goes offline, another Secure Web Gateway appliance takes over bucket assignment.

If WCCP is configured on the router and no Secure Web Gateway appliance is active as peer in the service group, the router will just let the requests through, without redirection. This behavior is called fail-open. If fail-open is desired in a Secure Web Gateway deployment, you have to configure your firewall to allow web traffic from any IP address, so clients can go out directly in case Secure Web Gateway appliances are not reachable.

If fail-close is desired in a Secure Web Gateway deployment, configure the firewall to allow only web traffic from Secure Web Gateway IP addresses. This way, clients will get blocked if they do not go through Secure Web Gateway. Some Cisco IOS versions also allow fail-open or fail-closed to be configured on the router or switch.

We do not recommend using WCCP when the router, clients, and Secure Web Gateway are separated by anything that will do source NATing of client traffic, as this will limit your ability to perform load balancing and will restrict you from using authentication sessions based on time or IP addresses.

Subscription

WCCP works by having the Secure Web Gateway subscribe to the router. The router is not aware of the Secure Web Gateway proxy until it subscribes. There are no settings that need to be configured on the router to tell it about the proxy.

It is also possible to have Secure Web Gateway subscribe to multiple routers in the same configuration using the same service ID or to multiple routers with different service IDs.

Here I Am & I See You (with Examples)

WCCP uses Here I Am and I See You packets to subscribe and negotiate settings and also as a health check every 10 seconds.

Here I Am is sent from Secure Web Gateway to the WCCP device to subscribe to the router and tell it about the settings that it is configured for. This includes the ports that can be redirected, the assignment weight, service ID, assignment method, redirect method, and the IP address that traffic should be redirected to.

The I See You is the acknowledgement from the router to Secure Web Gateway to inform it that the subscription is successful. It includes the router ID, which is the  highest interface IP address on the router.

If a router does not receive a Here I Am packet over a time period of 25 seconds, it will unicast a removal query message to the Secure Web Gateway proxy to request that it should respond immediately. If no response is received within 5 seconds, the proxy is considered offline and removed from the WCCP pool.

You may configure your network to fail open or closed depending on your policy.

Here I Am

I See You

Prerequisites

A few things should be considered when configuring WCCP.

Settings

All settings for WCCP are configured on the user interface for Secure Web Gateway under Configuration > Appliances > <Appliance ID> > Proxies > Network Setup. Make sure that Proxy (optional WCCP) is selected here, then select Transparent Proxy > WCCP.

Use the options under WCCP Service, which appear, to add or modify settings for a WCCP service.

Service ID — The service ID must match the router configuration. It is highly recommended to use a value from 51 to 98.

Service IDs 0 to 50 are static and reserved for “well known services” with preconfigured settings. Service IDs 51 to 255 are dynamic and involve negotiation between the WCCP peers.

The configuration with the sample settings shown above has 51 as the service ID.

Web-cache is a Cisco-reserved keyword that refers to well-known service ID 0 and will only redirect to port 80 regardless of port settings on your user interface, see also http://www.ciscopress.com/articles/a...92686&seqNum=2. This article focuses on WAAS, but includes useful information about WCCP.

WCCP Router Definition — Multiple routers can be listed in the Router field or a multicast address can be used. Note that if a multicast address is used, “group-address” and “grouplisten” must be used in the router or switch configuration Ports to be redirected: Keep in mind that the Web Gateway is primarily an HTTP proxy so any ports redirected to the HTTP  proxy port must be used for valid HTTP traffic or tunneled SSL traffic.

Redirection of FTP traffic or other protocols is not supported. Any ports that need to be filtered and treated as SSL, other than 443, must also be added under Configuration > Proxies > HTTP Proxy > Edit Proxy Listener > Ports treated as SSL. If WCCP v1, is used, there are no configuration options available on Web Gateway and only port 80 traffic will be  filtered.

Proxy Listener Address — This the physical IP address for the local NIC that you wish to have traffic redirected to. Assignment Method: The bucket assignment method is the method used by WCCP to determine which Secure Web Gateway appliance to use for the redirection.

Certain Cisco switches and routers will only support MASK assignment. See the documentation for the software revision and hardware model of the switch or router. ASA and PIX firewalls currently support only HASH assignment.

Assignment Weight — Controls how much of the total load can be re-directed to the proxy. This only needs to be adjusted if you have different types of Secure Web Gateway appliances participating in the same WCCP pool and you need to divert more traffic to a stronger appliance. Otherwise, it is recommended to leave it at the default value of 1000.

Input for load distribution — When running multiple Secure Web Gateway appliances, load distribution can be configured for the proxies on them. Data packets can be distributed to these proxies based on the masking of source or destination IP addresses and port numbers or on a hash algorithm.

We recommend, as a best practice, to select Source IP as the input for load distribution. This ensures that a user always hits the same proxy to avoid breaking sessions.

GRE encapsulation — Generic Routing Encapsulation (GRE) works by encapsulating the original packet inside a new packet with additional headers and sending it over the GRE tunnel from the router to the proxy. This method has more overhead, but has the benefit of being able to work across subnets.

L2-rewrite — L2-rewrite means Layer 2 rewrite. This method works by re-writing the packet's target MAC address to the MAC address of the proxy. This method works only if the router and the proxy are on the same subnet.

L2 Redirect Target  — The local NIC that you wish to handle the redirected traffic.

WCCP is used to send traffic back to the clients (WCCP return method)

WCCP is only used when traffic is intercepted and redirected to Secure Web Gateway. All traffic from Secure Web Gateway to the client will be sent directly there, which requires proper routing and firewall rules.

The WCCP return method is part of the WCCP specification. It is designed to be used in error conditions, so caches or proxies can reject traffic and send it back to the router.

The return method is not used for "returning" traffic back to clients. Secure Web Gateway does not use the return method and will never send any traffic back to the router. This is also why there is no configuration option for it.

The WCCP router must be configured with the Secure Web Gateway IP addresses

WCCP is a subscription protocol. The Secure Web Gateway appliances must subscribe to the router and this is how the router "learns" the Secure Web Gateway IP addresses,

All you need to do on the router side is configuring the WCCP service ID and the appropriate network interface to apply it to. After that you can have as many Secure Web Gateway appliances subscribe to the router as you want.

Dashboard

The dashboard can be found under Dashboard > Charts and Tables > System Summary.

It is useful for verifying the subscription status and statistics at a glance. It will show you the current subscribed service ID, router IP address, forwarding and return methods, and assigned buckets.

Even more important, it shows the times when the last Here I Am and I See You packets were sent, so you can verify that the health check is working, as long as these values are current.

Command Line

On a command line, you can do the following to troubleshoot WCCP issues.

• Verify that the redirect on the Secure Web Gateway proxy from port 80 or 443 to the proxy port has been configured correctly on the command line by entering:
  
  iptables -t mangle -L

• Check that Secure Web Gateway sends Here I Am and receives I See You packets (UDP 2048). You can use the following tcpdump string for this:
  
  tcpdump –npi eth0 port 2048

  • Make sure that the web cache ID is the same as the IP address or addresses of Secure Web Gateway appliance or appliances in the configuration.

  • Make sure that the bucket assignment method matches what is configured on Secure Web Gateway.

  • Make sure the redirect method is the same as what is configured on Secure Web Gateway.

• Check that the GRE-encapsulated or L2-rewritten packets are reaching Secure Web Gateway.

  • For GRE, use this command:
    
    cpdump –npi eth0 ip proto 47

  • For L2, use this command:
    
    tcpdump –npi eth0 not host < Secure Web Gateway IP address>

  • Verify that the source IP address of the GRE packets is the one configured for the router on Secure Web Gateway. 

  • Verify that the source IP address of the L2 packets is the client IP address.

• Check that redirected packets are received by Secure Web Gateway. Use the #ifconfig command and watch packets and bytes received by gre0 device.
  
  Note that filtered content is returned directly from Secure Web Gateway to the client. It is not encapsulated.

• The following commands are useful for troubleshooting from the router side:

  • show ip wccp detail

  • show ip wccp 51 detail

  • show sdm prefer (3750 and some other low end switches)

  • debug ip wccp packets

  • debug ip wccp events

• Things you might see when taking a network capture on Secure Web Gateway

  • SYN + No SYN/ACK
    
    Check that the proxy listener is not bound to a specific IP address If you switched from any network drive mode, make sure you rebooted

  • SYN + SYN/ACK + nothing after (or repeated SYN)
    
    Secure Web Gateway is likely not able to contact the clients directly. Need to determine what is in the path between client and Secure Web Gateway.

  • Packets getting lost due to size when using GRE encapsulation
    
    There  have been a few instances where GRE encapsulation caused packets to become too large to be forwarded and were subsequently dropped by the router. Lowering the MSS (ex: 1432) on the Proxy Listener definition on Secure Web Gateway may solve this.
    
    This link may also help if there is a fragmentation problem on the router side and adjusting  the Secure Web Gateway MSS does not solve the problem: http://www.cisco.com/en/US/tech/tk82...ies_white_paper09186a00800s6979.shtml#t5.