Business Case for SD-WAN

An anonymous commenter wrote this comment to my initial SD-WAN post:

I can still hardly imagine the business case behind SD-WAN. Any thoughts?

This question is really easy to answer. There’s a huge business case that SD-WAN products are aiming to solve: replacing traditional MPLS/VPN networks with encrypted transport over public Internet. However…

Why would you want to do that? Internet access is often orders of magnitude cheaper than traditional circuits. Replacing MPLS/VPN circuits with IPsec-over-Internet (or something similar) can drastically reduce your WAN costs. Trust me – I’ve seen dozens of customers make the move and save money.

Why is anyone still using WAN circuits? Where’s the catch? Contrary to some very vocal opinions, traditional WAN circuits still use lower oversubscription ratios and get close to the promised SLA most of the time. Some service providers offer business-class Internet services with guaranteed bandwidth and SLA, but these solutions tend to cost approximately as much as more traditional alternatives. Reserving bandwidth, providing support and fixing errors in real time costs money.

Weren’t we doing it a decade ago? Glad you asked. Of course we did. When I was working for a system integrator we migrated most of our customers to hybrid WAN in early 2000s, and I’ve worked with multinationals that run hybrid WAN on a global scale (sometimes coupled with PBR to separate business-critical traffic from the nice-to-have one).

Companies that prefer spending money on WAN circuits instead of upgrading their infrastructure and investing in people who actually understand how to run it are obviously stuck in the past and a ripe target for an SD-WAN sales pitch.

What’s the big deal then? If a smart group of engineers works on solving a problem for a decade, and then starts from scratch, they’re bound to create a more elegant and more optimized solution.

If they think about orchestration and monitoring from the moment they start designing the system, their orchestration system (aka controller) tends to be orders of magnitude better than Java-based GUI slapped in front of the hard-to-automate CLI.

The emerging SD-WAN solutions thus tend to be way better than a hodgepodge of protocols that grew organically for over a decade (keep in mind that we used NHRP to build shortcuts across ATM subnets).

Last but definitely not least, do keep in mind that at the moment every SD-WAN vendor focuses on what they perceive to be the sweet spot. Once their products hit reality and the customer pressure to implement per-customer knobs, they’ll slowly get as complex as the current solutions.

Finally, why is everyone so ecstatic? Because people always want to believe that it’s possible to replace investment and hard work with magic. The same managers that believed Cisco’s slide decks about the beauties of DMVPN (and got burned by the complexity of the real-life) now believe that it’s possible to throw away all the old stuff and replace it with next-generation magic. I wish them luck.

Recent posts in the same categories

5 comments:

  1. JHand 02 July 2015 19:39
    Traditional WAN circuits also have significantly less attack surface. Do Enterprises using fully Internet-based or Hybrid WANs have a Plan B for the possibly distant, but ultimately inevitable 0-day or PSIRT? Does their business case analysis include the business impact of such an event? Or are they assuming the the network is safe because the traffic is encrypted in IPSEC, and their router has ACLs limiting the traffic?

    Please note that I don't work for or have any interest in pushing FUD on behalf of carriers. This is my own, genuine FUD.
    Replies
    1. Ivan Pepelnjak 03 July 2015 06:59
      Perfectly valid question. Most of them assume the additional exposure of the network is limited due to ACLs and IPsec (and transport VRF if you use one). Some customers with higher security requirements use very specific ACLs that limit source IP addresses, and use per-peer IPsec keys or certificates.

      Obviously it's possible that there will be 0-day in Cisco IOS that will allow an intruder to send unidirectional traffic cloaked as IPsec, bypass all IPsec checks, and jump across VRFs (and I wouldn't be surprised to learn 3-letter agencies have it). However, while you should never say never, I do think other attack vectors are more likely.
    2. Unknown 03 July 2015 13:59
      Also on the subject of attacks, DDoS. Internet uplinks are obviously more open to that than private WAN circuits (which should be essentially off-limits to outside equipment). We've been hit with a DDoS attack more than once, and I'm really glad we don't generally use IPSec tunnels over the internet for remote site transport. Would've been rather bad if our internal transport networks had been hit aswell.

      And yeah, you could theoretically have backup WAN links, but in that case you'd be paying MORE for the solution in total, not less. I see no scenario in which we'd replace our backbone with VPN tunnels.
  2. JHand 03 July 2015 12:44
    Also, the very existence of IPSEC CAC suggests risks for DoS attacks that the ACLs won't necessily protect against and can leverage encryption as part of the attack.
  3. Christoph Jaggi 04 July 2015 18:46
    I have a gut feeling that the cost mainly shift from the network (WAN) to the customer edge as the savings in circuit cost are to a large degree offset by the cost of security equipment. It depends on the use case, but in most instances using a WAN circuit makes business sense from a cost and from a performance (SLA) point of view. The cost of WAN circuits have come down quite a bit over the last decade while the cost of providing real security in a L3-L7 environment has skyrocketed.

    Please note that I do not work for a carrier and that for me security add-ons in routers and switches tend to be insufficent to provide real security.
Add comment
Home
Sidebar