Software-defined WAN is becoming increasingly popular, and for good reason—it effectively solves a number of important challenges posed by traditional WAN architecture. Reduced costs, increased application performance, more flexible network topology, faster deployment and improved security are the main benefits SD-WAN offers. Read on to learn more.
A WAN, or Wide Area Network, is the computer network spanning a wide geographical area (regions, countries or even world). You need a WAN when you have a number of geographically distributed local networks that need to communicate with each other. Sometimes you need your individual hosts within a given local network to be able to communicate with private hosts in other local network. At other times, you need to create a private subnet spanning a number of local networks to have all the hosts within it securely connected.
These are just two examples of the use cases for how WAN can solve problems. Figure 1 below breaks down different types of computer networks by their geographic scope.
Fig. 1 Computer network types by geographic scope.
A WAN can have different geographic scopes and purposes:
- WANs connect multiple local (LANs) campus (CANs) or metropolitan (MANs) networks.
- WANs can be private, built for a particular organization, or created by Internet service providers to connect local networks to the Internet through a shared infrastructure.
- The Internet is an example of a WAN network with global access and standard services—WWW, electronic mail, Internet telephony (VoIP), etc.
WANs can be built using dedicated physical/fiber architecture shared by many clients using MPLS technology, among others (see Figure 2).
Fig 2. Different types of WANs
WANs can be used for different types of traffic: mobile, IPTV (e.g. mcast). Internet, B2B (e.g. VPN). A typical WAN use case is setting up a VPN, a topology of which can be seen in Figure 3.
Fig 3. Typical WAN topology
Before the SD-WAN era, the typical WAN topology looked as follows: hub site (for example located in a company HQ), usually with a data center providing central services (applications and storage) for spoke sites (branch offices). The hub site also controlled Internet access with proper security rules (firewall, threat detections, Internet service forwarding, etc.) applied and managed by the IT department. Such a WAN could be realized through a number of technologies, for example using IPSEC or MPLS tunnels.
While a traditional WAN approach is currently the most widely used one, it poses some important challenges.
- Rigid, static topologies
WANs were designed before the Cloud era. But today's traffic has different characteristics and requires quick, dynamic changes in topologies. This is why single, centralized hub sites are rare today. Different locations can serve different services depending on their physical location or organization capabilities.
There are even government rules preventing the storing of critical data outside of the given country’s borders. GDPR is a good example here. It all makes network topologies far more complex than just a single hub and spokes.
Of course, in classical WAN networks you may also have different types of topologies, not only those based on a single hub. Still, managing such a network is much more complicated and requires a gargantuan effort from IT departments.
Moreover, network segmentation is also an important feature in today's topologies. While segmentation can be easily done locally (e.g. based on VLANs), it is no trivial matter across an entire WAN, requiring considerable work at each site.
- Application performance
In a classical WAN, all the services share the same link. As a result, some of them may use more bandwidth, thereby starving other critical applications. Bandwidth usage can be dynamic, as different services may require different bandwidth during a year, month or even a day cycle (or even random ad-hoc spikes). Changing network policies in such a cadence in a traditional WAN is possible, but requires well-developed competencies and considerable investment in infrastructure.
- Slow deployment
Starting a new branch in a traditional WAN requires a good deal of planning and network engineering work to be done. It also calls for an MPLS line provider to be used, and a network specialist to work onsite.
Today’s business world requires more agility. You need to be able to create and shut down branches dynamically or even manage mobile sites, which change their location daily. Such demands require many corresponding services including VPN, firewall on the edge of spoke sites LAN, QoS on the edge, to name a few. Making these services up and running and providing their reliability and security require considerable investments and constant costly maintenance.
A classical WAN can be more secure, as the entire traffic going outside is routed through the central hub (thus compromising agility). Yet if there are any local Internet breakouts configured (direct access to Internet from local site), they must all be managed locally and individually. This opens up room for human error and requires considerable work to be done and strict procedures to be defined and applied throughout the organization.
Bear in mind, also, that MPLS/VPNs are shared networks. Traffic from thousands of different customers and users (including traffic from other carriers as well as the Internet) traverse a common set of backbone routers. In reality, the Provider Edge (PE) router is a “shared platform” where different customers, including Internet customers, are connected.
Of course, all those client networks are logically separated and the network operator can usually be trusted, so it isn’t all that big an issue. Still, if your WAN needs to be fully secure, you’ll want to have some encryption applied at each edge of your hub-and-spokes network. Expect this to increase the costs and work involved.
- High costs
Using private MPLS links means incurring considerable costs. This is especially important today, when widely used SaaS platforms and other cloud services generate more traffic that is directly routed to the Internet. It also means that spoke sites use costly MPLS line bandwidth just to connect to the Internet through their hub site (where the Internet gateway was located and managed).
In a nutshell, SD-WAN is an implementation of the SDN concept into WAN topologies. SD-WAN stands for Software-Defined networking in a Wide Area Network. The main concept mirrors that of SDN—to separate the control plane from the data plane and centralize the control plane in form of a shared service, where the control plane controls a multiple number of devices.
In this context, “shared” means accessible for all administrators within an organization. In case of multi-tenancy, the same service can be shared among many organizations. SDN technology opens up a number of new opportunities.
First among them is that policies can now be managed from a single place, while more sophisticated, proprietary algorithms can be used to manage data traffic. Of course, it is always beneficial to use standard technologies, protocols and services (to identify and solve network issues, to use some standard services and devices within the network etc.).
With SD-WAN, however, the standardization is no longer critically important, as the implementation runs as a service delivered by the SD-WAN solution producer. The only standardization will be applied between devices (switches, routers) and the controller, which sends to the devices concrete policies to be applied on each single device level (e.g. using OpenFlow protocol).
Still, SD-WAN solution producers usually deliver their own proprietary devices which do not have to use any standard means of communicating with the controller. Such solutions use proprietary protocols crafted specifically for them. This allows them to be lighter, faster and better, as there are no legacy devices which they would have to support when using standard protocols.
It’s up to you which path you follow: a standard or customized one. Standards will give you more flexibility in terms of external hardware or services you may add to your solution. On the other hand, if you know that your SD-WAN provider will provide you with all the features in out-of-the-box form, you can choose a more customized solution. This will give you flexibility in adding new features as well as the enviable ability to react faster to market changes.
Layers of SD-WAN architecture are shown on Figure 4 below.
Fig 4. Layers of SD-WAN architecture
A look at how network management was handled before the SD-WAN era will help illustrate just how far we’ve come with software-defined networking in WANs. In classic WAN solutions, the control plane concept was implemented as a distributed system with its components running on each routing/forwarding device in the topology. The configuration was very often done manually on each individual device. Other corresponding services, like firewalls, QoS and encryption were also very often managed locally.
This means that even though the software (or rather we shall call it firmware) was handling the control plane tasks, it remained coupled with hardware devices—firmware handling the control plane was running on the same devices that were responsible for data plane traffic handling. So, instead of the prefix SD, we could use HD (Hardware-Driven) for classical WANs, as all the orchestration realized through control plane protocols was handled by specialized hardware, usually dedicated and bound to a specific, proprietary firmware running on it.
If you have such a large number of hardware devices that need to be controlled individually, there will be an attendant and constant need to have a large number of people doing the controlling. Numerous teams have to communicate with one another to manage the sprawling network. This usually means processes, procedures and routines needed to be applied at every level of the organization, from individual divisions within individual sites to the overall organization. That’s why the classic WAN approach can also be dubbed PEOPLEWARE-WAN.
- More flexible network topologies
As your policies and configuration will henceforth be managed automatically, you need not worry unduly about your network topologies. You can continue to use your hub-and-spoke topology, but there is no point in keeping only a single data center. You can now focus on your system architecture and deploy your services in whatever way you feel is convenient, using the topology that is most suited for it.
You can even scrap the data center entirely and instead spread your services among your branch offices, if doing so makes sense from the point of view of your system. Most importantly, the limitation of network topologies has been removed and you can now focus on more crucial questions. Where should your data be stored to stay compliant with legal requirements? What will be the best location for deploying a given service to provide the best response latency and the highest connection reliability? What will be the lowest cost of connecting a given site to our system?
In the classical WAN era, the more rigid network topologies that ruled the day made solving these problems difficult. This rigidness resulted from the high costs of support and maintenance required to handle each new data center and Internet gateway (see Figure 5).
Fig 5. Sample SD-WAN architecture overview
Even when you keep your old hub-and-spoke topology, with a single data center used in the system, you do not have to worry about your Internet connection, which now can be directly accessed from each site. Internet traffic no longer needs to be routed through your hub for the sake of security, and your security rules are now applied automatically at each site. This makes your connections more efficient, as bandwidth is no longer wasted on internet traffic backhauling (see Figure 6).
Fig 6. Possible SD-WAN topologies
Starting a new site with SD-WAN technology usually takes just a matter of days. Your SD-WAN solution provider just has to ship a routing device to your site. The device itself is usually based on popular architectures, like x86, which is cheap, proven, easy to replace hardware. You just need to plug it in to the Internet or whatever other means you use to connect your sites, e.g. through MPLS. The device (or software, if it is delivered in virtualized form) will register itself into the controller, download all the applicable policies, configure itself and, voila, your site is up and running.
You can even start your mobile sites by very quickly connecting them through an LTE connection to the Internet. When it comes to networking, you can now treat your system as your own private virtual cloud (see Figure 7).
Fig 7. SD-WAN as a base network infrastructure for your private cloud services
- Increased speed of deployment
Thanks to the zero-touch provisioning described above, you can deploy individual sites or even a bunch of them very quickly and efficiently. Better still, you don’t need many engineers working on it, as most things are done automatically.
Additionally, centralized policy management is also helpful here. You manage all the site-specific configurations from a central point through the intuitive management platform. SD-WAN solutions also have an embedded monitoring system, ensuring better network visibility and making deployment and troubleshooting much easier.
- Higher application performance
As your topologies are not so rigid now, you can adjust them to the characteristics of your network traffic. Your sites may connect to the Internet services through your local Internet Breakout, which usually boosts the performance of SaaS applications (e.g. Office365).
You can also place your region specific data at one of the sites within the region and have other sites connect directly to it. This will shorten your traffic paths, which in turn will further boost performance (latency, bandwidth etc.). You can even move forward with network segmentation based on the application layer.
SD-WAN solutions often provide deep-packet inspection mechanisms applied in the dynamic routing services. Packets from specific types of traffic can be routed differently than others. For example, your site can use local Internet breakout for Office365 traffic, but it may use your connection to a specific site when your internal video conferencing system is used. Everything is smooth and transparent, so users of your network don’t even notice what happens under the hood. The only visible effect for them is a better experience, as the applications run more smoothly.
- Improved security
Your network administrators are also happy because they know that not only does each site work more efficiently, but is also protected from network threats. The policies are now managed and automated at a single place (controller) to eliminate human error.
This is an important point to remember. SD-WAN uses many proprietary, non-standard solutions and the security improvement should not be taken for granted. Those systems are not as commonly used as classic WANs, so there is a bigger chance that they have some security flaws that have not yet been detected.
- Reduced costs
It is not like SD-WAN is always a cheaper solution than a classic WAN approach. What it does give you, though, is flexibility. You can modify your network policies and topologies much faster and more easily to quickly react to the market or internal needs.
Furthermore, you are not limited to a given provider when it comes to networking. Of course, for your critical traffic you still need to rely on your most trusted supplier (critical links are usually costly). For low-priority traffic, you can use a generic ISP to make the tunnels between your sites. You may also use your ISP to access SaaS systems directly from each of your sites.
With an SD-WAN you can route traffic according to its source, e.g. use a standard Internet connection for video streaming or more reliable link for the ERP system. All these can be done by defining policies in a central location (controller). These policies are then automatically applied to every local network connected in your WAN.
Usually, your SD-WAN provider will also provide you with some firewall service on the edge of your site network. The policies for it are also managed at the controller level, so your Internet traffic doesn’t have to be backhauled to your hub. In this way you save on costly MPLS line bandwidth.
Last but not least, network engineers will no longer be needed at each of your sites. A central network engineering team working from anywhere in the world will be enough to manage your SD-WAN, and allow you to cut costs considerably. Less people directly involved in managing the network means fewer errors, saving you even more money on costly troubleshooting.
Let’s briefly summarize the main business benefits that implementing SD-WAN brings:
- More flexible network topologies
- Increased speed of deployment
- Higher application performance
- Improved security
- Reduced costs