When implementing a software-defined wide area networking (SD-WAN) topology, most IT organizations will work with an existing wide area network (WAN) architecture rather than building something brand new. One of the benefits of SD-WAN is how flexible it can be as an overlay technology, so there are a handful of ways to implement it correctly over an existing network. That said, there are a few tricks and tips that organizations have battle-tested up to this point.
Let’s continue our SD-WAN series by focusing on Multiprotocol Label Switching (MPLS) and Virtual Local Area Network (VLAN), two of the most common WAN architectures. We’ll explore how SD-WAN can augment each and add more benefits for network administrators, businesses, and end-users.
SD-WAN and MPLS
MPLS is the granddad of SD-WAN. By applying Quality of Service (QoS) to data packets over diverse connection type and protocol over large geographic areas, MPLS has offered a limited version of data prioritization for decades. What SD-WAN does is ratchet up the stack ranking of those data packets to reflect a software-driven world with dozens of applications.
Most IT shops that keep MPLS in tandem with a new SD-WAN solution are doing so for a few reasons:
- The security of MPLS and the need for a central security stack are still important to the organization for compliance and auditing purposes. One could argue that a cloud-based firewall and cloud-centralized stack are more secure than an on-site security hub. However, every IT shop is different, and I have encountered organizations where data privacy concerns and partnerships dictate that cloud-based security will not work for them.
- MPLS contracts are large and usually involve multiple sites, so it’s important to stagger the SD-WAN rollout and MPLS sunsetting over a longer period. Remember that bundled voice services with the MPLS carrier can create even more incentive to keep the MPLS network in play.
IT shops that run a hybrid environment of MPLS and SD-WAN usually follow a similar logic where deployed. Here are some of the most common features.
MPLS at the hub
Whether the hub site is headquarters or a data center, there’s always a main protected MPLS port into the hub for security reasons. This ensures that the data arrives with integrity and priority. These private lines that lead into the hub are never trimmed out in favor of an SD-WAN connection unless they were never really needed in the first place.
The second most common site that stays put in an MPLS architecture is wherever the data stack/data center lives. This is not to say that SD-WAN can’t exist at the hub; it’s more so that the hub will not be removed from MPLS.
Fewer ports
MPLS ports are expensive and unnecessary for each IP address on an MPLS network with a hybrid SD-WAN deployment. In addition to the added expense, MPLS ports are notoriously slow to provision and scale, sometimes taking weeks or months for implementation or Moves, Adds, Changes, Deletes (MACD) work. That timeframe won’t work in a modern and competitive IT environment.
Bandwidth reallocation
As an example, a remote sales office that once was on an MPLS circuit could safely be transitioned to best-effort connections with an SD-WAN appliance as a network controller on top of it. This is because the sales office isn’t storing any critical data. The critical data is being stored in a Customer Relationship Manager (CRM) that’s already housed in another software provider’s cloud environment.
If the data is encrypted in transit with SD-WAN, and is protected at rest by the software as a service (SaaS) provider, the IT organization can shed expensive private lines in favor of more economical connections. This also allows the IT shop to purchase secondary connections to choose where and what types of traffic go and why—for example, having a dedicated connection for voice and video, and having another circuit for general internet browsing.
More ports
Be careful with the promise of massive cost savings with SD-WAN. Many organizations will find themselves adding ports in the form of cloud connects or cloud onramps into many of the major SaaS and infrastructure as a service (IaaS) providers: Salesforce, O365, SAP Hana, a VoIP/UCaaS provider, Amazon Web Services (AWS), Azure, and more. Once again, this depends on the nature of the organization's work, so adding ports can be a customizable experience.
SD-WAN and VLAN
A VLAN is an extremely popular form of network segmentation that allows administrators to enforce group policy without the need to be in the same geographical area. An everyday use case for VLAN is to take all the voice traffic on an IP network and segment it into a VLAN so there is less data packet loss and collision, in addition to the administrator benefit of managing users, departments, and functions dynamically.
Another common VLAN configuration is a guest network that is secure and separate from the sensitive organizational data.
A last common use case would be for a security system including video and door access management. In fact, many organizations set up VLANs for security purposes vs. purely functional or managerial purposes. If your organization has some history in managing virtual private network (VPN) overlays on top of the VLAN, you’ll have a good starting point for your learning regarding SD-WAN as an overlay on a VLAN.
What must you keep in mind when provisioning SD-WAN overlay on top of a VLAN?
SD-WAN is not VLAN
The SD-WAN appliance is designed to prioritize application priority. Depending on the vendor, it might also add VPN concentration, bandwidth aggregation and a shelf-grade firewall. This is not the same features set as a VLAN. Some of the more robust technology providers (think big logos in networking) can package these services together as images on their routers.
Identity access management and zero-trust networking access solutions are also wholly separate technologies that solve similar problems at a higher level. SD-WAN solutions are not implemented for group policy management but rather for egress traffic efficiency. The organization should understand its VLANs and their objectives before layering on an SD-WAN appliance.
Port assignment
VLANs can be assigned to an SD-WAN appliance ports. VLAN ports can listen only to traffic on those VLANs. Ports and the firewall will have to have policies in place to allow traffic to flow freely. Organizations can also choose failover ports so if one WAN is unreachable traffic between hosts will flow over another auxiliary WAN. This is a choice and not a rule. These ports should be configured statically.
Layers and the order of layers matter
In most configurations with VLAN and SD-WAN, multiple VLANs will be created. These VLANs will be specific to management vs. control/data, for example. Layer 3 VLANs will need to be created one by one on the organization’s switch. Then, sub-interfaces and bridge interfaces can be implemented. Each vendor and subsequent switch will have its own command language for creating VLANs. These most commonly point to a Linux server where bridge interfaces will be managed.
Why use SD-WAN as an overlay?
It’s important to understand that while SD-WAN solutions advertise QoS-type features, they are not actually enterprise QoS services, as most IT and network administrators know them. It’s statistically impossible to guarantee QoS on best effort networks without private ports. But that’s also why MPLS and VLAN technologies have a place in tandem with SD-WAN. It’s all about use case and what the organization is attempting to achieve with their IT investments.
VLANs and MPLS aren’t going anywhere in the immediate future. In the present, we’ve seen a lot of organizations course correct away from overly complicated and slow solutions that don’t move at the speed they need to achieve their goals. Rest assured, regardless of how much legacy network you are dealing with when evaluating SD-WAN, there is a path forward as long as the organization sees the value in it.