This blog is brought to you by VeloCloud, now part of VMware’s partner Matrix Networks. Original blog is posted here.
IT administrators can generally always agree on one thing: dealing with carriers for their multi-site connectivity sucks! This connectivity normally comes in the form of a MPLS Private IP cloud, EPL, EVPL, VPLS, etc…. At this point in time it feels like so many carriers just make up new acronyms to try and make their service sound flashier. The industry consensus is that ordering new circuits takes forever and submitting trouble tickets is pretty much a “hurry up and wait” game. To receive SLA credits is near impossible, requiring you to use their own systems to prove they are incompetent. These are just the normal complaints about interacting with the carriers, when you start talking about how much money you send them every month…wow…just wow.
Why have we put up with this?
The decision to go with these “private” circuits generally is based on the need for QoS. It’s hard to find a company anymore that doesn’t run VoIP across their network, and we can all agree that QoS is vital for good call quality. Beyond just VoIP, there are plenty of other applications that most system administrators want to prioritize. QoS is primarily needed for congested links, but when you only have 5mb or 10mb links to your remote offices – they are more congested than an artery after an Arby’s binge! Another decision to go with these circuits is having “one throat to choke.”
If you have an issue anywhere in the network, you just contact one company. But when you are “choking” them pretty much 24×7, does that really have value? Another reason organizations chose to go with services like MPLS, is the carrier is maintaining the edge routers. Depending on the abilities of your IT admins, I can see this being valid, but with my personal experience in the area – when I submit a change request to the carrier and it takes 3 weeks to be implemented, I see no value there either. Frankly, for how much you are paying the carrier to provide/maintain that router, you can buy one yourself and hire someone to manage it.
This is horrible, but what are the alternatives?
So by now you are thinking – why am I putting up with this? As recently as five years ago, you didn’t have many options. To connect multiple sites your options were going with a private infrastructure with a carrier, or getting Internet connections at all your locations and setting up a VPN infrastructure. As I pointed out in the last section, you really need something prioritizing VoIP and other real-time traffic. When you have that voice inside an IPSEC VPN tunnel – and heaven forbid your locations have different Internet providers and are traversing the “public” Internet, you’re gonna have a bad time. Beyond just the issue of VoIP, most private MPLS style circuits are multipath up to the last mile. So if there is an issue “up stream,” you generally can be routed around it.
With your “commodity” Internet connections, most of the time you don’t even have that little bit of redundancy built in. To combat this issue your best option is to normally plug in two circuits into your firewall, now you have redundancy!! Well you do in the most technical use of the word. Generally you are now in an active/passive situation, or your firewall is doing some lame “load balancing.” In either situation firewalls are pretty poor at detecting when a circuit actually fails. We often see circuits that are still up, but have some type of minor packet loss, high latency, or high jitter.
At this point the service sucks for any real-time applications, but the firewall still sees the circuit up! When a circuit does fail, and the firewall finally gets that memo, it does send all the traffic over the other circuit. But I hope you didn’t have any sessions on the failed circuit you cared about – as they are all down now! That VoIP call with the CEO? Dropped. That video conference between the managers at multiple locations? Dropped. That cat video the intern was watching? Dropped. So again, VPN with a single or even multiple Internet circuits still isn’t ideal.
OK so everything we have sucks, now what?
Now that I have rained on your parade (as I know you are using one of these methods to connect your locations), what option do you have? SD-WAN to the rescue! SD-Wha?? First I really don’t care for the term SD-WAN, it’s just as nebulous as “The Cloud.” But what started as “SDN” (Software Defined Networking) has morphed into SD-WAN. At this point we are just stuck with the term…. To me it means: Intelligently routing traffic over the best path. That’s it. You would think this would have been a thing already, but it really hasn’t really come to market until the last few years. I think there are multiple reasons for this, but that’s another blog post.
For the terms of this discussion, SD-WAN gives us that missing piece of how to make VPN connections something we can really consider for all of our real-time applications inside an IPSEC tunnel. Sounds too good to be true, huh? So the whole idea is you take those two circuits out of your firewall (which sucks at actually using both connections well), and plug them into a magic SD-WAN box. From here, there are many solutions on the market, some require that box to be your router – others let the box sit in front of your firewall. Regardless of how the solution is implemented they all more or less measure the quality of the circuits you plug into the box, and intelligently route the traffic over the best circuit. So when the box sees a VoIP packet, it is going to route it over the circuit with the least latency, jitter, and packet loss. Big windows updates – good chance those will be routed over the circuit with the most bandwidth, regardless of latency and jitter. There is also a certain amount of abstraction here too – so if a circuit does fail, it seamlessly moves your traffic to the other circuit(s). If the CEO is on a call that is being routed over a circuit that fails, the call moves to the other circuit and your CEO has no idea you just had a circuit die. Awesome!
VPN + SDWAN = WINNING!
With the advent of SD-WAN, VPN connections are looking more appealing than ever. You really get the best of both worlds, high bandwidth and lower cost connections, while maintaining that valuable QoS style protection for your real time applications. Carrier provided networks are expensive, the support generally sucks, and they aren’t flexible when it comes to new technology. It is finally time to break away from the carrier and gain some new independence with an older technology and a new one; VPN and SD-WAN.
IT administrators can generally always agree on one thing: dealing with carriers for their multi-site connectivity sucks! This connectivity normally comes in the form of a MPLS Private IP cloud, EPL, EVPL, VPLS, etc…. At this point in time it feels like so many carriers just make up new acronyms to try and make their service sound flashier. The industry consensus is that ordering new circuits takes forever and submitting trouble tickets is pretty much a “hurry up and wait” game. To receive SLA credits is near impossible, requiring you to use their own systems to prove they are incompetent. These are just the normal complaints about interacting with the carriers, when you start talking about how much money you send them every month…wow…just wow.
