WAAS – WCCP Methods

In this post, I want to talk solely about how WCCP redirection works.  We are going to look at a real example of WAAS in action and look at the different ways that WCCP can be configured to redirect traffic to the WAEs. 

Redirection Methods
There are two WAAS redirection methods, WCCP GRE and WCCP L2…

WCCP GRE
WCCP GRE is in most cases, the default redirect method.  WCCP GRE works by creating dynamic WCCP GRE tunnels.  When I call them ‘WCCP GRE’ tunnels, I mean that they are fully automated and handled entirely by the WCCP process.  That being said, there is no real tunnel configuration that needs to be done for them to work.  Once the endpoints (the router and the WAE in this case) acquire the WCCP service, they negotiate and dynamically build a WCCP GRE tunnel to use for the redirected traffic.  This can cause some confusion when looking at a packet capture.  For instance, let’s look at this piece of the network diagram…

In my scenario, I’m using WCCP GRE for redirection off of the WAN-DC-EDGE-1 router to WAE-1.  Now, if we ran a packet capture on that interface, one might expect to see GRE encapsulated packets with an outer header source of 10.10.10.1 with a destination of 10.10.10.2.  That’s not actually the case.  A packet capture does show GRE encapsulated packets, but not with the IP addressing that you might expect…

Note that the source IP address is 192.168.100.2.  Where does that come from?  If you take a look at the WAN-DC-EDGE-1 router, you can see that the WCCP service assigned that as the WCCP router ID…

The inner packet header is the source of the server (10.64.32.20) and the destination of the client (192.168.0.50) just as we expected.  So as you can see, much of the WCCP GRE method just ‘works’.  The redirection is handled by GRE, but you aren’t really meant to see the configuration or manipulate it. 

WCCP L2
If we were to modify this topology and hang the WAE off of the data center switch, we could take advantage of WCCP L2 (Layer 2) redirection.  This method of redirection works by having the MLS rewrite the layer 2 destination address to that of the WAE rather than that of the true next hop.  The topology of the DC would look something like this…

The configuration on the switch side is identical to that of the router.  We just need to determine what interfaces should be used for redirection.  In my case, I use the VLAN interface that the CM and the servers live on for service group 52 and the interface facing the WAN-DC-EDGE-1 router for service group 41.  Let’s update the diagram with MAC addresses so you can see the layer 2 redirection in action…

Now, if we take a look at a redirected packet, we can see the redirection occurring…

In this packet, you can see that the layer 2 source of the address is 0021.d7c5.f245 with a destination of 000c.29f2.cac3.  The switch in this case rewrote the layer 2 header to push the traffic to the WAE rather than onto it’s next layer 2 hop of 0021.a0f1.61fc (the WAN router).

The switch I’m using for WCCP in this example is a 3750.  With the 3750s (and other MLS) it’s important to note that they only support the WCCP mask assignment method.  The WCCP peering won’t even form if you configure the WAE for the hash method. 

Egress Methods
There are two egress methods that the WAE can use to return the traffic back to the device it came from.  The default method is IP forwarding where the WAE just performs a normal IP lookup and sends the traffic on it’s way.  The other method is a little more interesting and can be used to solve some of the infinite loop problems we talked about in the last post.  That method is Generic GRE…

So let’s leave the WAE where it is, but put the WCCP redirection back on the WAN router.  Recall in the last post that we showed how this can cause an infinite loop issue since we are redirecting traffic that has already been sent to the WAE.  Let’s set the following configuration on the WAE…

And add the following configuration to the router…

interface Tunnel1
description WAAS Generic GRE Return
ip address 1.1.1.1 255.255.255.252
no ip redirects
tunnel source FastEthernet0/0
tunnel mode gre multipoint

FastEthernet0/0 is the interface on the router that’s pointing back to the MLS.  Once these two items are configured, WAAS will once again start working without the infinite loop problem.  The reason is rather simple actually.  Since we are returning the packets to a tunnel interface, we aren’t actually passing through FastEthernet0/0 hence we aren’t hitting the WCCP redirection commands.  Since the tunnel is a GRE multipoint, the tunnel will dynamically form.  The IP address is required simply to IP enable the interface.  It’ really isn’t used for anything else. 

Summary
I hope you gained some insight into how WCCP works.  I’ll admit, I find the configuration frustrating at times.  Cisco doesn’t have a lot of details on how the WCCP GRE dynamic service works which makes it had to troubleshoot and fully understand.  The Generic GRE return is in the same boat with not a lot of info out there besides ‘configure this and it should work’.