Manage Learn to apply best practices and optimize your operations.

Using a WAN optimizer sounds great, until it doesn't work

When a new WAN optimizer feature was added to the network, it appeared it would improve performance -- but it didn't.

This article can also be found in the Premium Editorial Download: Network Evolution: SD-WAN makes secure networks possible in hybrid WANs:

There I was, all sparkly eyed at the thought of WAN optimization being provided by a new version of code on my...

favorite site-to-site VPN endpoint devices. I'd worked to find a dedicated WAN optimizer in the past, and saw how very expensive magic boxes could make a T1 link "feel" like a T3 through compression and other tricks. When it works, it's simply glorious for the far end.

So, when my security appliances were gifted with a WAN optimizer feature set, I had wild visions of my branch connectivity getting a leg up for things like Active Directory (AD) profile loading, as the domain controllers are hosted at the main network (this was before branch caching was viable). The vendor promised huge perceived gains in server message block and HTTP traffic, and the 1 Tb SATA drives built into the appliances "for future use" would be woken up and turned loose as part of the WAN optimizer, WAN Opt feature set. Oh, sweet cheese, I couldn't wait for my remote users to call up and say, "What did you do to the network? It's smoking fast!"

And call they did; except it wasn't to heap praise on me and the network. Instead, I got an earful of, "It looks like the network's broken. Do you know what's going on? None of our AD machines are working!"

Quick call to tech support follows

I have a message from the WAN trenches: Whatever you're proposing or selling under the heading of 'Exciting Developments in WAN' has to actually work.

As you can imagine, a call to tech support had to be made. The VPN tunnel was still up, and non-optimized traffic was fine. Pretty soon, I opted to end a too-lengthy data-gathering session with the support engineer, and I disabled the new WAN optimizer feature. As if a switch was flipped, all was well again with the problem traffic flows -- except nothing was being optimized at that point. My high-latency WAN connection would stay high latency for a few weeks, until the vendor was ready to try again with new code. That failed as well. As did the next attempt. And the next. Over a year later, after multiple attempts at WAN optimization on this hardware, the vendor threw in the towel and pulled the feature for good.

So, why I am I sharing this fairly gloomy chapter in my WAN history? First of all, it happened rather recently with a vendor that tends to consistently knock it out of the park with the code that runs its networking gear. Secondly, there is a tremendous amount going on with WAN evolution right now. A lot of it rides the rising software-defined networking (SDN) tide, which means it's time for a reality check.

At the recent Networking Field Day 9 event, there was a fair amount of discussion about SDN-WAN and similar shadings. There were also many articles written on how SDN is changing by those who attended. In my own world, I'm getting acclimated to Cisco's newish Intelligent WAN offerings with self-optimizing path selection and other snazzy-sounding features. With commodity Internet prices coming down and the power of 4G edge routing, these are exciting times for affordably connecting remote locations in ways we couldn't dream of just a few years ago. I applaud anyone and everyone in the WAN game who is trying to bring new mojo (whether it's SDN-fueled or not) to caching, compression and auto quality-of-service management. And I love that, one day, thanks to a WAN optimizer, all WAN links might intelligently reroute when packets are dropped.

Simple message: Make sure it works

In the meantime, I have a message from the WAN trenches: Whatever you're proposing or selling under the heading of "Exciting Developments in WAN" has to actually work. The WAN itself has to work --consistently and reliably, as it always has. It's that simple. Beyond that, all the exciting stuff, with the WAN optimizer, is just gravy. Far-flung users at the end of WAN links are people, too. They are real workers doing real work, and there just isn't room for half-baked solutions and crowd-sourced beta testing by customers who didn't know they were being drafted into the quality assurance testing role. I've been on the losing end of a new WAN optimizer feature set that didn't live up to its hype despite the promises of a trusted vendor, and I suffered for it. Though I'm good at damage control and seeing stuff for what it is when it comes knocking, I still took bruises to my professional reputation and my organization looked foolish for a bit. Worse, my clients were impacted, and that just can't be tolerated.

Evolve away, but do so responsibly. And please, don't bring your WAN Big Idea to market until its ready.

Next Steps

VPN's role in enterprise wireless

SSL VPN products for enterprises

Understanding WAN optimization vs. acceleration

This was last published in January 2016

Dig Deeper on IP Networking

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What advice would you give vendors developing WAN optimizer technology?
Cancel

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close