Software-defined WAN: well-made electrical tape?

Translator's Note: This is a translation of a note by Ivan Pepelnyak (Ivan Pepelnjak) about reality and marketing around SD-WAN. The title of the note “Software-defined WAN: Well-orchestrated duct tape?” Comes from the following author tweet:

One of the Software Defined Evangelists announced 2015 as the Year of SD-WAN, and my podcast feed is full of startups telling about the merits of their product compared to the mess of traditional routers. Here you need to think: is SD-WAN really something new, or is it an old song in a new way?

Read the first thing

Do not get this post wrong. I am not against SD-WAN; in fact, I like some of the ideas I've seen, as well as the simple and unified architecture of some products.
')
However, I am sickened by all this hype disguised as a technical discussion, and I think network engineers (as opposed to marketers or managers) should approach SD-WAN like any other technology , try to understand how it really works, what are the real problems and solutions.

What is SD-WAN?

For lack of definition from a serious institution, let's turn to the description from the Open Networking User Group website ( community of users of open networks - approx. Translator ). From their charts, it appears that SD-WAN is something that allows you to use the public Internet in parallel with a private WAN to reduce costs.

Wait, what? We have been doing just that for years, and most of our customers have long gone away from MPLS / VPN, using solutions like IPsec, DMVPN, or even MPLS / VPN-over-GRE-over-IPsec .

Marketing gurus, working for SD-WAN developers, will quickly explain to you that what they do is fundamentally different from what was described: what we did in the past are hybrid WANs , and what's new is software-definable , uses a central controller, and therefore may not use a complex set of protocols like IKE, IPsec, GRE, NHRP, NBAR, IP SLA, PBR, and BGP or OSPF routing protocols. All this is being replaced by a certain proprietary "secret sauce" - with each startup (yes, exactly, this thought calms down immediately).

SD-WAN under the hood

In its simplest form, SD-WAN (as advertised by many startups) allows you to use two transport WANs for optimal data transfer between endpoints (end-to-end transport).



Let's take a look at what needs to be done to make it work.

Since you cannot advertise non-public address ranges used on your sites to transport networks (at least not to the public Internet), each SD-WAN solution builds its own virtual (overlay) network. It does not matter what they use there: GRE, VXLAN, IPsec tunnel mode or other encapsulation technology.

Some customers need direct connectivity between all sites, which requires a fully connected tunnel topology or multi-tunnel technology like DMVPN . Details are not important, and, in most cases, tunnels are established automatically (just like Open vSwitch or VXLAN implementations do).

And you do not want to transfer your internal traffic over the Internet without encryption, right? Each SD-WAN solution should solve the problem of traffic encryption (a hint: there is a standard solution for this, called IPsec ) and a key distribution problem (ie, IKE - in the multi-vendor world).

Before you can start using your SD-WAN virtual network, your network topology needs to be collected. Let us now forget about the problem of integrating SD-WAN edge devices with a traditional L2 / L3 network on the site and focus on what is happening in the SD-WAN cloud.

When the SD-WAN edge node turns on, it should connect to the controller and register its external (WAN) IP address on it. In networks based on standard protocols, NHRP is used for this.

Next, the controller needs to obtain information about local prefixes available at each site. Whether you use a routing protocol , a REST API, or some proprietary protocol for exchanging prefixes does not matter much ... unless you are concerned about interaction with products from other manufacturers, which we will not see for a long time in the SD-WAN world.

It's fun to listen to people who previously promoted the benefits of multi-vendor networks telling about the advantages of poorly documented proprietary solutions "because they are much better than routing protocols."

After collecting information about the prefixes of each site, the controller decides which routes to use and sends the prefixes together with the corresponding transport network next hops gateway addresses to SD-WAN border nodes. I do not know what could be more similar to the description of the work of the BGP Route Reflector (well, except perhaps for the little things that almost all SD-WAN developers use proprietary mechanisms, but I think this is already clear).

In the ideal case, each site is reachable from any other through more than one uplink, from which the best should be chosen. The choice is made by reachability metrics or by more complex measurements - such as such well-known tools as BFD or IP SLA do .

Finally, when link quality is known, user traffic should be sorted by application class (i.e. NBAR ) and transmitted to the target SD-WAN node via one of the uplinks based on a predefined policy (does it look like Policy Based Routing ?)

Some SD-WAN solutions go beyond simple PBR and implement intelligent download management, retransmission of packets, or even forward error correction to make the most efficient use of available bandwidth while maintaining end-to-end acceptable quality. There is nothing new in these technologies: they have been available for many years in WAN optimization devices (you may remember people who liked to chat about how bad they are).

findings

Every SD-WAN solution has to reinvent all hybrid WAN bikes — tunneling, encryption, key exchange, node registration, route information exchange, channel quality measurement, application recognition, and policy-based packet transmission — so there’s no need to talk about any revolutionism of these solutions ( RFC 1925 immediately comes to mind, sections 2.11 and 2.5).

There is, however, a fundamental difference between the mix of traditional protocols that have been forced into the hybrid WAN and SD-WAN architecture — SD-WAN product architects have no problems with legacy implementations, do not need to reuse code that was designed to solve very different tasks Do not use non-optimal protocols (for example, why would anyone use OSPF in DMVPN if it’s obvious that BGP scales much better?). The individual components that they use to invent these bikes are very well matched to each other, because they were originally designed for sharing.

The architecture of most SD-WAN products is much simpler and easier to configure than traditional hybrid networks. However, we should not forget that most of them use proprietary protocols, which leads to the vendor lock-in .