The idea of a VLAN, or Virtual Local Area Network, is simple enough, right? It’s hard to imagine any work in a modern networking/IT space without having encountered, set up, or managed a VLAN. Well if that’s all you needed to know about VLANs, we’d be done here, but there’s a bit more to it.

To cover our bases: In most modern networks the primary purpose of the LAN is to provide connectivity to a wider network, most notably the internet. When you think about all of the devices that you need to connect to your network today, the list can get quite long: laptops, servers, storage, mobile phones, IoT devices, security cameras… And that’s just the start.

This poses a potential issue. Do you really want all of these devices on the same LAN— all having equal access to the same set of resources? Should the IoT devices on my network, known to run rudimentary operating systems and to be susceptible to security vulnerabilities, reside on the same network as the laptops used by finance? And should those devices share a network with employees’ mobile phones?

Of course not!

The obvious solution is to start segmenting the network. This could mean running separate cables, separate switches, access point infrastructure, and more, to create separate local area networks for each device group. But that’s a lot of extra work, it’s expensive, inefficient, and complex to manage.

How does a VLAN work?

Network engineers realized this a long time ago, too. A simpler way to solve this problem is to logically segment the same physical network. The most basic way to do that is to create virtual local area networks or VLANs. Instead of running separate cables, having separate switches, etc. for each local area network, VLANs on your network use the same underlying physical infrastructure but create separate spaces for the traffic of different types. Although traffic traversing your network at Layer 2 will use the same physical switches and cables, traffic within each VLAN stays within its own specific compartment.

Let’s look at a practical example. Say you have a switch with eight ports. You’ve configured two separate VLANs on the switch – VLAN 100 and VLAN 200 – and connected three PCs to three neighboring switch ports. Since Devices A and B are in the same VLAN, they would generally be able to communicate with one another over Layer 2. Although it may seem like PCs B and C are neighbors, they are in separate VLANs— they have no direct links to each other at Layer 2. Instead, they’d need to rely on higher-level protocols in the OSI model, such as Layer 3 (the Network Layer) to communicate.

 

VLANs and broadcast domains

If you’re familiar with VLANs from prior experience and are just here for a refresher, you may be thinking “This isn’t quite what I learned in school!” – and you’d be right. While I’ve described the typical reason VLANs are used in most small to mid-sized networks today, let’s not forget about the original reason VLANs were introduced. The original purpose of VLANs was to reduce the size of the broadcast domain, therefore decreasing the amount of bandwidth being effectively wasted with broadcast traffic. Along with spanning trees, the goal was to reduce or eliminate broadcast storms.

Back to the example above. PCs A and B are in the same broadcast domain, so any broadcast traffic sent by device A is seen by device B. PC C is in a different broadcast domain, so if A is transmitting broadcast traffic, PC C won’t receive it. Prior to the introduction of VLANs, any devices connected to the same switch would see all broadcast traffic from each device within that LAN. And that can be a lot of traffic being processed by endpoints that don’t need to.

While these original concepts still apply, they are cited far less often as a reason to introduce VLANs into a network, since high broadcast traffic and broadcast storms don’t occur very often in a well-designed network.

 

 


If you’re looking for a way to get better visibility into how your network is connected both logically and physically, try Auvik risk-free for 14 days today. You’ll have a complete network map, showing all of your VLANs, in less time than it takes to grab lunch.

Steve Petryschuk

About Steve Petryschuk

As Auvik’s Product Strategy Director, Steve works with prospects, clients, and the IT community at large to identify, research, and analyze complex IT Operations challenges, helping guide the Auvik roadmap to better serve the IT community. Steve holds a Bachelor of Engineering and Management and is a registered Professional Engineer in Ontario with IT, networking, and IT security experience spanning product management, DevOps, systems admin, solutions engineer, and technical trainer roles.


Leave a comment

Got something to say? Name and email are required, but don't worry, we won't publish your email address.

*