5 big misconceptions about virtual LANs
- select the contributor at the end of the page -
Imagine you’re in an interview with a hiring manager and they ask you to define a VLAN. It sounds like a simple question with a straightforward, technical answer. Wanting to be specific, you might answer, “An Ethernet VLAN is an arbitrarily defined broadcast domain, and a broadcast domain is a collection of devices that can communicate at layer 2 (L2) using only their MAC addresses.” A technical hiring manager should give you big points for such an answer—after all, it’s detailed and correct. But let's be honest, it’s also flat and academic. Rattling off an important concept doesn’t really gauge your understanding, let alone whether you can do the job.
In the real world, VLANs are anything but simple
Suppose that the manager then asks how you would use a VLAN. This question, while on the same topic, is an entirely different beast because it requires you to discuss how to practically use VLANs in a particular context. You might answer by detailing how to use them to increase security. Or you might discuss creating a voice VLAN to carry voice-over-IP (VoIP) traffic. Or you could get really elaborate and talk about extending an existing VLAN into a new suite using 802.1Q trunks.
While the concept of a VLAN is easy to grasp in theory, pinning it down to specific, real world use-cases can be tricky. Unless you have a solid grasp of how VLANs practically relate to other concepts and technologies, explaining to a hiring manager how you would use a VLAN will expose any gaps or misconceptions in your understanding of VLANs.
Over the years, I’ve noticed five common misconceptions IT professionals have about VLANs. And all too often, I’ve heard these misconceptions uttered in job interviews. I’ve also talked with people who failed Cisco CCNA/CCNP certification exams because of this. I don’t want either of those things to happen to you, so I’m going to take this opportunity to detail not just what these misconceptions are, but why they’re wrong. I’ll also give you key takeaways from each misconception that you can apply immediately. So, let’s dive in.
Misconception No. 5: A VLAN is always associated with only one subnet
IT folks often talk about VLANs in terms of subnets. For example, if a server has an IP address of 192.168.55.12/24, someone might say, “192.168.55.12 is in VLAN 550.” This isn’t technically incorrect. That server might well be a member of VLAN 550. But it’s easy to make the inference that the 192.168.55.0/24 subnet somehow is equivalent to VLAN 550. After all, most of us think in terms of IP addresses, not MAC addresses.
The fact is that a VLAN can be associated with many subnets or no subnet at all. It’s common for some organizations to reserve VLAN 1 for L2-only protocols like Cisco Discovery Protocol (CDP) and Unidirectional Link Detection (UDLD). It’s less common, but still possible, to have multiple subnets in a single VLAN. For instance, on a layer-3 (L3) switch you can create a switched virtual interface (SVI) in VLAN 300 with the IP 10.3.3.1/24 and subsequently give that same SVI a secondary IP of 192.168.3.1/24 using the commands:
interface Vlan300
ip address 192.168.3.1 255.255.255.0
ip address 10.3.3.1 255.255.255.0 secondary
Both subnets would then reside in VLAN 300. This would be an unusual setup, and secondary IPs are normally used only temporarily for cleanly transitioning from one subnet to another without disruption. But it’s technically valid.
Takeaway: Your switches won’t warn you if you have multiple subnets using a single VLAN. Never assume a VLAN has only one subnet. When in doubt, do a show run interface Vlan300 on your layer-3 switches to view both the primary and secondary IPs.
Misconception No. 4: Creating and using a new “VLAN” involves just a few commands
This misconception stems from the confusion that arises when you use the terms “VLAN” and “subnet” interchangeably. It certainly is possible to create and use a new VLAN with just a few commands. But most of the time, when you create a new VLAN, what you’re really trying to do is create a new subnet.
Suppose you want to create VLAN 700 for the new subnet 172.30.7.0/24. Naturally, you first create a new VLAN to house the new subnet. I wish I could say that’s the easy part, but even the act of creating a new VLAN can be complicated if you have a lot of switches. You have to manually touch each switch that will carry traffic for the VLAN, and create an entry for VLAN 700 in the VLAN database. Even if you decide to automate this process a bit by using the VLAN Trunking Protocol (VTP), you still have some work to do.
The next step is to ensure that the new VLAN 700 is allowed on the trunk links between your switches. There are two ways a VLAN would get removed or pruned from a trunk. If you’re using VTP and have enabled VTP pruning, the new VLAN will get pruned from any trunk links going to switches where there’s not an active interface with membership in VLAN 700. This is to eliminate sending VLAN 700 traffic to switches that don’t need it. Also, the VLAN can get pruned from a trunk if it’s not in the VLAN allowed list.
Once you get your VLANs straight you have to actually create the subnet. This involves setting up a gateway to route traffic between the new subnet and other subnets in your network (you may hear this referred to as, “routing between VLANs,” which as you might expect, is technically correct, but confusing.) You configure an SVI on VLAN 700 and assign it an IP in the new subnet, say 172.30.7.1/24.
You also need a way to assign IP addresses to hosts on the new VLAN. Most likely, you’d already have a DHCP server to dynamically assign addresses from the new subnet. But in order to transport the DHCP broadcasts between the new VLAN and the DHCP server, you have to configure IOS to use DHCP relay or an IP helper address.
Takeaway: Creating a new VLAN to house a new subnet requires planning. Decide in advance what subnet you’ll use and how you’ll assign IP addresses to hosts. Use the following commands to make sure your switches are not pruning your new VLAN:
show interfaces pruning
show interfaces trunk
Misconception No. 3: VLANs are only for large networks
I’ve worked for companies that barely had enough employees to justify a having a switch, let alone multiple VLANs. An organization with 10 employees probably doesn’t need more than a couple of VLANs. But it’s a good idea to plan for growth. If ever you anticipate the need for more than one connected subnet, you’ll likely need to use VLANs. This is especially true if you ever implement Web filtering on a per-subnet basis.
Even in tiny organizations, it’s a good idea to set up a separate VLAN and subnet for guest access that’s isolated from the rest of the production network. This is especially true of nascent organizations that don’t have a well defined information security policy around network access. If your boss brings in her nephew to do homework online, and asks you to connect his laptop to the company network, that would be a good time to have a separate guest VLAN.
Takeaway: Not all switches support VLANs. An unmanaged 8-port switch from the local supermarket isn’t going to cut it. For a small organization, purchasing some inexpensive, used Cisco switches that support VLANs is a far better option.
Misconception No. 2: VLANs provide security
The idea behind this misconception is that traffic from one VLAN can’t cross-over to another VLAN. This bumper-sticker wisdom comes from the loose use of another term; “traffic.” L3 traffic—that is, IP traffic—does pass between VLANs with the help of a router, whether a physical router or a virtual router within a L3 switch. If you need to restrict IP traffic between VLANs, you can use IP access lists or firewalls.
But L2 traffic can’t cross between VLANs, at least it’s not supposed to. To get technical, an Ethernet frame with a particular source and destination address will not pass from one VLAN to another under normal circumstances. Under not-so-normal circumstances, however, L2 traffic can pass between VLANs. Here are a couple of ways this can happen:
- Connecting together two access ports that are in different VLANs. Suppose SW1 has port Ethernet0/1 configured as an access port in VLAN 3, and SW2 has port Ethernet0/2 configured as an access port in VLAN 4. If you connect these two ports together, traffic can cross seamlessly between VLANs 3 and 4.
- Another way this can happen is by changing the native VLAN on only one end of an 802.1Q trunk link. This doesn’t happen by accident. If someone does this maliciously, he would also likely disable CDP to avoid any NATIVE_VLAN_MISMATCH warning messages.
Takeaway: Shut down unused ports and use the Port Security feature to mitigate accidental VLAN crossover. On trunk links, tag all traffic, including the native VLAN, using the global configuration command vlan dot1q tag native
Misconception No. 1: Cisco IP phones use 802.1Q trunks
This misconception is as old as the Cisco IP phone itself, and surprisingly one of the most dangerous.
A Cisco IP phone separates voice and data traffic by tagging voice traffic with an 802.1Q tag that contains the VLAN ID of the voice VLAN. Understandably, many take this to mean that the IP phone must be connected to a switch port that’s configured as an 802.1Q trunk. As a result, it’s been common practice to configure every port connected to an IP phone as an 802.1Q trunk port. While this works and sounds innocent, it’s actually a big security risk.
By default, traffic for all VLANs will traverse the 802.1Q trunk. That means every user with an IP phone has traffic for every single VLAN coming straight to their desk. All it takes for someone to start sniffing sensitive traffic is to plug in a little Ethernet tap and a laptop with Wireshark. But it gets worse.
When a port’s configured as an 802.1Q trunk, it becomes trivial for a person to inject malicious traffic into any VLAN by simply tagging it. This opens the door for ARP spoofing and MAC flood attacks on all VLANs, not just a couple.
To avoid this unnecessary risk, Cisco invented the concept of a multi-VLAN access port, which allows access only to two VLANs: the tagged voice VLAN and the untagged data VLAN. No other VLAN traffic will egress a port set up in this way, and ingress traffic tagged for any other VLAN will get blocked.
Takeaway: Never configure end-user ports as 802.1Q trunks. Instead, configure all end-user ports as access ports using the switchport mode access interface command. For users with IP phones, additionally configure switchport voice vlan x to create a multi-VLAN access port.
Learn all practical applications of VLANs
Having a solid understanding of basic VLAN concepts is a must. But if you’re ready to move beyond the basics, VLANs & Trunking for CCNP Routing & Switching 300-115 SWITCH offers a deep-dive into how to practically use VLANs in a real organizational environment.
