SD-WAN and its challenges

The Future of WAN?

The enterprise workplace as we know it has evolved dramatically. And we all feel it. People do not go to the same office every day. Some days they don’t even go to the workplace at all. They work from home. The coffeeshop. And even the train when traveling to a customer. And this creates network safety challenges.

Companies are more spread around the country and even around the world in some cases.

As a result, the need for flexible but secure networking has also evolved from a local-concentrated networking to WAN or rather “extended LAN” situation.

Technologies such as VPN and MPLS have filled that gap for a big part, one being more secure and costly than the other. However, configuration isn’t what you would call “easy and flexible”, not to mention the overhead costs for Telco’s to keep it monitored and managed.

A new star on the horizon

With the arrival of cloud, the buzzword for someone else’s computer, came also a whole new workbench of management ecosystems. Deploying all these workloads on the same set of computers came with challenges such as security, routing, availability, etc.

This was partially addressed by de-coupling the functionality of a device (software) and the appliance itself (hardware).

We started distributing the workload on a set of “hypervised” servers, rather than running the operating system on a physical machine. The “virtual machines” were running on a cluster of machines which in their turn were running software like ESXi, Xen,  Hyper-V as a middleware for host-to-virtual communication and management.

The same technology was brought to networking infrastructure with SDN (Software Defined Networking). With software like OpenDaylight, NSX, Onap,… We’ve given networks the ability to be more flexible, “one-touch”  provisioned. And rather than functioning on their own, we now have given the network a possibility to communicate with the actual computers within the network. All this on a management level, providing a very important effort toward “single pane of glass management”.1-Providing Network Management from a central point of view, giving overview of the complete topology with monitoring and fault tolerance.

In this scenario, the network is split into two main parts:

  • The controller and controller network that orchestrates the network instances; and their traffic
  • The actual network traffic containing the payloads to deliver to the different hosts.

SDN on its own however is not suited for communication on an internetworking level.

As a result, SD-WAN was introduced built on the foundations of SDN-technology. A Gartner report in 2018 predicts that more than 90% of all “Edge WAN” infrastructure will be SD-WAN and it will over time completely replace the classic solutions that we are still widely using today.

I’m sorry, SD-What?

I hear ya, it’s all a bit unclear where this is going. From an MSP point of view, that was exactly what we were thinking.

On one end you’ve got our marketing friends building a story around a technology that will save every problem we’re facing from a WAN perspective. On the other end there’s the customer. In the end the finance dept. has to pay for it, and they want to know what the gain is.

If we want to know what SD-WAN is, I think the most important step is to learn how to describe it as accurately as possible.

According to Gartner again, SD-WAN is to be defined with at least four key-elements:

  • Providing the ability to connect multiple technologies into one WAN uplink (e.g. DSL, LTE, MPLS,…);
  • The ability to select an uplink path dynamically depending on pre-defined rules and shapes;
  • A simple, “single pane of glass” management interface with easy provisioning;
  • Providing a tunneling interface for site-to-site or multisite (mesh) private networking.

As you can see, the good thing about this technology is that indeed it does tackle a few of the key pitfalls of WAN internetworking.

We have an easy to manage solution that gives us a VPN alternative using multiple links and we can do some QoS and traffic shaping on it. Where do I sign, right?

In practice: 2 short case studies

In one case I really enjoyed using SD-WAN technology rather than classical IPSec VPN, was for an IoT customer that has mobile appliances that use both LTE and classic broadband uplink to provide access to the corporate network. I’m not saying it’s impossible to configure this using classical VPN infrastructure. You can use a dial-up model and go for a concentrated hub-approach, but you still need to put quite a lot of work into configuring this and to  keep the tunnel safe.

The customer is now using SD-WAN from Cisco Meraki and does 90% of operational management by internal staff. As the Edge appliance migrates from one network to the other, it communicates with the Meraki-cloud updating its location, IP-address, preferred outbound route, etc.. The link is completely automated and will failover in case one of both uplinks fail. So in the end, communication is redundant and secure and the access can be configured from a single management interface. A slightly higher TCO does in this case result in much lower operating costs and high availability, making the choice pretty straightforward.

In another case, however, we needed multiple video-links from a single location at high bandwidth and  low latency. SD-WAN was a possible approach but the TCO went through the roof due to limited availability of carriers and needed throughput. While we were doing our research, we’ve realized that we were just a lot cheaper working with a dark fiber configuration (point-to-point fiber link) and using point to point L2-bridging. But this was in the same city and carrier availability for dark fiber was good.

In short

To conclude, SD-WAN is a great technology enabling quite a lot of flexibility on different setups, mainly when building point to point multi-site network virtualization, by abstracting the physical from the software layer. But it’s not a complete replacement for MPLS. Some situations, depending on telco availability, redundancy needs, etc. will still benefit from MPLS. The best approach, as for me, is a case by case one. It’s a great buzz, but not a fix for all.

Please let me know your thoughts!

Leave a Reply

Your email address will not be published. Required fields are marked *