At first glance, Software Defined Wide Area Networking (SD WAN) sounds like another case of SDNwashing (cf. cloudwashing). Is it just some kind of automated configuration of existing technologies dressed up as a new product?

What Is SD WAN?

Before looking at whether there’s anything of value in SD WAN solutions, it’s important to understand what SD WAN actually means from a product perspective. Unfortunately as with Software Defined Networking (SDN) the definition is fuzzy at best (cloudy, you might say).

ONUG

In an ONUG blog post, SD WAN is defined as any wide-area network that is managed by software control. The author notes that there are two main types of SD WAN, intradomain (i.e. within your own networks) and intradomain (managing routing between independently managed entities, usually via a layer 2 switch).

Gartner

In Gartner’s Technology Overview for SD WAN the authors describe SD WAN as a new and transformational way to architect, deploy and operate corporate WANs, as it provides a dramatically simplified way of deploying and managing remote branch office connectivity in a cost-effective manner.

sdxCentral

News and research site sdxCentral describes SD WAN as a specific application of software-defined networking (SDN) technology applied to WAN connections, which are used to connect enterprise networks – including branch offices and data centers – over large geographic distances. The SD-WAN movement seeks to move more of the network control is moved into the “cloud,” using a software approach.

It’s worth noting that there is also a lack of consensus regarding whether the abbreviation should be written SDWAN, SD-WAN or SD WAN, so my conclusion is that SD WAN simply means something more than your existing wide area network. I’ve suggested elsewhere that we should get rid of the SD part and just call it Clever WAN instead. Whatever we call it and however we define it, it seems that one main use case has become the de facto example of SD WAN in the enterprise space, and that is hybrid WAN.

Hybrid WAN

A hybrid WAN is one that utilizes multiple WAN technologies to provide connectivity to each site. An example of this might be a site that has an leased circuit connecting to the corporate MPLS network, and an SDSL Internet circuit with IPSec VPN tunneling as a backup should the MPLS fail. Other technologies in use may include LTE wireless, cable modems, frame relay and any other circuit that can provide the necessary bandwidth to offer either a parallel path or a backup path to the corporate network. Let’s look at a typical hybrid WAN remote site configuration:

Often, centralized internet access policies mean that there is no split VPN tunneling locally and all traffic must go through the corporate HQ. The Internet link is usually there purely as a backup mechanism in case the leased line fails. In terms of configuration the simplest case would have a static default route via the leased line, then a floating static default route is configured, pointing via the IPsec tunnel. There are a few obvious issues with this solution:

1. The remote site Internet access is not being used for user Internet traffic, which puts unnecessary load on the MPLS network and core systems. Deploying internet access policies to every remote site could be a nightmare from a configuration management perspective.
2. The Internet link sits idle until the leased line fails; this is wasted bandwidth.
3. If the leased line is showing some level packet loss or high latency, traffic will keep on being sent that way. Only a total link failure will trigger an alternate path (and if using dynamic routing protocols rather than static, it’s also possible to detect an indirect connectivity failure as well).

If there were three links to the remote site – maybe a leased line, DSL and an LTE modem – the situation is more complex still, and the LTE would most likely never be used (but you’d feel happy knowing it was there, right?).

Using The Hybrid WAN Effectively

So as a customer, what might I want my hybrid WAN to be able to do? Well, a few things:

1. Use any and all bandwidth available to me so I don’t have circuits sitting idle.
2. Use the local Internet connection for traffic deemed acceptable, but push everything else via the central site.
3. Classify network traffic based on business criticality and network performance requirements, and use the available links to best meet those goals. For example, if my leased line is lower latency, IP Voice traffic should use that link by preference, but if the latencies change the traffic should be moved dynamically to the best available link, and other flows moved around as needed to accommodate the higher priority traffic.
4. Determine which traffic is important enough to consume expensive LTE data when there is contention for the available bandwidth.
5. Monitor packet loss on each link and determine strategies to minimize loss overall (e.g. forward error correction techniques, duplicate packet transmission, or anything else that helps), but only do these when necessary because typically error correction means sending additional data, and I don’t want to waste the bandwidth I have.
6. Optimize my traffic – maybe compress it, for example – so I can make the most of the connectivity I have. This should be done intelligently so that latency sensitive protocols, for example, are not impacted by latency induced by the blind compression of everything on the link.
7. Configure once, use many. Rather than configuring these rules on each of the 50 remote sites, it should be pushed out automatically.
8. Visibility. See what’s eating up bandwidth, make policy changes if needed and see the impact of those changes.
9. One edge device on each site that does all this for me.
10. The moon on a stick.

These are the technical needs, and I think as the reader you can make the logical leap to the potential business benefits of achieving everything on that list, so I won’t dwell on them here. I don’t ask for much, do I? Well, this list – or something close to it – is what Riverbed’s SD WAN solution aims to provide (give or take the lunar requirement). Is It SD WAN by some definition or other? Who cares. It’s more important that the solution provides useful features and benefits than it is to worry about what it’s called.

Riverbed SD WAN

Riverbed is well known for its suite of WAN acceleration products, which are typically deployed inline with WAN traffic flow. However, not every site needs, or can justify, a full WAN acceleration product. For SD WAN to be truly powerful though, it’s important to have one solution that can be deployed at all sites be managed centrally with one set of policies, and to have one source for WAN telemetry (visibility) rather than having to try and aggregate multiple sources into a useful view of the wide area network.

While I don’t have any insight to speak of, I do believe that Riverbed is making the transition from being a provider of inline tools to being a provider of feature-rich edge routing devices, with one of those features being the WAN optimization and acceleration for which Riverbed is already well known. I mentioned Project Tiger in a previous post, and I would propose that this is the opening play for Riverbed in a migration to become an edge device provider.

The initial Project Tiger hardware provides no WAN acceleration but acts as a controllable edge device making intelligent policy-driven routing decisions. This platform, coupled with the capabilities acquired with Ocedo such as an advanced firewall, will provide a solid foundation for a new generation of Riverbed edge products. The product hardware can be scaled to offer functionality appropriate for all sizes of sites, and as SteelOS (the new operating system created for Project Tiger) is developed, it’s an obvious next step (hardware capabilities permitting) to containerize and license the various additional aspects of WAN compression, caching, and optimization currently available in products running RiOS. If the hardware can support optional levels of hardware redundancy that larger sites will be seeking, whether in-chassis or as a cluster, Riverbed’s Project Tiger could become a ubiquitous one-stop edge device with features enabled site by site on an as-needed basis.

Total Control

The need for centralized management and visibility of the wide area network is very real, and Riverbed’s SteelCentral is where this happens. In fact, it’s essential that SteelCentral has total visibility and accurate telemetry data for the WAN because that’s how it’s possible to implement policies across the network and adjust behavior on the fly as needed. While policies can be deployed to each site that are operate autonomously, having broader visibility of network conditions and link behaviors can allow the controller to make even smarter dynamic decisions and communicate those updates to the edge.

Ship To Site

The last pieces to this puzzle are ZTP (Zero Touch Provisioning), and the Ocedo cloud, switch and access point products. I discussed the potential to add the Ocedo-originated wired and wireless LAN into a centrally managed system, and Jordan Martin has discussed how Ocedo’s cloud products can impact the Hybrid Cloud. Now add in ZTP, and deploying a new remote site starts to look very interesting indeed.

While ZTP–the idea that you can ship a device to site, plug it in to an Internet-enabled connection, and have it get a configuration–has become a ubiquitous feature in WAN products over the last few years, Riverbed will be in a rather unique position of being able to ship an edge router, Ethernet switches and WiFi access points to site, have them installed and connected to an Internet link (e.g. a cable modem) and the site could be lit up automatically by SteelCentral from the edge to the user. This is pretty much a site in a box and could make rapid deployment of remote sites incredibly simple. I don’t have details on Riverbed’s technical architecture in this area, but in an deployment with a Riverbed edge router I can see advantages to having the edge router respond to the switches and access points when they are turned up, proxying configuration and identification requests to SteelCentral as necessary, so that the devices have locally available configuration management within the site rather than going out to an public site directly. We’ll have to see what transpires as Ocedo’s products are progressively integrated into the bigger Riverbed picture and we see a unified offering hit the shelves, but the idea of drop shipping products to a site, selecting policies appropriate for the site in SteelCentral, then watching the site bring itself up with a standard managed configuration is very attractive.

It’s All About You

It’s worth considering what you would like to see from your WAN, putting aside the idea of software defined as a feature. I believe Riverbed are moving into a position where their WAN products will meet a broad range of needs on an à la carte basis, and should be high on your list when seeking a solution to your WAN needs.

---