Software Defined WAN: A Well-Made Insulating Tape?

Translator's note: this is a translation of a note by Ivan Pepelnjak (Ivan Pepelnjak) about reality and marketing around SD-WAN. Title of the note “Software-defined WAN: Well-orchestrated duct tape?” comes from the following author’s tweet:

@ecbanks everything can be solved with a right combination of NAT, GRE and PBR;) Duct tapes of networking.

- Ivan Pepelnjak (@ioshints) December 2, 2010

One of the Software Defined Evangelists declared 2015 the Year of SD-WAN, and my podcast feed is full of startups telling about the delights 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 that I saw, as well as the simple and unified architecture of some products.

However, all this hype disguised as a technical discussion disgusts me, 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 an 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 ). Judging by their diagrams, it seems 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 done just that for years, and most of our customers have long since left MPLS / VPN, using such solutions as 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 is described: what we have done in the past are hybrid WANs , and the novelty issoftware-defined , uses a central controller, and therefore may not use a complex set of protocols like IKE, IPsec, GRE, NHRP, NBAR, IP SLA, PBR and routing protocols BGP or OSPF. All this is replaced by some proprietary "secret sauce" - each startup has its own (yes, for sure, this thought immediately calms down).

SD-WAN under the hood

In its simplest form, the SD-WAN (as many startups advertise it) allows you to use two transport WANs to optimally transfer data between endpoints (end-to-end transport).



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

Since you cannot advertise the 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 overlay network. It does n’t 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 set up automatically (similar to what Open vSwitch or VXLAN implementations do).

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

Before you can start using your SD-WAN virtual network, the topology of your network must be collected. Let’s forget about the problem of integrating SD-WAN edge devices with a traditional L2 / L3 network at the site and concentrate on what is happening in the SD-WAN cloud.

When the SD-WAN edge node is turned on, it must 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 get information about the 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 interacting with products from other manufacturers, which we will not see in the SD-WAN world for a long time.

It's fun to listen to people who previously promoted the benefits of multi-vendor networks that talk about the benefits 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 along with the corresponding addresses of the transport network next hops to the SD-WAN edge nodes. I don’t know what can be more similar to the description of the BGP Route Reflector (well, except for the little thing that almost all SD-WAN developers use proprietary mechanisms, but I think this is already clear).

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

Finally, when the quality of links is known, the user traffic to be sorted into classes of applications (ie NBAR ) and handed over to the target node SD-WAN via one of the uplink based on a predetermined policy (though similar to the Policy Based the Routing ?)

Some SD-WAN solutions go beyond simple PBR and implement intelligent download control, packet retransmission, or even direct error correction to most efficiently utilize available bandwidth while maintaining acceptable end-to-end quality. These technologies are nothing new: they have been available for many years in WAN optimization devices (you may remember people who liked to chat about how bad they are).

conclusions

In every SD-WAN solution, all hybrid WAN bikes have to be invented - tunneling, encryption, key exchange, node registration, exchange of routing information, channel quality measurement, application recognition and policy-based packet transmission - no need to talk about any kind of revolution of these decisions ( RFC 1925 , sections 2.11 and 2.5 immediately comes to mind ).

However, there is a fundamental difference between a mishmash of traditional protocols forced into the architecture of hybrid WANs and SD-WANs - SD-WAN product architects have no problems with legacy implementations, should not reuse code that was developed to solve completely different problems, they can Do not use protocols that are not optimal for the task (for example, why would anyone use OSPF in DMVPN if it is obvious that BGP scales much better?). The individual components that they use to invent these bikes are very well-tuned to each other, because they were originally designed for sharing.

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