How enterprise networks use WAN virtualization

Virtualization is a backbone of network design, management and security in the modern enterprise. Surprisingly, in most enterprises, virtualization came to the WAN last, but it arrived with enormous sophistication in a short time.

Virtualize the WAN: Layers, like an ogre

Carriers were the first to use virtualization in the WAN. They introduced technologies, such as MPLS, to provide what appear to customers to be isolated WANs but which share infrastructure within the customer-facing edge.

Providers use virtualization for the same key reasons enterprises do, such as the following:

• to reduce costs by sharing infrastructure, instead of duplicating it for different use cases;
• to provide privacy and security via logical segmentation of traffic on shared infrastructure; and
• to enable performance management specific to the traffic within a virtual network.

Abstraction layer

Enterprise-focused virtualization began to emerge in the mid-2010s. The initial goal with these strategies was to extend virtualization to the underlying connectivity in enterprise WANs. These virtualization platforms provide a layer of abstraction immediately above the WAN connections, so capacity can then be allocated to WAN traffic, instead of pointing traffic at a specific interface.

Physical connectivity

The physical connections are underneath this abstraction layer. Because of the abstraction, changes in the connection pool -- such as swapping one provider for another -- don't necessitate changes in how capacity is used. This capability accomplishes the two following goals:

1. It can make many things look like one.
2. It can make one thing look like many.

In other words, abstraction makes many links look like one, available as long as any of the links work. This enables the platforms to reroute traffic from a failed or failing link to a working link, transparently to applications and users. It also enables the aggregate bandwidth of multiple links to be allocated to different classes of traffic as needed.

Virtual WAN overlay

Virtualizing away the physical details of WAN connectivity was the crucial first step in the WAN virtualization journey. With the tight coupling of logical WAN to physical WAN broken, it became possible to create multiple logical WANs, or virtual WANs, overlaying the same physical layer.

Virtual WANs can carve up and allocate overall capacity across various traffic classes, as defined by application needs, institutional priority or any number of criteria over time. Different subsets of sites and users can have different sets of WAN traffic management rules.

SD-WAN

Software-defined WAN (SD-WAN) emerged as the logical endpoint of the WAN virtualization movement. SD-WAN fully applies the bifurcation between the control plane and data plane at the heart of software-defined networking to the problems of the WAN.

SD-WAN supports management of the WAN as a unit instead of as a large collection of individual sites. For management purposes, SD-WAN abstracts away as much as possible the details of any given site's connectivity profile. This abstraction enables network managers to focus on defining policies to govern traffic management at a higher level than interface configurations.

There is no magic with SD-WAN, though. Someone always has to deal with the details of physical connectivity, whether it's an enterprise network engineer or an MSP engineer. The number of such folks required, however, and the number of times and ways in which they have to deal with the underlay's details should greatly decrease.

Design practices and considerations for virtual WANs

Security considerations

For security, virtual WANs can be part of a zero-trust architecture. For example, an SD-WAN can create virtual WANs that carry only sanctioned traffic and drop unsanctioned traffic.

A software-defined perimeter defines a one-to-one VPN between source and destination. If the conversation reaches across sites, that makes it another form of security-oriented virtual WAN.

Network engineers that think of virtual WANs as security partitions must dig deep into the implementation details of their underlying designs to ensure that, in overload conditions, they drop traffic (fail open) rather than pass it through with incomplete processing against policy (fail closed). Most traditional WAN offerings fail closed, opting to move traffic rather than dropping it, as the traditional goal of the WAN is to deliver every packet. Strategies that have more of a security mindset will -- or can be told to -- fail open, as their overarching goal is to ensure that traffic passes only in accordance with policy.

One aspect of WAN virtualization that network teams can't neglect -- but is often glossed over in WAN strategy development -- is underlay management.

Performance considerations

Most offerings perform better with fewer traffic classes to manage, so network teams should resist the urge to define a class for every application or department. For example, if security allows it, teams should assign one class for real-time communications tools and one class for all the tools that move data with tight time constraints, such as backup and email.

One aspect of WAN virtualization that network teams can't neglect -- but is often glossed over in WAN strategy development -- is underlay management. Once an SD-WAN tool is in place and sites can easily aggregate connectivity from multiple providers, provider sprawl kicks in. It's easy for an organization to have as many connectivity providers as sites and possible to have more.

Although the technical aspects of using all that connectivity are hidden under the hood of the SD-WAN, the organizational aspects -- e.g., dealing with billing and billing disputes, contract management, trouble tickets and so on -- are not. WAN teams should define a strategy for managing the pool of providers, such as having only two providers per metro area, state, region or country. Another option is to outsource the problem to a connectivity aggregator or a managed SD-WAN provider.

When transitioning to WAN virtualization, most organizations lay an SD-WAN on top of their existing primary WAN connectivity -- often MPLS -- and let it take over routing, as well as virtualization, duties. They can fold in existing or new backup links to provide active-active, resilient connections with significant bandwidth increases.

Many organizations work with subsets of sites initially, usually in the same region, and use them as test sites to define appropriate traffic classes and site-based policy groups. Most also enable direct access to select internet destinations from these branches, essentially setting up virtual WANs per sanctioned cloud platform. These often become the most important virtual WANs because the majority of WAN traffic touches outside the network, whether it originates from or ends up in those external environments.