• United States

It’s time for SD-WAN to grow up

Apr 11, 20185 mins

Some often-missed considerations drawn from hard lessons learned by SD-WAN early adopters.

Credit: istock

2018 has already been hailed as the “Year of SD-WAN” and while the promises of this technology are undoubtedly appealing to most enterprises, it’s equally important to understand its potential shortcomings.

The “Death of the Router” has been largely exaggerated by those trying to market their “silver bullet” solutions that still lack basic routing capabilities. While there’s no doubt that years of technical debt have added some unnecessary functionality to the modern router, it’s worth acknowledging that there are many “table-stakes” features leveraged that need to exist in any SD-WAN solution that is meant to replace those boring routers.

I’d like to highlight some often-missed considerations drawn from hard lessons learned by SD-WAN early adopters. Specific names and details have been left out to protect both the guilty and innocent.

1. Routing support

If you’re looking to quickly down-select SD-WAN vendors, ask your favorite pure-play startup or pivoting vendor about Multicast, IPv6, IGP and full BGP support and you’ll quickly get to your short-list. The harsh reality is that many of the solutions that exist were either built from the ground-up with limited routing capabilities or are products attempting to pivot into the space – such as WAN Optimizers and Link Load-Balancers – that were typically run in an inline mode. I’ve seen new routers sold along with SD-WAN solutions (originally meant to replace those routers) and GRE tunnels leveraged over the SD-WAN overlays to facilitate a missed Multicast requirement.

2. Hardware capabilities

If we’ve learned anything about Quality of Service (QoS), besides it’s often overly complex, we know that QoS features often can quickly become dependent on the underlying hardware. Consider a scenario where your MPLS carrier requires you to accept your circuit on a 1Gig tagged Ethernet sub-interface that must be shaped to 100mb per your contract. One would assume that an SD-WAN appliance, like a router, will allow you to create a sub-interface with the appropriate Ethernet tag and shape on that logical interface, but imagine if that didn’t work because it’s not supported?

Most currently available SD-WAN solutions require Ethernet handoffs from the carrier.  However, many organizations have global and rural locations that only offer legacy connectivity such as T1/E1 or xDSL. While enterprises can leverage a transceiver or router to ingest a non-Ethernet interface, it’s worth understanding different options in this case prior to getting too far down the evaluation and procurement path.

3. Security and SD-WANs

Most of the SD-WAN vendors don’t claim to be in the next-generation firewall (NGFW) business, yet security should be a critical consideration when evaluating SD-WAN. Anytime a device connects directly to the Internet it’s worth ensuring that it’s hardened from a security perspective and stands up to the scrutiny of your InfoSec team. If you’re purchasing a solution from a start-up or pivoting vendor that has no security pedigree be extra careful. I’ve run into some rather immature capabilities on this front and have been surprised by some advanced capabilities by other manufactures that get security (Control Plane DDoS protection, End-to-End Segmentation etc.).

The days of pre-shared keys for VPN authentication are over, yet not surprisingly, some SD-WAN solutions have not yet added support for certificates (Integrated PKI function). This is unacceptable and should be explored as part of the vetting process. If someone breaks into one of your offices and leaves with an SD-WAN appliance you should be able to immediately revoke that device’s network access because PSKs are NOT secure. And we all know it’s rare for an organization to modify them even after networking engineers familiar with settings and security protocols leave the organization.

4. Troubleshooting your SD-WAN deployment

It’s 2 a.m. and your cell is ringing incessantly. You log into that sexy GUI that sold you on your new SD-WAN solution, and it appears there may be a routing issue. Call me old fashioned but the first thing I’m going to do is log into the command line interface (CLI) to check routing tables, adjacencies to the carrier and so forth, but wait who stole my CLI? Yes, there are new shiny SD-WAN solutions that don’t provide or expose CLI access to the end-customer or simply don’t provide the granularity that you’re accustomed. Take the time to understand exactly what troubleshooting tools will be at your disposal when you simply want to be sleeping soundly.

In summary, please take the time to critically assess the strengths and weaknesses of each prospective solution. It’s also imperative to consider current and future business requirements to make an informed purchase decision. Understanding current product limitations and “committed” roadmap capabilities with timelines will help prevent any resume generating events. Try to avoid being enamored by flashy marketing gimmicks and demos that don’t address your requirements, by ensuring you’re setting the table when it comes to required functionality.

Caveat emptor.

Video: How does SD-WAN work?


As Carousel Industries’ senior director of infrastructure solutions, Jason Viera is responsible for driving strategy around the solutions that Carousel ultimately provides for clients around networking, data center, and cloud technologies. He works with clients across multiple verticals to address their challenges with comprehensive end-to-end architectures to meet their business and technical requirements.

Jason has held over 15 certifications from the likes of Cisco, Juniper, Microsoft, and VMware, including two CCIEs in routing/switching and data center. Prior to his tenure at Carousel Industries, Jason served as a technical solutions architect for Cisco Systems and as a principal IT architect in the Fortune 500.

The opinions expressed in this blog are those of Jason Viera and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.