Many of us have now realized that more bandwidth doesn't necessarily mean faster applications. Add that to the fact that bandwidth doesn't come for free and suddenly we're talking about way to optimize our networks...

There are many, many ways tweak our networks for better application performance. As a matter of fact, I think I'll write a more detailed blog post on that next week as it's a cool topic and one that is near and dear to my heart. That said, one of the ways that many people are now accelerating applications on the WAN is to implement WAN optimzation appliances. The two that I'm most familiar with are Riverbed's Steelhead appliances and Cisco's WaaS devices. IMO you can't go wrong with either one. It's great technology and there's a lot of headroom for technical advancement over the next few years.

Once you've decided to evaluate and/or implement a WAN optimization device the next question is usually "How do I monitor it?" or "How do I measure it's effectiveness?". Both are great questions and fortunately the answers are fairly straight forward if you understand how WAN optimization technology works.

I won't go into a lot of detail because you can find some great tutorials on WAN optimzation on both the Cisco and Riverbed websites. In a nutshell, you put a pair of these puppies inline between the user and the application server (one at each end). When the conversation (TCP conversation I mean) reaches the first appliance it's broken down and restructured and the appliance makes decisions on where to get the data (most of them do some caching), in what order to send/request data, and via how many round trips. Then, the WAN optimizer at the other end reconstructs the conversation and sends it on it's way. The whole thing is transparent to the user and the application server.

When it comes to monitoring these devices you of course want to be able to monitor the appliance's health (up/down, CPU load, memory, etc) but most importantly you want to be able to monitor the traffic going through the applicance and the devices effectiveness at optimizing traffc. Each system offers both an element manager and a web inteface for the device itself where you can get a lot of this data. If you only have a pair or two of these devices and assuming you don't have a need for historical data collection for trending then the built-in management interface may be enough for you.

Monitoring these devices in the enterprise offers additional requirements as you'll most likely want to be able to manage them within your NMS and you'll need to be able to setup alerting, reporting, trend analysis, and etc. The device health data is available via SNMP and so assuming that your NMS either a) monitors them out of the box or b) has a flexible polling engine that can be easily extended to monitor them you should be good to do. Here at SolarWinds we offer Orion NPM which both monitors these devices out of the box and offers an easy way to extend that monitoring through it's Universal Device Poller (UnDP).

To monitor the traffic going through the applicance most people turn to NetFlow. In the case of the Steelhead devices, they themselves support NetFlow and it's likely that the network devices adjacent to them will as well so you can get some great data on the network traffic. Keep in mind that because the application conversations are quite literally terminated, restructured, and then reformed on the other end that in many cases the TCP port numbers will change which makes analyzing this traffic with NetFlow impossible. Riverbed recently added a feature called "Port Transparency" which solves this problem. So, if you're planning to analyze the traffic using NetFlow you'll want to enable that.

Some network management systems, like Orion NPM, also include some built-in reports specifically geared toward managing WAN optimization devices.

Ping me back if you'd like more information on this subject or if you have any cool stories to share wrt your implementation of this technology.

Flame on...
Follow me on Twitter