Ethan Banks raised some thought provoking questions around SD-WAN on his blog. Here’s our response to those questions.
1) What’s the impact to hosts on virtual machine based endpoints, i.e. how much CPU does an SD-WAN VM eat for solutions that use VMs? Not a simple question to answer anymore, as there’s usually cryptography involved.
Silver Peak virtual appliances, like most modern virtual appliances, take advantage of the embedded AES-NI instruction set that modern x86 CPUs have to offer. As a result, there is no appreciable impact on resource consumption or WAN performance when performing IPsec encryption for the secure overlay.
2) How much latency does the SD-WAN controller introduce, and under what circumstances?
The Silver Peak SD-WAN controller sits outside of the data path and, as such, does not impact the performance of the SD-WAN fabric.
3) When WAN-based SD-WAN tunnel endpoints are inevitably separated from the controller due to a network fault, what happens?
With Silver Peak, the data plane will continue to function normally when there’s a failure to the control plane. Policies cannot be added or modified while the controller is isolated form the SD-WAN fabric, however there would be no interruption in service and existing policies will continue to be enforced.
4) How does the SD-WAN infrastructure track tunnel availability, and how quickly does the controller react when a tunnel is down?
Silver Peak sends control packets across its SD-WAN tunnels performing advanced measurements for packet loss, out-of-order packets, latency and availability. The advanced, per-packet measurements provide the ability to avoid application outages, including handling brownout conditions where the line may be active, but underperforming because of network conditions.
5) What happens to in-flight traffic when a tunnel dies? (Every financial services organization is going to ask that question.)
Silver Peak provides seamless failover for TCP connections including traffic-in-flight.
6) How does the SD-WAN solution get traffic into the system? As in, routers attract traffic by being default gateways or being in the best path for a remote destination. SD-WAN tunnel endpoints need to attract traffic somehow, just like a WAN optimizer would. How is it done? WCCP? PBR? Static routing? (All 3 of those are mostly awful if you think about them for about 2.5 seconds.) Or do the SD-WAN endpoints interact with the underlay routing system with BGP or OSPF and advertise low cost routes across tunnels? Or are they placed inline? Or is some other method used?
We support a broad range of configurations for moving traffic into our SD-WAN. These approaches include inline, WCCP, PBR, and default next hop.
7) What about traffic I don’t want to go through the overlay fabric? How do I exempt it?
A simple policy will exempt traffic from the SD-WAN. Traffic can be identified by a variety of means including IP address, application, VLAN tag, and port.
8) Double-encryption is often a bad thing for application performance. Can certain traffic flows be exempted from encryption? As in, encrypted application traffic is tunneled across the overlay fabric, but not encrypted a second time by the tunnel?
Any traffic, including pre-encrypted traffic, can be exempted from the SD-WAN by defining a simple policy. That said, given the inconsequential CPU overhead associated with encryption on a modern CPU (see Q1), most customers would choose to keep things simple and not worry about avoiding double encryption.
9) Is the encapsulation type standard or proprietary? If it’s proprietary, convince me I don’t care.
Silver Peak builds its SD-WAN fabric with standard protocols, including GRE and IPsec with AES-256 bit encryption.
10) Assuming unique keys per tunnel (and I’d hate to imagine a single key per tunnel fabric), how are these keys managed and by whom?
Each tunnel in the Silver Peak SD-WAN fabric has a unique key and those keys are managed by GMS, the Silver Peak SD-WAN controller.
11) Is path symmetry important when traversing an SD-WAN infrastructure? Why or why not? Depending on how the controller handles flow state and reflects it to various endpoints in the tunnel overlay fabric, this could be an interesting answer.
Path symmetry is not required for Silver Peak’s SD-WAN. We perform equally well across symmetric and asymmetric paths.
12) Selectively forcing certain flows to traverse firewalls or other security devices is part of the SD-WAN unicorn. How, exactly, does this happen, and what are the network underlay dependencies required to bring it about? Ergo, SD-WAN service chaining differs from service chaining through a hypervisor-based vSwitch where a controller can direct the traffic inside of a nice, tidy ecosystem wherever it wants. SD-WAN service chaining has to work on traditional IP fabrics that have no inherent notion of service chaining, and all you’ve got to work with are overlay tunnel endpoints.
This is an interesting question. We expect that SD-WAN solutions will be able to hand-off traffic at an aggregation point, such as a regional hub, according to a specified policy. For instance some traffic may be forwarded to a firewall or some other security function. However, it’s not clear that it is a good thing if this functionality metastasizes into full blown service chaining. There are multiple open and proprietary service chaining architectures for a software defined data-center, and it seems more important that a SD-WAN solution fits well into these open architectures, versus reinventing this capability and artificially tying it to a WAN traffic aggregation architecture.
13) Just how granularly can I identify applications, considering progressively more applications are encrypted as they traverse the wire?
As more applications are encrypted with SSL traditional forms of deep packet inspection (DPI) are no longer effective. Silver Peak is pioneering a new means of identifying applications without DPI.
Great questions, Ethan. In a future blog post, we will look at a few more questions that might also be asked.