WAAS – Getting traffic to the WAEs

      No Comments on WAAS – Getting traffic to the WAEs

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. 

Leave a Reply

Your email address will not be published.