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.
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.
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.
This article is published as part of the IDG Contributor Network. Want to Join?