Free DownloadWhat is network virtualization? Everything you need to know
Network virtualization doesn't require admins to manually configure hardware to instantiate the virtual networks, so teams can spin up logical networks more quickly in response to business requirements. These factors and more have spurred the adoption of network virtualization within enterprise and carrier networks. Explore more about the associated benefits and challenges of network virtualization, how it works and the different types.
What software-defined LAN means for campus virtualization
LAN virtualization has long encompassed VLANs to segment network traffic. But software-defined LAN is emerging with zero-trust strategies to provide more comprehensive security.
Software-defined LAN, or SD-LAN, is nothing more -- and nothing less -- than the application of software-defined networking principles to the non-data center LAN.
Those principles include the separation of the logical control of a network -- the specification of the policies that govern what talks to what -- from the actual shuffling of packets from place to place. In practice, this means a control plane -- a management platform that runs on a VM or in a cloud -- directs the activities of a network or forwarding data plane, which is mostly physical and virtual switches. Generally, the control plane has APIs that enable automation to programmatically control network policies.
The separation of logical and data planes supports LAN virtualization in new and exciting ways. It's important to remember, though, that this isn't the first time IT has virtualized the LAN.
Before SD-LAN, take 1: Virtual LANs
Virtual LANs (VLANs) have been around for decades and have been commonly used in the campus LAN for almost as long. Network engineers have long implemented VLANs to segment the network at Layer 2. For example, systems connected through ports on one VLAN cannot directly talk to ports on other VLANs, instead accessing them via a router or firewall.
VLANs create separate network domains that overlay multiple logical LANs on top of a common physical network. Network teams can use VLANs to segregate traffic in the following ways:
for different departments;
for different classes of device, such as IP phone VoIP traffic; or
for different security domains, such as a VLAN for traffic associated with network management.
VLANs paved the way for SD-LAN by breaking the tight coupling between network use and network infrastructure.
SD-LAN
VLANs are a Layer 2 mechanism fully embodied in Ethernet frame headers and implemented at a switch port level. SD-LAN generalizes the idea so it doesn't depend solely on Ethernet or other Layer 2 protocols. It virtualizes the LAN completely so that policy control is lifted off the switches, leaving behind only enforcement.
A fully realized SD-LAN system looks at criteria beyond Layer 2 to make decisions about access and visibility. It should take into account the user, process, program and device identity, for example. It might also consider IP addresses, device location and even time of day. Whichever factors the system supports, network engineers can use them to define policies that govern access to the data network and the scope of allowed activities for network nodes.
The most exciting aspect of SD-LAN currently is its utility for implementing a zero-trust network access architecture.
Zero trust, SDP and the SD-LAN
The most exciting aspect of SD-LAN currently is its utility for implementing a zero-trust network access (ZTNA) architecture. With a comprehensive SD-LAN strategy, the basic zero-trust approach to block everything except what is explicitly allowed can be implemented at the campus network level. That is, the SD-LAN can serve as the campus face of the software-defined perimeter (SDP).
With a zero-trust policy in place, an SD-LAN would, by default, prevent most lateral network traffic, such as laptop A talking to laptop B. That would, in turn, prevent a vast array of malware from spreading within an environment from a compromised device.
Take, for example, the now sadly classic scenario of a bad actor using corrupt IoT devices as platforms to attack workstations. SD-LAN stops that process. Those corrupted wall clocks or vending machines can only see and communicate with their management workstation, not an entire network segment. They might not even be able to compromise that management workstation, if the ports, protocols or volumes of traffic involved in the attack broke any access rules governing the connection.
The benefits of SD-LAN
SD-LAN has a number of upsides. Operationally, the presence of a controller with APIs creates the potential for broader and more effective automation of LAN operations.
Improved management extends to better ability to discover, map out and audit the current state of the network. For example, network teams can track what's on the network, how each entity is behaving and what has deviated from policy.
And, as indicated by the potential for implementing zero trust, SD-LAN offers the ability to greatly improve the basic security posture of enterprise networks. Notable improvements are possible even if an organization doesn't push all the way to zero trust.
The challenges of SD-LAN
Challenges abound with SD-LAN as well. Some of those challenges include the following:
the ability to harness existing infrastructure in the scheme to implement SD-LAN;
the expense of upgrading anything that can't be properly incorporated; and
finding the staff time to redevelop core skills and harness all the potential of SD-LAN.
And, as with a more general zero-trust strategy, when pursuing ZTNA in the campus network, the key challenge for most organizations is understanding what policies to implement -- what needs to talk to what.
As enterprises begin a broad shift toward greater network automation and tighter security, SD-LAN will be an increasingly important tool in advancing enterprises' goals.
