WAN Transformation is a Go!

We Are About to Rebuild our WAN...Again

If you look back to when I started writing this blog over 3 years ago, I wrote a series of blogs on how we had built our current wide area network: Making BGP Our Core Enterprise Routing Protocol Using BGP to Make Our Internet Access Dynamic Using BGP to Build a Separate Lab Network The vast majority of these routing protocols designs, all based on network design templates, still exist. However, we ran into an interesting problem over the last year. We are out of bandwidth. Despite the network design being solid, the users were just stepping on each other for bandwidth, even with QoS. When we built the new WAN 4 years ago we provided each typical site in the US two 3 Mbps MPLS circuits which were load balanced (international sites were similarly sized). So, 6 Mbps total bandwidth, but individual user sessions were limited to 3 Mbps because of per-session load balancing. At the time, this was appropriate. We had fewer applications, no VoIP, each application used less bandwidth per session, and YouTube and Facebook were just getting started. Unfortunately, several events occurred over the last 4 years to leave us in the bandwidth pickle we are in today. First, we've done pretty well as a company, growing quite well despite the recession. More people equals more WAN bandwidth. Second, Internet content is exploding and users expect access. Third, we have added many applications, video conferencing, and VoIP. Finally, and more importantly, about every 2 years you should go to your carriers and require a price leveling (this should be part of your contract). This keeps your pricing in line with industry competitive standards. Normally, this price reduction is turned into bandwidth upgrades. So, your total spend doesn't change, but you end up with an across-the-board bandwidth upgrade. Too bad our 2-year mark was the fall of 2008. Anyone remember what happened in the fall of 2008? The cost savings from that price leveling was delivered to the bottom line to reduce costs during the recession and the bandwidth upgrade was skipped. This leaves us today with a WAN that hasn't had a bandwidth upgrade in 4 years. We started to notice the cracks about a year ago. Sites started complaining about slow response times or individual users filling the circuits doing large downloads (QoS would protect critical applications, but bulk transfers would step on each other). Then, we started testing WAN acceleration thinking it would be the elixir for the bandwidth problem, only to be dissapointed by the results. The WAN acceleration testing is where we learned that WAN acceleration is good, but needs to be combined with more bandwidth. Given this information, we set out to develop a business case for a complete WAN Transformation. This would not just be a bandwidth upgrade, but include many services - bandwidth, WAN acceleration, upgraded Internet access, SIP Trunking and more. That business case has now been approved and we are about to get started. Next week I'll delve into the business case and the ROI we created for it. After that I'll go over the new technologies and services that constitute the WAN Transformation. It's going to be a fun 12 months.

More >From the Field blog entries:

Cisco Unified Computing System is 75% Networking - Who Knew?

Congress Needs to Step In for Net Neutrality...Really? Seriously?

It's Time to Start Loving Tunnels

Special Cisco Live Contest - Hottest Booth Girl

Best Sign at Cisco Live

Our Cisco Live Certification Gift

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2010 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)