Over the past couple of decades, networking technology has exploded through society like a pack of Mentos shoved into a two-liter bottle of soda. As more and more devices enter the networked world, new ways of organizing and accessing these devices (or preventing their access) have been required to keep it manageable, secure, and running smoothly. One such technology is the Virtual Local Area Network or VLAN for short.
If you head over to Cisco’s website, you’ll find that they have this to say about VLANs:
A [Virtual Local Area Networking (VLAN)] is a group of end stations in a switched network that is logically segmented by function, project team, or application…VLANs have the same attributes as physical LANs, but you can group end stations even if they are not physically located on the same LAN segment.
But… what does that even mean?
In this article, we’ll try to break down what a VLAN is, how they work, and that “gotchas” you should keep in mind when working with them. Implementing them in our own networking stack was an incredible (and somewhat painful) learning experience for us all. We stubbed our toes in a several different ways. This was especially true when it came to testing and debugging, and we’d love to take the opportunity to share some of what we’ve learned with you.
What is VLAN?
A local area network (LAN) is a group of devices that are connected based on the fact that they’re located in the same place (such as a single floor of an office building). Once you’ve got these devices connected (or networked) together, they can share an Internet connection, connect to communal printers, share files with each other, and so on.
As you can probably guess from its name, a virtual local area network is similar to a LAN. What’s the difference? Well, a VLAN allows you to connect devices, even though they aren’t in the same physical location. Conversely, you can also create what looks like distinct networks when you have devices and resources that are located near each other. An essential component of a VLAN is that computers or devices which are not a part of the network are unable to communicate with one another.
Let’s say a small company needs to provide internet access for its accounting, legal, and marketing/sales departments. These departments must be isolated from one another for security and privacy (and possibly even performance) reasons. To that end, the company’s network administrator might create individual VLANs for each department.
In this case, those in accounting might have access to the internet and can share printers and files with others in accounting. That said, they cannot share resources with those in legal or marketing/sales. This is true even if individuals from accounting legal are sitting in desks that are right next to one another. The physical location of the devices themselves doesn’t matter.
How Does It Work?
When you have a physical network that you need divided, you end up with what are called broadcast domains. If you don’t opt to set up virtual local area networks, then you will need to have switches and infrastructure for each individual broadcast domain. That’s a lot of equipment that costs a lot of money, not to mention the time and resources it takes to set up and maintain this stuff.
However, if you opt for VLANs (you’d need one for each domain), you can use one switch that routes network traffic to the appropriate VLAN. Each virtual local area network is identified by what’s called a VLAN ID. So, traffic addressed to VLAN 1 will be accessible to the VLAN 1 ports on the switch, but not any of the ports that are assigned a different VLAN ID.
You’ll also be tagging each port on your switches with one of the following: tagged, untagged, or excluded. With tagged ports, the switch will add the VLAN ID to the header of any packets it sends. Conversely, untagged ports do not do this, and they will potentially remove any VLAN ID in packets that come through. Excluded ports are those that never send packets with VLAN IDs.
Additionally, your network card might allow you to specify a VLAN ID for that specific network interface directly from your computer. One instance where this is helpful is if your switch doesn’t support VLAN tags, or if you need a port to support multiple VLAN IDs. Such switches may simply pass the packets through as-is. In this case, your network interface will check the packets to ensure that they belong to the correct virtual local area network.
Pro TipBe careful that the VLAN ID you’re using matches the port to which you’re connected, or you may be in for some marathon troubleshooting sessions.
What's in a VLAN Packet?
- The destination MAC address – 6 Bytes
- The source MAC address – 6 Bytes
- The packet type (in this case, it’s VLAN: 0x8100) – 2 Bytes
- The VLAN tag – 4 Bytes
- User Data
|Dest MAC||Source MAC||Type||VLAN Tag||User Data|
|6 bytes||6 bytes||2 bytes||4 bytes||varies|
The VLAN tag contains the user’s priority for the packet, a canonical format identifier (CFI), the ID of the VLAN to which the packet belongs, and the Ethernet type/length.
|3 bits||1 bit||12 bits||16 bits|
(Confused by this jargon? See WireShark for additional details!)
Reserved VLAN IDs
Unfortunately, you can’t just use any old number for your ID. Instead, you are limited to a 12-bit field using hexadecimal values that are not reserved. Luckily, the only two that are reserved are 0x000 and 0xFFF, which means you have 4,094 options available. For additional information on see IEEE 802.1Q-2005.
When You Might Find VLAN Helpful
There are a lot of reasons why you might set up a VLAN, including:
- Providing logical groups with resources (like the office scenario we mentioned previously)
- Setting up a guest network so that you can separate such traffic from internal traffic
- Isolate devices and users who require lots of bandwidth (e.g., cameras that are continuously streaming feeds, sales and marketing folks who make a lot of VoIP calls)
However, there are many ways to introduce the logical separation required for the situations we’ve mentioned above. So more specifically, what are the benefits of implementing such use cases? Well, VLANs are helpful for:
- Improving Performance: Isolated traffic means that you’ll see better performance, especially if you isolate high-resource users from everyone else.
- Improving Security: Legal cannot spy on accounting and vice versa.
- Simplifying Network Administration: Logically isolating groups (e.g., based on department) allows you to enforce access policies and the like at a group level.
- Troubleshooting*: Your administrators will find it easier to fix something if the problem is isolated to a smaller area (e.g., the guest network).
* This will be true unless the issue is with the VLAN itself, in which case… see below.
The Trouble with VLANs
There are several upsides to using a VLAN, but there are some downsides to this type of network infrastructure, as well. Some of the ones that you should be aware of include:
Just because you can create a VLAN doesn’t mean that you should. For example, should you really put each office printer on its own VLAN without any other compelling reasons? Complexity can be difficult to manage once you’ve introduced it. Because of this, make sure you have a compelling reason to do so before you start divvying out those VLAN IDs. You might think that creating a VLAN requires just a few commands. However, if you’re implementing network where this technology could be beneficial, you’re going to need a bit of planning before execution.
You’re probably able to tell the difference between your VLANs and your LANs. However, the tools you use for debugging and troubleshooting might not be able to do so. This means that debugging network communications might be problematic when working with VLANs. For example, network interfaces will often strip VLAN specific information out of a packet before passing it to the application. If you use network sniffers/packet analyzers such as Wireshark (like we do), you will be unable to see that data in your captures. Some specific network interfaces provide a workaround by allowing you to set promiscuous mode. This allows the full packages, tags, and all, to be passed along. However, identifying this issue from the get-go can be difficult. Even once it’s identified, there’s still no guarantee that your network card will play nicely and give you what you’re looking for.
It can be harder to get your VLANs functioning correctly with things like virtual machines and switches (i.e., Hyper-V options) than you’d think. This is ironic and can be genuinely infuriating, as every party involved is virtual. Unfortunately, this isn’t an area where we can get prescriptive. Just know that you might be in for some trial and error with regards to settings for your VLAN and virtual switch, as well as the virtual machine itself.
Security (or Not)
One of the biggest reasons for using a VLAN is to introduce security. There are caveats to this, however. For example, L2 traffic (which consists of packets sent to specific switch ports) can cross between LANs in particular cases. This means there’s a connection between two access ports in VLANs or potentially malicious changes to VLANs. The best practice to keep this from happening is to shut down any switch ports that aren’t in use. Additionally, tag all traffic for easy identification and take full advantage of port security features.
Virtual local area networks (VLANs) are powerful, but there are a lot of nuances to consider when setting them up. In addition to evaluating whether this is the right choice for you and your network, you’ll need to make sure that your equipment is VLAN compatible. To that end, NetBurner’s Systems-on-Modules and IoT Development Kits provide built-in support for VLAN in their networking stack. This lets you get your IoT projects going with ease, regardless of the network you’re operating in.
As always, thank you for joining us in our discussion of VLANs. If you have any comments, questions, or VLAN horror stories of your own, please feel free to share in the comments below. Additionally, you can email us directly at firstname.lastname@example.org.