Software-defined WANs (SD-WANs) are quickly gaining popularity, in no small part because vendors are applying them to a bunch of diverse missions -- so diverse, in fact, that users often complain they don't understand the offerings at all. To help cut through the market muck and evaluate your SD-WAN options, here are six questions you can ask your prospective suppliers.
The first question is obvious but often missed: What is the relationship between the SD-WAN and carrier WAN services? SD-WANs could be built over one Internet connection or several, could use MPLS VPNs as an option or not, and might expect other network features to be offered through your network connection. The SD-WAN market is in a state of transition, with some products designed for direct deployment by users and others for cooperative use within a carrier network. If you aren't careful with the network-to-SD-WAN relationship, you could end up with something that just won't work at all.
The second question is a bit more complicated: What is the information connection among the SD-WAN devices themselves? Generally, SD-WAN devices will build a private IP network on top of a set of "tunnels" or virtual wires that pass through one or more WAN services to connect all the SD-WAN devices. The connection mechanism can vary considerably -- for example, offering more or less additional overhead. If you want to manage the SD-WAN pipes using your current device or service management tools, you may want to be sure you're able to get statistics from some source on those connections.
Question three is an important one: What connectivity features does the product offer, and how are they controlled? Obviously, an SD-WAN product has to be able to route packets from each device to the correct destination device. That means a routing table, and how that table is built can be important. Is it adaptive, as it would be with routers, or do you configure specific addresses and destinations? How does it accommodate new subnets or users? Can you use the routing table to control who is allowed to connect with certain servers?
This is the area where you can expect the greatest variation in implementation, so you're going to want to spend some time on this one. If the vendor supports "discovery" or adaptive routing, you'll need to know what routing protocols it expects to use at the port connection in each of your locations. If you have to set up the routing table, you'll need to gauge how complicated it will be to do that in each of your sites, and that means finding out the number of subnets and how dynamic they are.
Question four is: What features does the SD-WAN device provide beyond basic connectivity? Some devices will offer encryption, firewall security, etc. Network professionals are divided in whether these features are helpful in SD-WAN applications; many already provide the capabilities through separate devices and don't want to displace their investments. If you don't need added features, you may pay more than you should -- not only in product price but in ongoing device management.
Pay particular attention to application acceleration and prioritization features. All devices can be loaded with more input than they can forward as output, resulting in queuing. Application acceleration can compress traffic to increase effective capacity. Prioritization features can let critical traffic jump ahead on that queue, reducing delay and improving performance. In addition, where SD-WAN devices offer multiple network connections (two ISPs, ISP plus VPN, etc.) routing traffic to one or the other based on priority may also be possible.
The fifth question is: How does your SD-WAN product detect congestion or failure, and what can it do about it? SD-WANs run on top of other services in some way. If the underlying services have a problem, mitigating it in various ways, depending on just what the underlying services are, is theoretically possible. For example, if an SD-WAN supports both MPLS VPNs and Internet transport, a VPN failure could result in a switch to the Internet. But how does the SD-WAN detect the failure?
IP networks generally react to failures at the TCP level, where the detection of missing or out-of-order packets and "time-outs" occurs. TCP doesn't usually run inside an SD-WAN box; it runs in the applications themselves. Those applications could be anywhere in the facility, and number in the thousands. Given that, would the SD-WAN device even detect a failure? If it does, could it switch over to another connection without creating problems with some applications? If your SD-WAN has no practical way of recovering from problems, why pay for the features?
The final question is: Does the product have a software-instance form linkable to a cloud component? Even if you're not a cloud user today, you're likely to have some cloud applications in the near future. SD-WANs that depend on physical devices are difficult to use with public cloud services, but a software-hosted version could link into cloud machine images. Be sure to check with what cloud/container services the product will work.
SD-WAN may become the transformative technology of this decade because it focuses on services rather than infrastructure. But that truth means it may also become the most-hyped technology. Ask questions and get your plans aligned with reality, or you'll risk the stability and security of your network.
Follow Tom Nolle on Google+!
Tom Nolle on Google+
