WAAS

You are currently browsing articles tagged WAAS.

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…

image

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…

image

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…

image

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…

image

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…

image 

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…

image

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

image

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…

image

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…

image

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’. 

Tags:

As a network engineer, what I concern myself with (mostly) is what the packet flow looks like.  When you talk about adding something like WAAS to an existing network, there are LOTS of considerations to take before just slapping it in.  Namely, how are you going to modify the traffic flow to get the traffic you want to optimize to the WAEs.  Let’s talk first about the interception methods and then touch a little on the flow of traffic to and from a WAE.

Redirection Types
The most basic WAAS deployment involves inline mode.  That is, the WAE sits physically cabled in the path of traffic.  I don’t agree with this type of deployment so I’m not going to spend a lot of time talking about it.  The bottom line is that I’m not a fan of putting appliances like this (IPS, WAEs, etc) physically inline without having some kind of automatic bypass in case the device tanks.  Once you make that consideration, true content redirection seems to make the most sense.  So let’s talk about the redirection methods.  WAEs can have traffic redirected to them a few different ways.  You need to tell the WAE which way you plan to send traffic to it.  The WAE considers this to be it’s ‘interception method’…

image 
You can redirect traffic to the WAE with either WCCP, an AppNav controller, or with VMware vPath (vn-service).  I’m going to focus on the WCCP side of things during this post since that’s the most common type. 

Once you’ve picked your interception method, you need to start thinking about traffic flow.  WAAS uses the following terms to describe traffic flows…

Redirected Traffic – Traffic being redirected to the WAE out of the normal network flow.  That is, traffic to be optimized by the WAE before being sent on it’s way.

Return Traffic – Traffic not processed by the WAE and sent back to the redirection device.  Most commonly this includes traffic that can’t be optimized or traffic that is excluded by a interception ACL on the WAE.  For instance, UDP traffic can’t be optimized by the WAE.  That being said, if it gets redirected to the WAE it will always be ‘returned’.

Egress Traffic – Traffic processed by the WAE and sent on it’s way.  Note, that the key word here is ‘processed’.  The WAE doesn’t have to optimize it in order for it to be counted as egress traffic.  If the WAE looks at the traffic, matches it to a rule that tells it to ‘pass-through’, and forwards it, that would still count as egress traffic. 

So now that we have some basics, let’s look at my lab setup so we can talk about traffic flow and redirection/interception methods…

image

Sorry if that’s too small.  You might have to click on it and make it bigger to see what I’m talking about.  Basically, we have a branch site on the left and a DC site on the right.  The CM (central manager) and WAE-1 live in the DC with WAE-2 living at the remote branch site.  The two sites are connected together with a simulated WAN connection throwing 100ms of latency in path. 

The traffic we are interested in optimizing is user traffic at the branch talking to an apache web server at the DC.  The user will be 192.168.0.50 and the web server is 10.64.32.20. 

With this design, it’s not hard to visualize the design without WAAS.  WAAS in this design sort of ‘hangs’ off of the existing equipment.  They aren’t in path, and they don’t require me reconfiguring (taking down) the network to get them working. 

So let’s talk a little bit about how we plan on getting traffic to the WAEs.  In this case, WCCP seems to be the best fit.  Since the WAE’s are being hung off an interface on the WAN router, we can very easily WCCP traffic from the router, to the WAE, and back.  Traffic flow would look something like this…

image

The green arrows show the traffic flow from the client to the web server and the orange arrows show the return path.  With WCCP, configuring interception to match this flow is very important.  You need to not only tell WCCP what traffic to send for redirection, you need to tell it which interfaces to do this on.  The Cisco recommendation is to do this with two ‘redirect in’ statements.  That is, pick the two physical interfaces that see the traffic flow, and configure inbound redirection on both.  The alternative would be to configure a single interface for both inbound as well as outbound redirection. 

Configuring WCCP
WCCP is a negotiated protocol.  You’ll notice that you configure some things on the WAE that the router actually uses (the load balancing method for instance).  Let’s take a look at the configuration on the WAE first.

WCCP works off of service group numbers.  You need to define two service groups for each WAE.  The WAE will let you choose the first service ID, but always automatically choose the next number as the second service ID…

image

You also need to tell the WAE what routers it will be talking WCCP with.  This can be one or many.  Any routers defined have a chance (if they have the proper WCCP config themselves) of forming a WCCP peering with the WAE…

image

In many cases, you’d have more than one WAE in the same WCCP cluster.  When that occurs, WCCP needs a mechanism in which to determine which flows go to which WAEs.  This is EXTREMELY important.  For WAAS to work, the same connection needs to land on the same WAE for the duration of the connection.  If it doesn’t, optimization can never occur.  WCCP can use either hash or mask assignment.  Hashing works by hashing parts of the source or destination IP and/or port and doing a XOR on them.  Mask works by defining a mask to use for WCCP and ‘masking’ it with the packets source or destination IP address.  Once the mask is applied, only the relevant bits are left.  All possible values for these bits are assigned to 8 hash buckets.  In turn the WAEs split the hash buckets up between them.  The binary value of the masking function returns a value which is assigned to a particular hash bucket which is then assigned to the WAE. 

You’ll note that when you configure the hashing method of WCCP assignment that you are given some further configuration options.  You can pick what IP each service group uses for hashing, source or destination.

image

This is important when considering the traffic flow of the packets through the network.  Let’s take a quick look at the router configurations and then talk about why the hashing method and service group numbers are important. 

WAN-DC-EDGE-1
interface FastEthernet0/0 (LAN)
ip address 10.0.0.2 255.255.255.0
ip wccp 52 redirect in

interface FastEthernet0/1 (WAN)
ip address 75.75.75.1 255.255.255.252
ip wccp 51 redirect in

interface FastEthernet0/2 (WAAS)
ip address 10.10.10.1 255.255.255.0

ip wccp 51 redirect-list WAN_TO_LAN group-list WAE_LIST
ip wccp 52 redirect-list LAN_TO_WAN group-list WAE_LIST

ip access-list standard WAE_LIST
permit 10.10.10.2
!
ip access-list extended LAN_TO_WAN
deny   tcp any any eq 3389
permit tcp any 192.168.0.0 0.0.0.255
ip access-list extended WAN_TO_LAN
deny   tcp any any eq 3389
permit tcp 192.168.0.0 0.0.0.255 any

So that’s it.  That’s the entire WCCP configuration required to get this working on the router end of things.  Note that we have service group 51 assigned to the WAN interface.  Also note that service group 51 uses the redirect-list of WAN_TO_LAN.  That ACL tells the router to redirect traffic coming from the site going anywhere to be optimized. 

If we look at service group 52 we can see that same type of configuration.  It’s applied on the LAN interface and uses the ACL LAN_TO_WAN which specifies traffic coming from anywhere going to the remote site. 

If we look at WAE-2 and the BRANCH-EDGE-2 router this is what we see…

image

BRANCH-EDGE-2
interface FastEthernet0/0 (LAN)
ip address 192.168.0.1 255.255.255.0
ip wccp 51 redirect in

interface FastEthernet0/1 (WAN)
ip address 75.75.76.1 255.255.255.252
ip wccp 52 redirect in

interface FastEthernet0/2 (WAAS)
ip address 10.20.20.1 255.255.255.0

ip wccp 51 redirect-list LAN_TO_WAN group-list WAE_LIST
ip wccp 52 redirect-list WAN_TO_LAN group-list WAE_LIST

ip access-list standard WAE_LIST
permit 10.20.20.2
!
ip access-list extended LAN_TO_WAN
deny   tcp any any eq 3389
permit tcp 192.168.0.0 0.0.0.255 any
ip access-list extended WAN_TO_LAN
deny   tcp any any eq 3389
permit tcp any 192.168.0.0 0.0.0.255

So the config is pretty similar, but there are some differences.  Namely…

DC Service Group
51 – WAN, WAN_TO_LAN
52 – LAN, LAN_TO_WAN

Branch Service Group
51 – LAN, LAN_TO_WAN
52 – WAN, WAN_TO_LAN

Notice that on either box the configuration is to hash on ‘source’ for service group 1 (51).  Let’s imagine for a moment that we did have two WAE’s at each site.  In this configuration, the hashing from client to  server would look like this…

image

1 – Client(192.168.0.50) initiates a connection to the web server (10.64.32.20)
2 – The router receives the packet on it’s LAN interface that’s configured with service group 51.  Service group 51 is defined to look for LAN_TO_WAN traffic which this matches.  Since the router is using service group 51, it knows that it should hash on the source IP address of the packet.  The router runs it’s hashing algorithm and decides to send the packet to the top WAE. 
3 – The WAE optimizes the packet and returns it to the router. 
4 – The router forwards the packet out of it’s WAN interface.  Note that the WAN interface is configured for WCCP, but only in the inbound direction.
5 – The WAN router at the DC receives the packets on it’s WAN interface which is configured for service group 51 inbound WCCP.  The packet matches the defined ACL of WAN_TO_LAN so the router knows it should forward the packet to a WAE.  The router runs it’s hashing algorithm on the source IP address of the packet since it’s using service group 51. 
6 – The WAE optimizes the packet and returns it to the router.
7 – The router receives the packet and performs normal IP forwarding to get the packet to the web server. 

The return traffic would look like this…

image

1 – The server (10.64.32.20) responds back to the client (192.168.0.50)
2 – The router receives the packet on it’s LAN interface that’s configured with service group 52. Service group 52 is defined to look for LAN_TO_WAN traffic which this matches. Since the router is using service group 52, it knows that it should hash on the destination IP address of the packet. The router runs it’s hashing algorithm and decides to send the packet to the top WAE.
3 – The WAE optimizes the packet and returns it to the router.
4 – The router forwards the packet out of it’s WAN interface. Note that the WAN interface is configured for WCCP, but only in the inbound direction.
5 – The WAN router at the branch receives the packets on it’s WAN interface which is configured for service group 52 inbound WCCP. The packet matches the defined ACL of WAN_TO_LAN so the router knows it should forward the packet to a WAE. The router runs it’s hashing algorithm on the destination IP address of the packet since it’s using service group 52.
6 – The WAE optimizes the packet and returns it to the router.
7 – The router receives the packet and performs normal IP forwarding to get the packet back to the client. 

It’s important that the two different service groups hash on different parts of the IP header.  This ensures that traffic coming in and out of a site go to the same WAE.  Luckily the CM saves you from breaking this yourself.  As you can see, you can only pick half of the equation, the other half is greyed out…

image

If you uncheck the top box and check the bottom one, the greyed out side readjusts…

image

If it didn’t do this for you, you could very easily misconfigure this and end up with the packet’s on different WAE’s which could cause some pretty serious problems. 

The last thing I want to talk about in this post is the placement of the WAEs.  Some might look at the network diagram and ask why the DC WAE doesn’t live off of the DC switch.  Let’s take a look at an example of that to see why it’s a bad idea.

Let’s assume that the MLS isn’t WCCP capable so we have to keep running WCCP on the router.  The router interface configured for WCCP would stay the same and be the interface facing the MLS.  Let’s take a look at the packet flow in this case…

image

1 – The web server replies to the client.  The packet goes through the MLS and hits the router interface. 
2 – The router redirects the packet to the WAE
3 – The WAE returns the packet through the MLS to the router.  The packet hits the routers interface.
4 – Since the router interface has WCCP configured, it will again send the packet back to the WAE for processing.  This begins an infinite loop. 

We’d have the same outcome if the WAE lived off it’s own VLAN on the MLS.  It still has to hit the router interface to get to the WAN.  There are a couple of solutions for this problem and I plan to cover those on the next post where we’ll talk about the different WCCP redirection types. 

Tags:

So one of my more recent projects at work has been to get up to speed on the Cisco WAAS platform.  We use WAAS quite heavily on the WAN side of things and it makes a considerable difference.  Put simply, if we turn it off, the users complain. 

I don’t have a ton of WAN acceleration experience but when you break WAAS down into it’s core components, it’s really not that hard to understand.  So let’s do a couple of quick breakdowns. 

WAAS hardware Components
There are a few main components to the WAAS solution.  Namely, there is the WAE (Wide-Area Acceleration Engine) and the CM (Central Manager).  The WAE’s do the actual WAN acceleration while the CM(s) provide the central management for the entire platform.  When you receive a WAE, you can boot it up, type ‘setup’, answer a few questions, tell it where the CM is, reboot it, and never ever log into the WAE directly again.  Once the WAE is joined to the CM, you can do all of the configuration from the CM going forward.

A WAAS appliance can server either the CM or the WAE role.  That decision is made as part of the provisioning process.  I’ll state the obvious here, you generally don’t buy a high end box to serve as the CM.

A more recent addition to the WAAS family is AppNav.  AppNav is another appliance ‘type’ which can server as an advanced load balancer.  We won’t talk much more about AppNav in this post but its worth mentioning at this point. 

WAAS acceleration components
When you look at how WAAS does what it does, there are really 4 main pieces.  In no particular order…

TFO – Transport Flow Optimization (TFO) is Cisco’s proprietary TCP optimization.  Basically, TFO just takes TCP and optimizes it.  You’d be surprised at how much this can speed things up.

DRE – Dynamic Redundancy elimination (DRE) is another Cisco proprietary way of eliminating duplicate pieces of data.  What’s interesting about DRE is that it works on the binary level which means that it’s totally application agnostic.  DRE works by caching the largest chunks of binary data it can find in the raw packet payload.  It then looks for that same chunk in future packets.  If it finds it, it can replace that chunk of binary data with a key.  The WAE at the other end (client side) will also look for these same chunks and give the chunks of data it finds the same key.  When the packet arrives at the client side the WAE can simply do a key lookup and replace the data back into the packet. 

PLZ – Persistent LZ compression.  Standard LZ compression applied to the packets payload. 

AO – Application Optimizations.  These are specific pieces of code written to optimize specific protocols.  For instance, there’s one for CIFS and another for Citrix ICA. 

So that’s really it.  All optimization applied by the WAE can be grouped into one of those 4 categories. 

I don’t want to cover a ton of info in this post since it’s just a intro, but I do want to show you the impact that WAAS can have by applying each of these 4 optimization methods. 

Let’s look at the impact of each of these when applied to a client downloading a file from a server using HTTP.  In my example, a Windows XP client will be downloading a 130 meg file across the WAN from an Apache HTTP server.  Let’s see how long the download takes without WAAS…

image

So 3 minutes and 45 seconds.  Let’s turn on just TFO and see what it does…

image

43 seconds just using TFO.  Let’s try it with TFO, DRE, and PLZ…

image

29 seconds, and if we download it again now that the DRE cache has been populated…

image

Pretty impressive numbers in my opinion.  In the next few posts I hope to talk a little bit more about the network side of things.  Namely, how we get the traffic to the WAE and back in a transparent manner.

Tags: