SD-WAN Short Comings Are Significant

We are starting to see SDWAN deployments within our customer base. As pointed out in our list of vendors supporting SD-WAN, about eight of the manufacturers listed export NetFlow or IPFIX but, none of them to date export the details that allow customers to verify that they are really getting what they paid for.

“Gartner predicted that by the end of 2019 30% of enterprises will deploy SD-WAN technology in their branches.”

“IHS predicted that the number will be as high as 45%.”

“IDC has forecast that rapid enterprise adoption will drive market revenue to $6 billion in 2020.”

SD-WANs took many of its ideas from Software Defined Networks which promise to be provide enhancements to the management and optimization of all traffic. Some specific SD-WAN features include:

• Provide load balancing whereby traffic is dynamically moved to other connections with extra available capacity
• Moving “Rerouting” of connections without resetting them
• Compressing the data
• Use the detection of errors such as packet loss, latency, jitter to make decisions on which traffic to a move to a more optimal path
• They provide a single interface at the ‘controller’ for management of the WAN hardware
• Some vendors promise to provide support for different vendor platforms
• Distributed controllers are available to help scale the solution and provide redundancy
• Promise to better optimize the QoS demands of the business applications
• Provide performance details on the overlay traffic going over the SD-WAN

When it comes to monitoring and management, SD-WAN vendors promise to provide:

• Details on traffic priority rules
• Details on mission critical apps
• The ability to set security permissions
• Information on up/down/degraded status
• Detailed metrics on jitter, packet loss, top application details

The above information is insightful however, where all the solutions fall short is on the very last bullet above. The area of verification of connection rerouting. We are finding that it definitely needs some enhancements. Specifically, customers want insight into which flows were rerouted by the SDWAN controller AND why. This is important because administrators often want confirmation that the SD-WAN architecture is:

1. Rerouting specific flows when certain metrics degrade
2. Truly optimizing business application traffic as preferred by the customer

It wouldn’t be hard for these SD-WAN vendors to provide what customers are looking for. For example, the flow rerouting details could come in the form of a separate IPFIX template which would look something like the following:

• ID of the flow that was rerouted. This links the entry to the flow that was impacted by this event.
• The name of the metric that triggered the reroute (E.g. latency, packet loss, jitter, load, retransmits, MOS Score etc.)
• The value of the metric that triggered the reroute
• Additional elements as determined by the vendor for competitive differentiation

Without providing good, clear details on the flows that are being rerouted, how can the customer determine:

• Which applications are being rerouted the most, how often and at what volume?
• Are the tweaks that they are making to the architecture having the impact that they desire?
• Are certain physical connections seeing more reroutes than others?

The ability to answer the questions above is the type of insight and verification that allows customers to get the most out of their SD-WAN solution. It allows them to gain confidence that it is working as intended at the flow level.

The official IANA standard for all flow technologies is IPFIX which defines elements that are similar to what we need. For example, forwardingStatus(89), flowEndReason(136), firewallEvent(233) are all elements that try to clarify why something occurred to the flow. Although they don’t exactly address the SD-WAN short comings, they are examples of how the technology has been used to provide additional insight into traffic issues. SD-WAN customers should reach out to our team if they need help gaining insight into the traffic traversing their SD-WAN.