• 07/22/2015
    8:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

SD-WAN: The Killer App For Enterprise SDN?

Software-defined WAN technologies promise to help enterprises modernize their WANs by combining classic WAN technologies with SDN capabilities.

Despite widespread interest in software-defined networking, enterprise adoption of SDN has been slow. With all the attention on software-defined WAN, I wonder if it can be a catalyst for SDN adoption in the enterprise -- in other words, a "killer app."

SD-WAN augments a traditional MPLS network with broadband and other networks plus intelligence from a controller that directs traffic to the appropriate path.  It combines classic WAN technologies with SDN features such as network automation to enforce policies.

The rise of SD-WAN is partially a reaction to the changing enterprise environment: There are more SaaS applications, increased use of network-sensitive apps like voice over IP (VoIP) telephony, and challenges in making the existing infrastructure adapt to these needs. People want a modern WAN work to meet these needs while staying within budget.

Packaging matters

Many elements associated with SD-WAN have been around for many years, such as the ability to combine the public Internet with MPLS or VPN, classify and steer traffic where it is best suited, or to use overlays to tunnel over multiple networks. WAN optimization for compression and caching has been widely deployed for years. Dynamic Multipoint Virtual Private Network (DMVPN)  delivered some of these capabilities, but is a combination of technologies, as opposed to single product or feature.

But SD-WAN isn't just a repackaging of old technologies.  There are some innovations such as central controllers, built-in analytics, network service provisioning and orchestration. The code is freshly written, and parts are cloud-based.  Centralized policy management and security features such as app firewalls, segmentation or key management are often included. Together, these help deliver a modern WAN with SDN capabilities.

With SD-WAN, startups and traditional networking vendors alike have packaged a variety of technologies into an easy-to-deploy solution that reduces the need for extensive configuration by end users, and the result is marketed with a clear ROI.

Packaging matters since makes it simplifies the purchase process. A product from a single vendor is easier to buy compared to a solution comprised of software, hardware devices and professional services from multiple vendors.  Furthermore, a single supported product is easier to deploy and support for the mainstream users’ skill sets since there is a single source of training or documentation. CIOs often state that matching a solution to an organization’s skills set is a key requirement for adopting products.

Startups such as Aryaka, CloudGenix, Pertino, VeloCloud, Viptela and Talari Networks offer SD-WAN products.  Established vendors with WAN products such as Cisco (with iWAN), Citrix, FatPipe, Ipanema (part of InfoVista), Riverbed and Silver Peak Systems also compete in this segment.

WAN modernization obstacles

If you already own traditional WAN building blocks with the right features, it’s possible to redesign it to meet current needs, but you may encounter these obstacles:

  • Systems integration difficulties: Modernizing a WAN requires redesign.  IT management may say, “You have the building blocks, so please just make it work.” However, it’s not always simple to do, or get budget to pay for professional services.
  • Organizational boundaries: WAN technologies may be paid for by both central and remote office IT budgets, and changes require buy-in from many parties.
  • Timing is not right: Some groups be reluctant to fund modernization since they need to wait until network circuit contracts are up for renewal or existing hardware gets refreshed.

An SD-WAN solution makes it easier to overcome the system integration objections since you can point to a single product for WAN modernization   But how does one overcome the timing and organizational objections?

ROI focus

SD-WAN products are sold with a clear emphasis on ROI as opposed to a set of technologies.  From the perspective of CIO, if a product or service saves money or improves service levels, then it makes sense to consider it, regardless of how it matches with the upgrade schedule or where the budget is controlled.

The savings are realized in two main ways. One is to limit the growth of adding MPLS circuits as traffic needs grow by augmenting it with a low-cost public Internet link for carrying low-priority traffic.  It’s also possible to reduce MPLS circuits if they were deployed in excess of the current needs and can be split into a combination of fewer MPLS circuits and broadband links.

When server virtualization took hold in the last decade, there were two ways in which purchases were justified. Server containment, which is to slow down the rate of physical server sprawl, and server consolidation, which is transform existing physical servers into VMs. It was much easier to sell virtualization based on server containment, as opposed to doing physical server conversion. 

The same may apply in SD-WAN: As end-users adopt more cloud apps and require more bandwidth, SD-WAN may be used to control the growth of MPLS circuits and steer traffic to the cloud, instead of to the central datacenter. It’s a form of containment.

So is SD-WAN a killer-app for SDN? It may be too bold to proclaim it a catalyst that suddenly brings SDN into the mainstream.  I expect the strong pull to modernize WANs will help the adoption of SD-WAN, and that in turn will deliver SDN capabilities into enterprises. Once deployed, SDN technologies such as automation and policy-driven control will prove their value and serve as examples for use elsewhere in the data center.



Hi Dan -- Are there any potential drawbacks you see with SD-WAN? I've heard of concerns about vendor lock-in.


That is a risk and to some extent, hard to avoid in the networking world for early technologies. For example there are no standards for SD-WAN controllers.  But being a "all-in-one" package means it's easier to deploy, operate and troubleshoot. Perhaps one can design the architecture so that portions that can be replaced if you're not completely satisfied with the product you've chosen?


Thanks Dan. It seems like that would be the best approach to take, but perhaps sort of tough to do. 


Some systems use well-known protocols, such as IPsec, so they are not necessarily all proprietary.  I would recommend that our readers assess the product capabilities in addition to their skill-sets, technical knowledge, and desire for ROI in their decision making.  DIY is always an option -- but it's not always easy.


I feel that it is better to invest in upgrading employee skills rather than, spending resources on technologies that are obsolete or close to it. If this eliminates the positive gains in ROI then, at least in the long term the organization would have created an employee base with a higher skills set. 


In particular it can offer the best ROI for SDN technology. But only if you implement SDN, you might need more $$$ to invest in new compatible softwares, I guess it is like re-building your network.


@aditshar1, thanks for reading. I think SDN comes in many flavors. Some requie an overhaul or rebuilding the network (maybe you're doing a datacenter SDN to work with a private cloud), but others are less so. In some cases it's possible to simply "slip-in" to an existing infrasructure (i.e. just install an SD-WAN edge device in a remote office, install some software to control it and let the device segregate the traffic to MPLS or broadband). In the latter case, you do need to purchase new software and hardware but there's disruption and rebuilding.  

Ultimately, as you said, it's an issue of figuring out the best ROI.


Thank You @Dan, I understand the summary in comment. But this brings me back to basic query..i.e. where do we start or kick off in SDN. Do i need to move some part of my network to SDN or i need to rebuild/ upgrade entire backbone.


@aditshar1 --  good point!  The term SDN is not a single, and as you are aware, it's not a single product you can buy, but incorporate many elements into your infrastructure.  But let me take a stab at this.  if you take an approach of using an overlay network, which is what many SD-WAN systems do, as well as some SDN products for the datacenter, it's very much software centric, so it's relative non disruptive.  

In case of SD-WAN, it may be insertion of an edge appliance into your existing network, and it should not be need a big rebuild of the backbone  Converting a datacenter network to be more SDN-like in a virualization or cloud orchestration platform does not require big hardware changes, but will require reconfiguration of the hypervisor settings -- such as virtual switches -- to use the SDN platform.

If you want to do do something more complex, like convert from a traditional three tier network to a CLOS with SDN components, then that may require a rebuild, like you said.

If you take SDN from the viewpoint of network automation, then you can start without rebuilding, since many devices support APIs to help automate settings via scripting languages like Python or anythign that can use RESTful APIs.  Some vendors give you sample code too as a starting point.

So to do the first easy step -- why not start with automation scripts, and then move on more complex things?


Hi Dan -- What do you think of the SDN starter kits a lot of vendors offer now? We posted a roundup of them yesterday.


Marcia, Yes, I've taken a look. I think it's would be a great way to evaluate various alternatives. Depending on what aspect of SDN one wants to try, the list covers many but not all the options.  If you want to try the pure software varieties, those are often available for download and limited time trials (the Brocade SDN Controller in the list and can work with hardware or virtual appliances too, and there are others in the market).

The other ones in the list require some hardware to make it work, but if it's a limited scope trial, it would probably suffice to use it compard to performing a re-design.


Thank you @Dan for short and descriptive response, i guess we need some more and experiance to replace traditional tier network with SDN, rebuilding network sounds little complexsive as if now.


@aditshar1 - I'm not familiar with your infrastructure or level of expertise, but I don't want to discourage you either from trying SDN.  I you want to experiment -- the SDN trial hardware and software listed in the other network computing article is a place to start -- and perhaps there are consultants who can assist.  For example, some datacenters are moving to leaf-spine, so that may be an opportunity to try SDN.  Or if you want to stay with current hardware, there are overlay networks or just automation.  It all depends on how far you're willing to try, or how much time you have to contribute.


Great well balanced article, Dan.

SD-WAN seems like a viable solution for enterprises and service providers.  Do you have thoughts on the importance to enterprises and carriers of coexistence or, better yet, integration between traditional WANs, like MPLS, and SD-WAN?  I'm reminded of the days when carriers and enterprises invested in Frame Relay and then desired a way to integrate or migrate to ATM when that technology was introduced (it was difficult to impossible).  Will MPLS to SD-WAN be easier for enterprises and SPs?


Re: Coexistence?

@WoodCast, great question. I think that SD-WAN will be easier for enterprises and service providers because, businesses are changing in terms of their geographic layout, data and information is being assigned a higher value and the consumers/clients of the business are increasingly found at the edge of the network. This requires that the internet is managed at a high level of efficiency that is comparable to local networks and SD-WAN enables this through better packet reliability, greater control of QOS and higher security through VPNs.

Re: Coexistence?

@Brian.Dean. I agree with you.  In some businesses, the "action" for the nework is shifting - more going to the internet (if you are using SaaS apps like Salesforce), maybe less to the data center (if datacenter based client/server apps are moving to SaaS and there still lots of important work happening at the edge, since that's where the interaction with customers are, or where field work is done (at construction companies, for example). Even though field offices may have fewer servers in the future (maybe i don't need as many file servers in a remote offices), the field offices may need to use the network intensively for other purposes, like video conferencing (they use dto just use the regular telephone -- but now they use that less and do video)

Re: Coexistence?

@WoodCast - Thanks for reading the article.

It is important for enterprises to integrate SD-WAN with their MPLS networks.  SD-WAN's goal is to steer high priority traffic like VoIP over MPLS or other reliable networks and transmit low priority network over broadband. So MPLS will not go away.

As for SPs, I think this will not affect them too much other than the fact they will see a higher proportion of "appropriate" traffic like VoIP over their networks and not "waste" MPLS over something that's not mission critical.

Some SPs are eager to work with SD-WAN companies since it utlimately helps customers get the best value and service over their networks. The SPs can in theory sell both MPLS and broadband to the customers.