Unlike many of my articles up until now, when I say something is often perceived as being more difficult than it really is, WCCP is the exact opposite. While WCCP seems really simple and straightforward on the outside, it is often far more complex than it would seem. In this article, we’ll be going through what WCCP is, how traffic is forwarded between a WAN optimizer and a router via WCCP, and how to configure WCCP.
WCCP stands for Web Cache Communication Protocol. Unfortunately, the name WCCP does not really give you a hint as to what it does, why it needs to do it, or how it does what it does. Starting off with the basics, we can define what WCCP does. Simply stated, WCCP intercepts packets entering or leaving one interface and it redirects to a device attached out a different interface. You can almost think of WCCP as a detour you would run into during road construction. Traffic WANTS to go straight through to its destination, but WCCP forces that packet to go around the long way before getting back on its original path. The why of WCCP varies. But, for the most part, it’s because you want that traffic to be changed or modified in some way by a specialized device. That device is usually what is referred to as a WAN optimizer.
Perhaps the reason that WCCP is considered so simple is because lots of people configure it in a lab environment as a part of their test preparation, and a much smaller subset of people actually use WCCP in a production environment.
The intricate details of WCCP are often discovered during the attempt to get it working – and whenever you are learning intricate details during maintenance windows, it is usually a pretty safe bet that there will be a lot of head banging going on. One thing that adds to the difficulty of WCCP to troubleshoot is that WCCP is the gray-area bridge-like protocol that links network administrators with administrators of WAN optimizers – each know their device pretty well, but neither one really understands exactly how traffic is sent between the two devices. It’s easy to conceptualize, but far harder to get working.
The first thing we’ll review in regards to WCCP is the transport for getting traffic from the router to the WAN optimizer, and then back from the WAN optimizer to the router. There are two main transport methods – GRE Tunneling (Generic Routing Encapsulation) and Layer 2. GRE is where any traffic sent by the router to the WAN optimizer has a GRE header added to it. The source on the GRE tunneled traffic is the WCCP source of the router (which may or may not be configurable, depending on the version of code your router is running), and the destination is the WCCP IP of the WAN optimizer – which usually is configurable, though this likely varies from optimizer to optimizer. After traffic has been processed by the WAN optimizer, the headers are simply reversed (source of WAN optimizer, destination of router). On most Cisco platforms capable of WCCP, GRE encapsulation is going to be done in software by the CPU – this means that the CPU level on your device will probably run a little bit hotter with GRE WCCP. In WCCP GRE mode, you do not have to configure any tunnel interface. The router will do this automatically when the WCCP peering comes up. Once up, you will see a dynamically created tunnel interface. Do not attempt to modify this tunnel interface in any way. Most IOS versions will actually throw an error and not let you do so if you try, but it is definitely better to be safe than sorry.
The other method of getting traffic from the router to the WAN optimizer and back again is referred to as layer 2. In layer 2 mode, rather than wrapping a new GRE header around every packet, the device just rewrites the source/destination MAC addresses. The source MAC would be the source MAC address of the router interface through which the WAN optimizer is logically connected via. The destination MAC address would be the MAC address associated with the WCCP IP address of the WAN optimizer. Because on most platforms, rewriting the layer 2 header is something the hardware can handle directly without having to involve the CPU much if at all, you may see lower CPU when using layer 2. Because of the differing ability of routers to perform certain functions in hardware, you may see that some WCCP peerings will not come up with layer 2.
Though it may seem somewhat obvious, I’ll mention it nonetheless. GRE is the only option you have if the WAN optimizer is not logically connected directly. When I say logically connected directly, I mean if your “show ip route” for the WAN optimizer IP does not say “directly connected,” you will have to use GRE mode. This makes sense in reality. If you were to try to use layer 2 mode, the router would be attempting to use the ARP protocol to find the MAC address associated with the IP of the WAN optimizer. You will of course never be able to do that if the WAN optimizer and router are not on the same subnet with one another. But with GRE, you can write the destination IP address in the GRE header to be whatever you want, and then just let your network take care of the routing.
There is no way to specify that you want either layer 2 or GRE on the router itself. That setting is configured on the WAN optimizer. When the router and WAN optimizer are negotiating the peering, the WAN optimizer will attempt to negotiate either GRE or Layer 2. As long as that particular mode is supported by the router, the peering should come up. However, if it is not, you would see errors about not supporting the required mode on the router.
So now that we understand a few of the mechanics of WCCP, we can take a look at how to configure a router for a WCCP peering. Fortunately, this part of WCCP is pretty straight-forward. Keep in mind, however, that bringing up a peering is NOT going to cause packets to be redirected. You have to enable redirection on an interface to do that. Bringing up a WCCP peering involves calling a couple of objects that you have predefined from a single line of code. Of course, you need to create the objects you are calling first.
First, you will want to define what IPs you will allow the router to peer with. That is done with a standard access control list, as follows. Of course, the name of the said access control list is completely up to you.
Ip access-list standard WCCP_PEER
The next thing to do is to create an extended access list that defines what will be redirected. This is not technically required, but highly recommended. Doing so gives you the ability to modify at any time what is redirected vs. what is not. This can prove extremely valuable when you are wondering if a particular application is being “broken” by some weird thing the WAN optimizer is doing to its traffic. Rather than having to tear down the WCCP peering (affecting production traffic) and recreate a new one which calls an access control list that controls what is sent, you just modify the existing access list in a completely non-impacting manner. It also allows you to use the hit counters associated with an ACL to see if a certain type of traffic is flowing or not.
Let’s say that you wanted to send everything except Microsoft Remote Desktop to the WAN optimizer. That could be accomplished with the following ACL. Note, just because you are “denying” the traffic, doesn’t mean you will drop the traffic. The router logic processes the deny as you wanting to deny it from being sent via WCCP to the WAN optimizer. The traffic is still allowed to flow through the router, and just isn’t redirected.
Ip access-list extended TRAFFIC_TO_WCCP
Deny tcp any any eq 3389
Deny tcp any eq 3389 any
Permit ip any any
Now that you have defined all of your called objects, you can create the single line of config that brings everything together and is actually what starts the WCCP neighborship negotiation between the WAN optimizer and the router. This is typically defined as something like this. The WCCP group number can be any number between the range of 0 and 254. As a general rule, you should use a number in the range of 90-97, which per the RFC are supposed to be the user-configurable ranges – think of this as similar to private address space. Certain types of traffic are associated with some of the service group numbers outside of the 90 to 97 range. Of course, password is optional, but highly recommended. You can imagine it would be a hacker’s paradise to be able to bring up a WCCP peering with some unsuspecting and unsecured router and be able to get 100 percent of the traffic entering and exiting a router.
Ip wccp <group number> redirect-list TRAFFIC_TO_WCCP group-list WCCP_PEER password 0 <xxx>
Again, with WCCP, this is only half of the story. The administrator of the WAN optimizer is also going to have to configure WCCP. But, that is outside of the scope of this article. And even if it were in scope, it would take a tremendous amount of time to attempt to lay out the GUI-based configuration of WCCP on all the various vendors of WAN optimizers – Bluecoat, Riverbed, Citrix, etc.,
With the single line of config, you need to keep in mind that if the interfaces you plan on redirecting traffic to/from on is in a VRF, the WCCP peering configuration needs to reflect that. An example would be something like this.
Ip wccp vrf INSIDEVRF <group number> redirect-list TRAFFIC_TO_WCCP group-list WCCP_PEER password 0 <xxx>
Only newer versions of code support the ability to specify VRFs in the WCCP peering statement. The feature you would want to look to make sure was supported in your version of code, should you be using VRFs, is VRF-Aware WCCP. And if you need to upgrade code to support VRF-aware WCCP, always take a look to ensure that licensing (if moving to 15.x code) and/or DRAM/memory requirements are not going to pose additional problems.
So now that the WCCP peering is up, you can configure redirection. This is what actually tells the router to intercept traffic and send it to the WAN optimizer for which there is an active peering. WCCP redirection is unique per group. So your redirection command needs to match the group number that you configured in the WCCP peering configuration. Redirection can be configured for inbound traffic, outbound traffic, or both. If you configure inbound redirection, you are telling the router to take any packet coming INTO that interface that matches the redirect-list and send it to the WAN optimizer. If you configure outbound redirection, you are telling the router to take any packet LEAVING that interface that matches the redirect-list and send it to the WAN optimizer.
Ip wccp <group number> redirect in
Ip wccp <group number> redirect out
As to whether you want to configure inbound, outbound, or both, that is more a function of the way in which the WAN optimizer performs acceleration/optimization than it is anything else. Generally, you’ll need bidirectional redirection if the WAN optimizer is doing everything transparently. By transparently, I am referring to the WAN optimizer not tunneling the traffic to its other WAN optimizer peer (aka leaving the IPs and ports unchanged). If the WAN optimizer is in fact changing the source or destination IP or port of the traffic when it gets it, it is likely that only outbound redirection on a single interface is required. Again, however, this is completely a function of how the WAN optimizer does its WAN optimization and is beyond the scope of this article.
In summary, while this article cannot attempt to provide a complete look at all of the potential issues one could run into with WAN optimization, it does lay the groundwork for understanding the networking component as it relates to WCCP.