For all the hype that’s surrounded “software defined” there’s precious little tangible proof of a clear concise definition that everyone can agree on. To some it seems to mean a regression to the days of router-style technology where all networking decisions are made in general purpose CPU and RAM; to others it means little more than a fancy way of branding yesterday’s automation and orchestration software.
For the purposes of this article, we’ll be radical and try to propose a single definition that will encompass all forms of SDN including SD-WAN:
Using software and policy to remove the need to configure a network.
Radical, isn’t it? Removing the need to configure the network. That’s ultimately what we’re trying to achieve though, since a lot of the problems we have with modern networks is that they don’t adapt to change fast enough (i.e. the engineers controlling them can’t change them fast enough) and thus we spend most of the time working with sub-optimal configurations for what the network is trying to do for us. That’s the promise of SDN, that our network will be able to configure itself, and adapt to changing use and changing network conditions automatically, but with much more intelligence than simple automation and orchestration can provide.
What’s wrong with the Network I have now?
For years, there’s been a primary disconnect between IT and users. We’ve all heard the sayings “problem occurs between keyboard and chair” or “the network would work fine if it weren’t for the users”. While often a bit of friendly banter, there is some truth to the fact that the arbitrary configurations assigned to many aspects of modern IT don’t accurately reflect usage patterns. A network engineer may well set aside a chunk of bandwidth for backups, however these backups don’t happen continuously so that backup capacity sits idle most of the day while users suffer with insufficient speed. Routing of traffic across the WAN is often inefficient and fails to recognize those users and applications that need better performance from those who could live without it. Video conferencing has become something of a poster child for this fact, as many organisations have found that getting a reliable high-quality telepresence meeting to happen requires monumental efforts on the part of IT and often must be scheduled well in advance or be configured to use its own dedicated bandwidth.
The result of all of this is that the purchasing of networks has also become inefficient. Either too much money is being spent, or the user experience is not good enough, but few businesses seem to be able to get the balance right. We also see many businesses stuck in contracts with service providers for “managed” networks, that are anything but – as they are so static and slow to make changes that they are never well matched to the actual organisational needs. It’s almost laughable that when we think of management in the sense of people, it’s those managers who are quick on their feet, adaptable, approachable, resourceful and always in tune with their staff; yet I don’t think any of us would describe our relationship with our managed network in those terms.
SD-WAN is just a VPN right?
There are those out there who would have you believe that SD-WAN is a “secret sauce” that lets you do all your corporate networking over cheap commodity Internet, and do away with private networks entirely. Certainly, there are those providers who are offering just that, but before we get carried away, let’s go back to our agreed definition of SDN and then apply it to a WAN. I stated that the point of “Software Defined” was to use software & policy to remove the need to configure the network; I’m certain I didn’t say that it was to build your network using virtual private networking technologies! This is a flawed and potentially dangerous over-simplification of SD-WAN. While it’s true, that SD-WAN technologies would remove the need to configure things like encryption, and secure networking such as we use in a VPN; and while it’s true that SD-WAN could create and manage VPNs for us, when appropriate, to say that this is all it is misses the point entirely.
We always could use VPN over the Internet, this isn’t new, in-fact encrypted connections over public networks is one of the oldest applications we’ve had on the public network aka “Internet” with initial work on the most common connection encryption standard IPsec being started as early as 1993. Clearly with the predominance of MPLS and VPLS private WAN networks since then, it’s not the existence of VPN that’s fuelled the need for alternative WAN network topologies, but something else. The answer can be found in the debates surrounding “Net neutrality”. One of the basic tenants of the Internet is that you cannot pay to have better service. You can pay to have more service, but not better service. This means that if you have a critical application like a payment system, you simply cannot rely on Internet alone as you’ll always have issues with congestion.
How private is that VPN anyway?
Aside from the issues with performance, we still have yet more issues with pure-play VPN over Internet SD-WAN solutions. Namely, the “Private” part. We’re lead to believe that a VPN is analogous to a private network, however as we’ve seen with issues surrounding net neutrality, this isn’t true, there’s a whole world of traffic out there that’s riding the same network as our “private” network traffic. This doesn’t mean in and of itself that our traffic is not private however. I mean if we continue with the road analogy, we can have a private vehicle on a public roadway, right?
Unfortunately, when you use a VPN it’s a bit like one of those play-tents your kids enjoy at the park. Sure, it looks like privacy when you’re in the tunnel but anyone in the playground can jump up and down on the tunnel and really interfere with your ability to use it! This isn’t just about congestion and reliability; we’re now talking about DDoS and having a point of vulnerability where a competitor or hacktivist can take cheap and easy steps to interfere with your WAN connectivity and interrupt your critical business operations. As encryption technologies improve, it does become less likely that they’ll be able to access your data, however you need to consider how important your data is, and how important being able to access it is before relying on a VPN as your only means of WAN connectivity as it’s all too easy for the hacker to take away your access when you’re travelling across the Internet.
So there’s a WAN and a VPN?
Here we come to the crux of the matter, is SD-WAN simply something old that’s new again? The promise of SD-WAN, done correctly, is that we’ll be able to combine together both private WAN links and Internet VPNs into an intelligent self-configuring WAN that dynamically builds connections as needed… Rather like DMVPN. For those who aren’t familiar, DMVPN provides the capability for creating a dynamic-mesh VPN network without having to pre-configure (static) all possible tunnel end-point peers, including IPsec (Internet Protocol Security) and ISAKMP (Internet Security Association and Key Management Protocol) peers.
This network can use both public (Internet) and private (VPLS) circuits as the transport, then create a new overlay network using tunnelling technology. It’s certainly miles ahead of MPLS-WAN as it allows the user the ability to configure and manage their own WAN, controlling routing and IP addressing across their own network irrespective of the service provider; and many businesses are doing it now. In-fact it’s widely supported on mid-high end routers from most of the major branch office router makers.
So what’s the difference? Or put another way, what’s wrong with DMVPN that we needed to invent something else? For many customers, nothing, hence why adoption of SD-WAN has been slow relative to other software defined networking applications. Still there’s more than marketing hype here.
SD-WAN from many vendors is essentially promising that it will eliminate the whole host of complex standard protocols used in DMVPN and hybrid-VPNs with some “secret sauce” – not a very comforting thought. What it does however, when implemented correctly, is wrap the complex technologies we know and trust including the encryption, tunnelling and addressing technologies in a friendlier, APP style software wrapper. It’s not that the network has changed, but it’s much more approachable.
So what do I get?
To put it simply, SD-WAN allows you to use two or more “transport” networks, typically this will be Internet plus a private “wires only” or VPLS style service between all your corporate sites through a centralised or often cloud-based WAN controller interface.
What this means for the user, is that there’s no complex router-by-router configuration necessary to manage the WAN. Even better, it may not even be required to have such expensive router equipment at each site, as often the SD-WAN intelligence will be done inside the compute environment as a virtual machine (or virtual appliance in this case). This means that the SD-WAN network allows us to seamlessly interconnect our sites via Layer-2 or Layer-3 directly into the LAN switching environment, across two or more separate transport networks without any costly equipment or complex configurations. That’s a real win, and that’s why SD-WAN does go beyond traditional hybrid-VPNs.
By programming the SD-WAN with your business requirements (what traffic needs to be guaranteed, more secure, faster vs what is low-priority traffic or traffic that can be sent publicly) the controller uses all available network resources to deliver the best possible overall experience. What’s more is that because it’s actively controlling the network, it’s able to adapt and change on demand based on changes in the network, in the traffic or even based on pre-set things like time-of-day. The WAN isn’t being configured by people anymore, it’s being managed by software in real time. That’s SD-WAN.
As businesses become ever more dependent on real-time connectivity between all their disparate locations, SD-WAN will become ever more relevant. The beauty of SD-WAN isn’t that it negates the need for traditional private WAN networks, it’s that it puts those networks firmly in control of the business, not at the behest of network engineers (whether internal or at the service provider). The businesses that will most benefit from SD-WAN are those that understand the wider benefit of centralising their IT functions, eliminating duplication between locations, and leveraging the low-cost high-bandwidth links available today together with cloud-based applications and technology to streamline their IT and increase the efficiency of their business and IT operations through software, DevOps, mobile and digital. SD-WAN is the natural underpinnings of these kind of digital native businesses.