TAGS: | | | |

SD-WAN Gives Us The Best Path We Always Wanted

Ethan Banks

This article was originally posted on June 15, 2015 on my retired personal blog. It’s been cleaned up a little, augmented with parting thoughts from the present day, and re-printed here for a friend that requested it.

In networking, we rely on routing protocols to compute best path. That is to ask, from the perspective of a given router in a routing domain, what is the best way to reach a destination? Best path is typically computed using simplistic metrics like hop count, cost, bandwidth, and delay. Given several paths to get to the destination, the best path is chosen based on the most desirable metric computed along those several paths.

Traditional “best path” thinking is effective, insofar as it goes. It scales to a large number of devices and destinations. It is resilient. It is mature. However, the best path approach has its limitations.

  1. Routing protocols compute the best path for a given destination, not a given application.
  2. Best path computations are not influenced by real-time events such as lossy links or link congestion.
  3. In general, lower bandwidth links are not used to carry traffic (i.e. are not computed as the best path and are therefore unused), EIGRP’s variance feature being a notable exception.

Now, routing protocols can be influenced by outside forces, such as IP SLA. Complex routing policies can be built with BGP. Engineers can create custom routing policies or build traffic engineered paths that flout best path calculations. I recognize that. But, generally speaking, routing protocols were not built to route application flows. They were built to route individual packets.

Software defined WAN brings more sophisticated metrics to the computation of best path.

  1. Best path is computed on a per-application basis, not per-destination. The best path for a bulk traffic application might be different from the best path for a voice application, even if heading to the same destination.
  2. Real-time link capabilities can be factored into the decision.
  3. Any link, no matter the available bandwidth compared to other links, can be used in an active/active manner.
  4. In the original blog, I closed here, inviting folks to attend an SD-WAN related webinar I was co-hosting.

    Parting Thoughts From 2024

    SD-WAN has proven to be one of SDN’s killer apps, perhaps even the killer app. The SD-WAN market was exploding around the time I originally wrote this piece.

    Several SD-WAN startups have been acquired by various larger IT providers, nearly all of these products living on in their new homes. 128T went to Juniper Networks. Silver Peak went to HPE. Viptela went to Cisco. Velocloud went to VMware (which has since gone to Broadcom). Cloudgenix went to Palo Alto Networks. Talari went to Oracle. Ipanema went to Extreme. Masergy went to Comcast. There were others.

    Why such a flurry of activity in the SD-WAN merger and acquisition space over the last decade? SD-WAN’s core value proposition helped organizations make the most of their WANs while saving money. How? SD-WAN brought a degree of trust to the Internet-as-WAN that it did not enjoy previously. Many companies that relied on their service providers to create a private MPLS-based WAN discovered they could create their own WAN with similar quality of experience & greater bandwidth at a substantial cost savings. As the service providers were slow to react to SD-WAN technology, SD-WAN vendors found themselves with a technology that sold itself.

    As the years have worn on, SD-WAN has iterated. Security services are often bundled with SD-WAN, falling under the technology categories of SASE and SSE. Public cloud services and the rise of zero trust have also helped shape SD-WAN’s evolution, spawning cloud-based inspection services, ZTNA, and multi-cloud networking.

    Will there be even more impact on networking to come? Assuredly. The overlay model we now take for granted with SD-WAN finds itself almost everywhere now, invading campus LANs and data centers. The next step is stitching these various fabrics together into a cohesive network. Much work has been done in this area across many products companies use today, and I anticipate more will come to improve the experience for network operators and users.

    From where I sit, SD-WAN changed not only the face of wide area networking, but of networking as a whole.

    About Ethan Banks: Hey, I'm Ethan, co-founder of Packet Pushers. I spent 20+ years as a sysadmin, network engineer, security dude, and certification hoarder. I've cut myself on cage nuts. I've gotten the call at 2am to fix the busted blinky thing. I've sat on a milk crate configuring the new shiny, a perf tile blowing frost up my backside. These days, I research new enterprise tech & talk to the people who are making or using it for your education & amusement. Hear me on the Heavy Networking podcast.

Leave a Comment

window.addEventListener("DOMContentLoaded", function() { var preElements = document.getElementsByTagName("pre"); if (preElements && preElements.length > 0) { for (var i = 0; i < preElements.length; i++) { var preElement = preElements[i]; var spanElement = document.createElement("span"); spanElement.classList.add("copy-container"); var buttonElement = document.createElement("button"); buttonElement.textContent = "Copy Snippet"; buttonElement.classList.add("copy-button"); buttonElement.addEventListener("click", createCopyTextHandler(preElement)); spanElement.appendChild(preElement.cloneNode(true)); spanElement.appendChild(buttonElement); preElement.parentNode.replaceChild(spanElement, preElement); } } }); function createCopyTextHandler(element) { return function() { var text = element.textContent; var tempInput = document.createElement("textarea"); tempInput.style = "position: absolute; left: -1000px; top: -1000px"; tempInput.value = text; document.body.appendChild(tempInput); tempInput.select(); document.execCommand("copy"); document.body.removeChild(tempInput); }; } */ ?>