SD-WANs: The Bad and Uglyby Sorell Slaymaker in Telecom
Software Defined WANs (SD-WANs) are getting a lot of good press and the Gartner 2016 Networking Hype Cycle puts them at the peak of expectations, before sliding down into the trough of disillusionment. Here are 13 things to be aware of when building an SD-WAN strategy and selecting an SD-WAN vendor.
- 25-50% “bandwidth tax!” – versus T1 MPLS. MPLS adds 4 bytes of overhead as a tag to separate various IP networks that run over it. When moving to a 10M Ethernet access and IPsec tunnel over an Internet connection, this will add 78-93bytes per packet. If the average packet size is 160 bytes, this overhead is significant. This overhead can add to large packet fragmentation which will break many applications.
The overhead is even greater when SD-WAN vendors add additional overhead from additional tunnels such as GRE or VxLAN. 128 Technology is the only vendor that does not use tunnels and does not add overhead to every packet unless encryption is required, since they are session aware and maintain session state in their router.
- Lack of Scalability – SD-WANs use tunnels, whether IPsec based or a proprietary schema. Tunnels take router resources for managing tunnel state, plus the encryption. To provide a full mesh of tunnels to all sites on a large WAN requires N*(N-1) connections. For site to site connectivity, most SD-WAN players will backhaul traffic to a data center and avoid the mesh. Also, every tenant, which is a local LAN segmentation, requires its own tunnel such as guest WiFi, voice, and credit card traffic. A 100 site WAN with 3 WAN links per site (MPLS, Internet, LTE) and 8 tenants per site will require close to half million tunnels in a full mesh.
- New Hardware Required – IPsec and other tunneling encryption protocols require significantly more CPU than existing routers can provide. SD-WAN migrations require a new hardware platform, whether it is a fixed appliance or a virtual server at the branch office. Cisco ERS, which is their software based router that runs on Linux takes an approximately 10x hit in throughput performance when 256bit encryption is turned on.
- Poor ROI for Large Sites – Broadband Internet access is the primary driver of savings. But, broadband speeds top out around 50/5Mbps. Large sites that require 100Mbps and greater speeds, still need to buy dedicated Ethernet access, regardless if using MPLS, VPLS, or Internet. The premium of MPLS over VPLS and Internet is only 10-20% until one gets to speeds of 1Gbps or higher. Network transport access represents 60% of the cost of most WANs.
- Stateless Failover – If one of the SD-WAN routers fail, the backup router has to recreate the tunnels, which if they are using PKI for key management can take up to 30 seconds to create. New sessions will run over the backup link, but existing TCP & UDP sessions will drop. This was a problem with some SBCs in the early days with voice sessions.
- No Out of Band Management – A lot of SD-WAN solutions run on virtual machines and do not have the interface or ability to support remote access if the WAN links are down. This has a big impact on the mean time to repair. A few vendors are starting to support OoB management through a USB port off the virtual platform or within the appliance.
- Lack of Dynamic QoS – As more applications move to the cloud and hide behind the cloud providers firewall which provides network address translation, most of the traffic in terms of IP addresses, port numbers, and DSCP QoS markings looks the same, such as Web conferencing traffic. The ability to intelligently and dynamically manage similar sessions when network congestion occurs is lacking along with rate limiting large flows.
- 60-80ms of Additional Latency – Most SD-WAN vendors have Forward Error Correction (FEC) via packet duplication, which they run across multiple network links. In order to provide FEC and to adjust for packet fragmentation, they add a buffer to synchronize the packets, which adds delay.
- Inefficient Double Encryption – Many applications such as virtual desktops, are encrypted at the application layer using TLS, and do not need to be encrypted a second time at the network layer which just adds additional network overhead and router CPU utilization
- Minimal Granular Analytics – While the SD-WAN vendors can monitor and report on the latency, dropped packets, and jitter per flow, but most cannot get more granular and report on number of TCP retransmits nor the mean opinion score based on codec type.
- No LTE Support – While some SD-WAN vendors support LTE, they treat the LTE link the same way as an MPLS or Internet link. LTE networks have a lot more delay, dropped packets, and lower throughput than the other links, so the buffer size, QoS, and dynamic management must be different. Also, the rules on when to failover and to failback are lacking in most solutions.
- Zero Layer 5-7 Security – While many SD-WANs come with basic firewall capabilities, they rely on partners for layer 5-7 security for features such as a web proxy to control and log what sites users go to.
- No Legacy Interface Support – SD-WANs support copper Ethernet connectivity, but do not have the ability to support legacy copper (T1 & DS-3) nor fiber (OC-X & Ethernet) interfaces. Many enterprises continue to retain one of their MPLS links at the branch office which is usually delivered on copper today.
Per my post last week, SD-WAN vendors are still putting together a vCPE eco-system whereas they can provide a complete set of networking and security services in the branch office. In many cases the hardware required for an SD-WAN solution costs more than the software, esp. if an enterprise goes down the SD-WAN appliance model.
So while SD-WANs can offer cost savings to small branch offices, centralized control, minimal touch deployment, and greater agility and security, the immaturity of the solutions on the market pose significant challenges. My recommendation is to evaluate SD-WAN vendors to augment an existing WAN today, and then over time, they may even replace legacy routers. Going out and replacing all the existing WAN routers with Cisco ISRs in an enterprise is very expensive and can be avoided with competitive SD-WAN offerings.