Virtual Local Area Networks (VLANs, for short) may sound daunting to a sysadmin without any prior network experience. However, they’re pretty simple bits of network configuration that allow you to more efficiently use your network hardware resources. All but the smallest networks are typically split into VLANs, and understanding how to properly configure and troubleshoot them can save you hours of back-and-forth with your network team. I begin this article with a foundational knowledge of VLANs, so by the end, you should be pretty comfortable with VLAN fundamentals.
I'll take a moment to refresh your knowledge of networking basics. In particular, I'll review the concept of a broadcast domain. Then, I’ll discuss what exactly a VLAN is.
Broadcast domain basics
A broadcast domain is a network segment where hosts can send broadcast frames to each other. In the case of an Ethernet network, the broadcast address is FF:FF:FF:FF:FF:FF. Ethernet frames sent to this address will be sent to all hosts on the local network.
Generally, most networks ensure that their broadcast domains and IP subnets match up, although this isn’t a technical limitation. For example, a subnet of 192.168.1.0/24 will correspond to a single broadcast domain at the Ethernet level. It’s generally a best practice to keep your broadcast domains and subnets small (e.g., a /24 network) because this setup ensures that lots of broadcast traffic (such as ARP) isn’t tying up all of your bandwidth.
A basic, unmanaged switch (like the one in your home router) without any VLAN support will only have one broadcast domain. Such a simple network would look something like this:
Network symbols provided by the LibreOffice VRT Network Equipment extension.
All of the hosts on this network will be able to talk to each other at layer two (the data link layer). If a third host is added to the network and begins to send broadcast traffic, then this traffic will be received by the other two hosts that are currently in the diagram. This might be fine for a small office or home network, but over time your network will invariably grow and you’ll want more subnets (and with that, more broadcast domains). You can imagine a network growing to look like the one below:
Network symbols provided by the LibreOffice VRT Network Equipment extension.
VLAN basics
This is where VLANs come in. It wouldn’t make sense for you to buy a single switch for each subnet (as in the above diagram), as that option would be expensive and inflexible. VLANs allow you to create virtual broadcast domains. Your network engineering team can create a VLAN on a switch, and then configure a network port for the appropriate access. Only hosts on the same VLAN would be able to talk to each other directly at layer two. A network with VLANs might look something like the diagram below:
Network symbols provided by the LibreOffice VRT Network Equipment extension.
VLANs are created on the switch, and then the switch ports that connect to hosts (or other switches) must be configured to support VLANs. Switch ports are usually considered either access ports or trunk ports.
Access ports are used for hosts that only need to connect to a single, logical network, and are assigned to a single VLAN. For example, end-user PCs typically have no reason to access VLANs other than their designated client network. However, certain hosts (or other switches) may need access to multiple VLANs on the same connection. This is where trunk ports come in.
A trunk port can carry multiple VLANs on a single port. Trunks do this via the IEEE 802.1Q protocol, which adds a special 802.1Q header to the Ethernet frame. This header provides the numeric VLAN ID to the connected device, allowing for the frames to be differentiated by VLAN when they are received, as seen here:
Source: Wikipedia
When might you encounter trunk ports? The most common use for trunk ports in simple networks is for connecting multiple switches together. You might have several switches in your network, and they may all have some of the same VLANs. Your network team needs a way to span these VLANs across many switches, so they may use trunk ports to accomplish this, as seen below:
Network symbols provided by the LibreOffice VRT Network Equipment extension.
Another use case that may be more familiar to sysadmins is for hypervisor connectivity. In more complex networks, a hypervisor may need to support virtual machines on many different logical networks (VLANs and IP subnets). In order to support connectivity to all of these networks, the network port connected to your hypervisor will likely be a trunk port, and you need to create multiple, logical VLAN interfaces to support the VLANs carried by the trunk.
One other concept about trunking that you may come across is the idea of a native VLAN. A native VLAN is carried on the trunk without a VLAN tag. Therefore, the end host doesn’t need any special configuration to begin using the native VLAN. You would just configure a network port like any other network port, and away you go.
Native VLANs are useful for management purposes because they don’t require any special configuration to use. For example, your hypervisor may come online and obtain an IP address through DHCP (e.g., via a static DHCP reservation) without any additional configuration. You can then log into the hypervisor via its management IP to configure all of the VLANs that you need.
Wrapping up
VLANs might seem complex to the network-uninitiated, but they’re just a simple way of dividing switches into multiple broadcast domains (and typically, IP subnets) for increased efficiency. Small networks may never move beyond a few VLANs, while complex data centers may have hundreds. In both cases, having a basic understanding of how to configure and troubleshoot VLANs can help you to more quickly isolate problems in your network and work toward the right resolution.
In the next article in our series, we'll discuss how to learn how to configure your VLANs on Red Hat Enterprise Linux. Check back soon.
[Need more on networking? Download the Linux networking cheat sheet.]
About the author
Anthony Critelli is a Linux systems engineer with interests in automation, containerization, tracing, and performance. He started his professional career as a network engineer and eventually made the switch to the Linux systems side of IT. He holds a B.S. and an M.S. from the Rochester Institute of Technology.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit