Demystifying network switches and VLANs for DevOps. Learn the difference between access and trunk ports to fix common network segmentation and connectivity issues for good.

I Hear You’re Confused About VLANs. Let’s Fix That.

I remember it like it was yesterday. 2 AM. The on-call phone screams. Production is down. Not slow, not flapping—down. We spent three hours chasing ghosts in Kubernetes pods and application logs, only to find the root cause was a junior network admin who changed a single switch port from ‘trunk’ to ‘access’ during a ‘cleanup’. One little keyword change, and our entire VM cluster was firewalled from its own storage. That’s when I learned: you don’t have to be a network engineer, but you damn well better understand how the network sees your servers.

The “Why”: It’s All About Tagging Your Traffic

Let’s get this straight. A switch isn’t magic. It’s a bouncer at a club with multiple VIP rooms (VLANs). The bouncer’s job is to look at everyone’s ticket (the network packet) and make sure they only go to the room they’re allowed in. The confusion starts with how the tickets are marked.

• Untagged Traffic: This is like a local who doesn’t need a ticket. The bouncer (the switch port) is told, “Anyone who shows up here without a ticket goes straight to the ‘General Admission’ room (a single VLAN).” This is what an Access Port does.
• Tagged Traffic: This is for VIPs with special wristbands. The packet arrives with a digital ‘tag’ (an 802.1Q tag) that says “I belong in VLAN 10” or “I belong in VLAN 20”. The bouncer on a Trunk Port is trained to look for these tags and route the person to the correct VIP room.

The problem always, and I mean always, comes down to a mismatch. Your server is sending tagged traffic, but the switch port is configured as an access port expecting untagged traffic. Or vice-versa. The bouncer sees the wrong kind of ticket and just drops the packet on the floor. No error message, no warning. Just silence.

The Solutions: From Simple to Server-Side

Alright, enough theory. Let’s get our hands dirty. Here are the three ways we handle this in the real world at TechResolve.

1. The ‘Set It and Forget It’ Fix: The Access Port

This is your bread and butter for any single-purpose machine. A physical database server, an appliance, a workstation. The machine itself doesn’t know or care about VLANs; it just needs to be on one network. You tell the switch port which VLAN to assign all traffic to.

Use Case: You’re plugging in a new database server, prod-db-01, that needs to be on the secure database network, VLAN 50.

The Fix (Cisco-ish Switch Config):

interface GigabitEthernet1/0/5
 description "Connection to prod-db-01"
 switchport mode access
 switchport access vlan 50
 spanning-tree portfast
!

Darian’s Pro Tip: This is the simplest and most secure setup for a single device. Ninety percent of your physical server connections should look like this. Don’t overcomplicate things by trying to make the server’s network card VLAN-aware if it doesn’t need to be.

2. The ‘Grown-Up’ Fix: The Trunk Port

This is for the big leagues. You use a trunk port when one physical cable needs to carry traffic for multiple VLANs. The classic examples are connecting two switches together or, more relevant for us in DevOps, connecting a hypervisor (like ESXi/Proxmox) or a Kubernetes worker node to the network.

Use Case: Your new hypervisor, kvm-host-03, will host VMs for Production (VLAN 10), Development (VLAN 20), and Management (VLAN 99). All that traffic must go through one network cable.

The Fix (Cisco-ish Switch Config):

interface TenGigabitEthernet1/0/1
 description "Uplink to kvm-host-03"
 switchport mode trunk
 switchport trunk allowed vlan 10,20,99
!

Warning: Be very careful with the concept of a ‘Native VLAN’ on a trunk. This is an untagged VLAN allowed on a trunk port, and it’s a frequent source of misconfigurations and security vulnerabilities. My opinion? Unless you have a specific, legacy reason to use it, block it or set it to an unused VLAN. Don’t mix tagged and untagged traffic on a trunk if you can avoid it.

3. The ‘DevOps’ Fix: When Your Server Becomes the Switch

This is where the lines blur and where most of the Reddit confusion comes from. When you configure a trunk port to your server, the switch’s job is done. It’s now up to the server’s operating system to handle those VLAN tags. Linux, for example, does this by creating virtual sub-interfaces for each VLAN.

Use Case: On kvm-host-03 (which is connected to the trunk port from the last example), you need to create a new container that lives exclusively on the Development network (VLAN 20).

The Fix (Linux Command Line): You create a virtual interface ‘tagged’ for VLAN 20 on top of your main physical interface (e.g., eno1).

# Create a virtual interface tied to eno1 for VLAN 20
$ ip link add link eno1 name eno1.20 type vlan id 20

# Bring the new interface up
$ ip link set up dev eno1.20

# Now, when you assign this interface (eno1.20) to your VM or container,
# any traffic leaving it will be automatically tagged for VLAN 20 by the Linux kernel.

Here’s how the pieces fit together:

So, next time you can’t ping your new instance, don’t just blame the firewall. Take a deep breath and ask: “Am I talking tagged or untagged, and does the switch port agree with me?” Getting that right will save you from a 2 AM phone call. Trust me.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions