cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Why You Need to Jump on the SD-WAN Bandwagon

Level 10

Software Defined WAN is easily the most mature flavor of SDN. Consider how many large organizations have already deployed some sort of SD-WAN solution in recent years. It’s common to hear of organizations migrating dozens or even thousands of their sites to an entirely SD-WAN infrastructure, and this suggests that SD-WAN is no longer an interesting startup technology but part of the mainstream of networking.

The reason is clear to me. SD-WAN provides immediate benefits to a business’s bottom line, so from a business perspective, SD-WAN just makes sense. SD-WAN technology reduces complexity, improves performance and greatly reduces cost of an organization’s WAN infrastructure. The technology offers the ability to replace super-expensive private MPLS circuits for cheap broadband without sacrificing quality and reliability. Each vendor does this somewhat differently, but the benefits to the business are so palpable that the technology really is an easy sell.

The quality of the public internet has improved greatly over the last few years, so being able to tap into that resource and somehow retain a high quality link to branch offices and cloud applications is very tempting for cost-conscious CIOs. How can we leverage cheap internet connections like basic broadband, LTE and cheap cable yet maintain a high-quality user experience?

Bye-bye private circuits.

This is the most compelling aspect for using this technology. Ultimately it boils down getting rid of private circuits. MPLS links can cost thousands of dollars per month each, so if an SD-WAN solution can dramatically cut costs, provide fault tolerance and retain a quality experience, the value is going with all public internet connections.

Vendors run their software on proprietary appliances that make intelligent path decisions and negotiate with remote end devices to provide a variety of benefits. Some offer the ability to aggregate dissimilar internet connections such as broadband and LTE, some tout the ability to provide granular QoS over the public internet, and some solutions offer the ability to fail over from one primary public connection to another public connection without negatively affecting very sensitive traffic such as voice or streaming video. Also, keep in mind that this is an overlay technology which means that using SD-WAN means your transport is completely independent from the ISP.

Sweet. No more 3-year contracts with a monolith service provider.

Most SD-WAN vendors offer some, if not all, of these features, and some are going a step further by offering their solution as a managed service. Think about it: if your company is already paying some large ISP thousands per month for Ethernet handoffs into their MPLS cloud, what’s the difference with an SD-WAN managed service handing off a combination of Ethernet, LTE, etc. interfaces into their SD-WAN infrastructure?

Especially for small and medium-sized multi-site businesses, the initial cost of switching from managed MPLS to a dramatically cheaper managed SD-WAN provider is nothing compared to the savings over only a few years of savings from dropping private circuits.

For organizations such as high-transaction financial firms that want to manage their entire WAN infrastructure themselves and require almost perfect, lossless connectivity, SD-WAN may be a harder sell, but for most businesses it’s a no-brainer.

Picture a retail company with many locations such as a clothing store, bank, or chain restaurant that needs simple connectivity to payment processing applications, files, and authentication servers. These types of networks would benefit tremendously from SD-WAN because new branch locations can be brought online very quickly, very easily, and much more inexpensively than when using traditional private circuits. Not only that, but organizations wouldn’t be locked into a particular ISP anymore.

This is mainstream technology now, and it’s something to consider seriously when thinking about designing your next WAN infrastructure. It’s cheaper, easier to deploy, and easier to switch ISPs. That’s the real value of SD-WAN and why even huge organizations are switching to this technology in droves.

20 Comments

I'd also offer the idea of leveraging competition--if it's available--to reduce MPLS costs.  Not to put down SD-WAN, but I've seen our WAN costs decrease significantly over time, while simultaneously increasing bandwidth.  Apparently our service provider sees the competition and wants to ensure we don't move away from our current services.

It also does not hurt to ask for price improvements.  I have over a hundred WAN sites, some use 10Gig MPLS, more use 1Gig MPLS or L2 Clouds, some use smaller pipes into MPLS.  The provider would lose much if we moved to the competition, while we could move with relative ease and brief outages.

Remember that you can be in the driver's seat, if that's your mind set and if competition or alternate solutions are in place.

Also watch for SD-WAN solutions that may not work as you assume.  For example, I ran into issues with IWAN where the solution unexpectedly limited G3 or G4 provider connections.  We couldn't use different vendors--the provider had to also be the current existing ISP or MPLS vendor.  The solution didn't accommodate multiple vendors to the same IWAN sites easily.

Level 10

Great points for sure. There are some significant differences among SD-WAN vendors, and I've heard of positives and negatives (and experienced a few myself), so solid research and a PoC are still important when making a move like switching to SD-WAN. I know that the hybrid approach is a big benefit that vendors are advertising, and I understand that in terms of the several year process it can take for an enterprise to move away from private circuits, but I still think the biggest value as far as cost savings is in getting rid of them.

You make a good point about being in the driver's seat, too. Providers are hungry for business especially as speeds get faster and costs come down. For some industries, though, the time it takes to spin up a new site is one of the most important factors. I did some work with a engineering firm that had construction office trailers on-site with their building projects all over the state, and though they were temporary (a few months or so), they still needed connectivity to HQ better than standard site-to-site VPN. The solution worked extremely well for them because they could basically spin up a site in no time with pretty much any internet connectivity that was available in the area.

You're totally right about just asking for a better price. Sometimes we don't have because we don't ask

MVP
MVP

Hmmmmm......not a network guy so I am not sure off all the ramifications on this.

Level 20

We've tried this method of using disparate service including cable modems at some sites and it's ended not well... we have gotten rid of all of our T1, T3, and other of these types of mixed connections and moved to a single vendor MPLS cloud and things are much much better than when we did the mix of various services trying to save money.  Our performance is orders of magnitude better now and we're still doing SDN with VMware NSX too so you don't need SDN just for cobbling together different transports... it still has huge benefit even if you're on one MPLS cloud.

Level 10

I understand that. Private circuits are still great as an actual technology, of course, but I was thinking more in terms of the ability to drastically reduce OpEx which is why the last few CIOs I worked with were so interested in the tech. It definitely has more maturing to do, and I know some vendors have more issues than others, but assuming the technology worked the way they promised, I feel the business driver is still pretty compelling. I know many orgs also do a hybrid model almost as a PoC or just to keep small branches online with SD-WAN while keeping the DCs and large sites in a private MPLS cloud. I've heard horror stories regarding one particular vendor, but then I've had nothing but success with the vendor I'm working with now.

We've rolled out Silverpeak with great success thus far. Echoing others' comments here, not all SD-WAN products are created equal, of course, but the SP software has matured nicely and allows us to mix-and-match MPLS and commodity circuits with ease.

For companies that have significant MPLS spend/sites, I can see why getting 'in the driver's seat' with regard to pricing negotiations may be useful. Those types of customers are not the primary target demographic of SD-WAN providers. If you're a managed services customer, have less than 20 MPLS sites, are locked into multi-year contracts based on spend, and don't have the ability to renegotiate price mid-stream, SD-WAN is a great way to begin weaning oneself away from dependence on MPLS and demonstrating the benefits to your business before it's time to re-up into another three years of guaranteed opex that is acceptable only because 'it's always been this expensive'.

I appreciate someone admitting in the open that there are big benefits in avoiding an environment built with multiple services.  One can have good things (consistency, predictability, single-place-to-call-for-tech-support-issues, etc.) from putting all the eggs in one basket, no matter how negative that description might seem.

It's a tough line to balance on.  On the one hand is a single point of failure but an easy one to configure and troubleshoot.  On the other hand is the discovery that having multiple WAN services and types of WAN services can be difficult to balance, support, and use.

No one wants a total outage, no IT staff want to discover that their kluged-together combination of T1's, DS3, broadband, L2-WAN, and MPLS/BGP cloud can't keep everything up and running with the required latency and throughput when the big pipes go unavailable due to any reason (backhoe fade, heat sag, suck-out, rodents, birds, component failure, etc.).

Thanks for saying there are benefits in keeping it simple, keeping it fast, by using a single-vendor MPLS cloud.

Level 21

Much like Jfrazier​ I am also not a network guy.  You certainly did a good job of highlighting some of the benefits of this technology but what are the drawbacks?  There are two sides to every coin so I am curious to know what the flip side of those benefits is?  Are there any security ramifications?

Especially if your business is understanding when one of your sites served only by MPLS suffers a hard outage that no SLA agreement will fix - such as an errant backhoe as you mentioned.

What we realized quickly is that we are still depending on a single provider (in this case, the SD-WAN solution itself) - we had just abstracted that dependence away from the pipes themselves. Our pilot has been slow and measured with those thoughts in mind. With regard to security - again, we're beholden to the quality and security of the provider's platform and architecture, and we had quite a few discussions about how that piece was protected.

Level 13

I agree, the savings for moving off MPLS is great.  We did it 6 months ago and have already recouped to initial cost.  Plus increase bandwidth too boot.

Level 20

Another HUGE advantage to being on one private MPLS cloud is perfect QOS across the entire infrastructure.  We now have solid and by using NCM consistent QOS configuration from Coast to Coast in the US.  We've upgraded our WAN routers to the newer Cisco routers which run essentially linux which give us the ability to be a Sourcefire IPDS inside each WAN router and provide visibility into L1 - L7 and what's happening at each entrance into and out of the WAN.  By using Cisco Firesight I can see any questionable traffic and we can put rules into place with Firesight to isolate any site that might be infected with any detected exploits trying to spread.  This really is the state of the art in IPDS technology.

That's really impressive!

This scenario (I think) sort of supports my earlier comment - that a company/network/infrastructure such as yours is not the target customer for the majority of SD-WAN technologies as they stand today. You have your own routers, pipes, and sufficient internal expertise to guarantee the results you describe. SD-WAN has helped smaller companies like mine - that are constrained by size, contract restrictions and other obstacles of scale - to be *less* hobbled by those constraints through abstraction.

Level 20

So true... you have ONE phone number to call and the big MPLS providers have built great redundancy into their own MPLS clouds.  Nothing is perfect, like you said, there will always be power failures, fiber cuts, and some things aren't avoidable.  Another great things about having the MPLS provider hand you a fiber at each site is when you need to change bandwidth... it's easy!  You need 40G here 10G there.  The need changes and it can be adjusted quickly to meet demand.  As I stated above as well... having real consistent QOS across the entire network is powerful!  I've even gotten them to give network management traffic more priority than normal which is great for Orion.

We really tried to save costs by going the cheapest route at many sites.  At first the cable modems seemed like a HUGE savings and thought it was going to increase bandwidth for smaller sites... until over time when things went bad... there was little we could do.  Having netpath in 12.x Orion is going help I suppose but when the internet just fails some places and you're just connected out into wherever your packets happen to go to get to their destination is can be very frustrating for troubleshooting.  I'm really looking forward to using netpath.

I was lovin' your train of thought, then you back the benefits of having multiple services when you referenced being down because "the internet just fails." 

That's the big use case for having multiple services, vendors, and paths.

What's most important?

  • Cost of being 100% down
  • Cost of more services that can prevent total WAN / site outages
  • Cost of supporting multiple vendors/services and the associated complexity

I suspect my management team would say they are more concerned about being a site being 100% down, and they'd accept some pretty steep costs in complexity and multi-vendor-WAN solutions and staff headaches to keep it all straight, all towards preventing a site being 100% down during business hours.

MVP
MVP

The question here is...what is 100% down ?

There is a point where things are so slow that you are effectively down and you are not generating enough traffic to do enough business to cover daily costs...your are effectively down at that point although everything is "up".

Good question....and defining what 'so slow you are effectively down' means is a slippery one for lots of shops, I'd wager...after all, it depends who you ask!

I took the easy way out:  backhoe fade is 100% down.

It gets nebulous and gray when saying "application X is essentially unusable when latency exceeds some number of milliseconds, or when bandwidth drops below a specified rate."

Having SD-WAN or IWAN available can still result in that application being down if it needs a lot of bandwidth or low latency--but VoIP phones might work through IWAN because their traffic got sent out a G3 or G4 pipe, while the big application's data is stopped until the broken fiber is repaired.

Is the site truly "down" 100% if the app is down, but folks can still get to the Internet, can still use their VoIP phones and get e-mail or use Citrix through alternate circuits through SD-WAN?

What level of functionality or non-functionality can a business or Management Team accept before calling it quits until the fiber is repaired?

pastedImage_0.png

Level 20

Also I suppose if this application or site is that important then you would have more than one provider bringing in connectivity too... it all comes down to what you're willing to "accept" and "pay."

Surprising!  What sort of SLA's go with the new services?  Will your WAN be as resilient as the MPLS cloud was?

What technologies did you go to when you left MPLS?

What bandwidth improvements resulted?

How much hardware was involved in supporting the new solutions?