When implementing a software-defined wide area networking (SD-WAN) topology, most IT organizations are going to be working with an existing wide area network (WAN) architecture vs. building something brand new. One of the benefits of SD-WAN is how flexible it can be as an overlay technology, so there’s a handful of ways to correctly implement it 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 network administrator, business and end user benefits.
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 is still important to the organization for compliance and auditing purposes. One could argue that a cloud-based firewall and cloud centralized stack is more secure than an on-site security hub. But every IT shop is different, and I have run across 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. Keep in mind 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 the sake of security. This is to ensure 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.
MPLS ports are expensive and not needed 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 simply won’t work in a modern and competitive IT environment.
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 so they can 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.
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 work the organization is doing, 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. A common 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 in a dynamic way.
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 do you have to 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) have the capability to 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 egress traffic efficiency. The organization should understand their VLANs and the objectives of those VLANs before layering on an SD-WAN appliance.
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 are going to 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 to create 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.
Get more tech insights like this right in your inbox with CompTIA’s IT Career Newsletter. Subscribe today, and you can save 10% off your next CompTIA purchase.