VLAN configuration is the method I use to isolate network traffic by dividing a single physical switch into multiple logical broadcast domains. Instead of buying separate switches for every department or server group, I assign VLAN IDs to ports and let the switch silicon handle the separation. Done correctly, VLAN segmentation improves both security and performance — guests can't reach production databases, and broadcast storms stay contained. Done poorly, you get silent packet drops, mismatched native VLANs, and 2 AM phone calls. Here's how I configure VLANs and trunk ports in production, plus the mistakes I see most often.
Why VLAN Segmentation Matters for Security and Performance
In my environment, flat networks are a liability. When every device sits in the same broadcast domain, a single compromised host can ARP-spoof the entire subnet, and a broadcast storm from one misconfigured NIC takes down everything. VLAN segmentation fixes this by creating boundaries that the switch enforces at Layer 2.
The security benefit is straightforward: a web server in VLAN 10 cannot talk to a database in VLAN 30 unless I explicitly permit it through a router or firewall. Inter-VLAN routing becomes a policy enforcement point, not just a connectivity path.
The performance side is just as real. Broadcast traffic — ARP, DHCP, mDNS, NetBIOS — stays inside its VLAN. On a 200-host flat network, that noise adds up. Split into four VLANs of 50 hosts each, and every segment gets a quieter, more predictable network.
Access Ports vs Trunk Ports: Getting the Basics Right
This is where most people trip up on their first VLAN deployment. There are two port modes you need to understand:
- Access port — belongs to exactly one VLAN. End devices plug in here. The switch strips the VLAN tag on egress toward the host, so the host never sees 802.1Q tagging.
- Trunk port — carries multiple VLANs between switches or from a switch to a router/firewall. Frames are tagged with 802.1Q headers so the receiving device knows which VLAN each frame belongs to.
The classic mistake: plugging an end host into a trunk port and wondering why it gets an IP from the wrong VLAN or no IP at all. Or worse — plugging a switch-to-switch link into access ports and watching only one VLAN pass traffic.
Step-by-Step: Configuring VLANs on a Cisco Switch
Here's a practical configuration I deploy in production. The scenario: three VLANs — management (10), servers (20), and guest (30) — with a trunk link to the firewall for inter-VLAN routing.
First, create the VLANs and name them:
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name MANAGEMENT
Switch(config-vlan)# vlan 20
Switch(config-vlan)# name SERVERS
Switch(config-vlan)# vlan 30
Switch(config-vlan)# name GUEST
Switch(config-vlan)# exit
Then assign access ports to end devices. Port Gig1/0/1 goes to a management workstation:
Switch(config)# interface gigabitethernet 1/0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# spanning-tree portfast
Switch(config-if)# exit
I always set switchport mode access explicitly on end-user ports. Leaving it in dynamic negotiation mode (dynamic desirable or dynamic auto) is a security risk — a rogue device can negotiate a trunk and receive all VLAN traffic.
Trunk Port Configuration for Switch-to-Switch Links
The uplink to the firewall or core switch needs to carry all three VLANs. Here's how I configure the trunk:
Switch(config)# interface gigabitethernet 1/0/24
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan 10,20,30
Switch(config-if)# switchport trunk native vlan 999
Switch(config-if)# exit
A few things worth explaining:
switchport trunk allowed vlan 10,20,30— only permit the VLANs that need to cross this link. I never leave a trunk allowing all VLANs (1-4094) in production. If someone creates a new VLAN on the core switch, it shouldn't automatically appear on every edge switch.switchport trunk native vlan 999— the native VLAN is the one that gets sent untagged on a trunk. I set it to an unused VLAN (999) by default. This prevents a classic attack called VLAN hopping, where an attacker sends untagged traffic that lands in the native VLAN — which, if left at the default VLAN 1, often has broad access.
Note: On some platforms, switchport trunk encapsulation dot1q is not needed because ISL is no longer supported. Modern Cisco switches default to 802.1Q.
Common VLAN Misconfigurations I See in the Field
I've cleaned up a lot of broken VLAN setups over the years. These are the recurring problems:
- Native VLAN mismatch — one side of the trunk has native VLAN 1, the other has 999. You'll see CDP/LLDP native VLAN mismatch warnings and untagged traffic gets dropped or lands in the wrong place. Check both sides.
- Forgetting to create the VLAN in the VLAN database — you assign
switchport access vlan 50to a port, but VLAN 50 doesn't exist on the switch. The port goes into a suspended state. Runshow vlan briefto verify the VLAN exists. - Trunk allowing all VLANs — convenient in the lab, dangerous in production. I've seen a misconfigured server NIC flood every VLAN with multicast traffic because the trunk was wide open.
- No inter-VLAN routing control — if you just enable routing on the switch (
ip routing) without ACLs, every VLAN can talk to every other VLAN. That defeats the purpose of segmentation. Route through a firewall and write actual policies. - VLAN 1 in use — VLAN 1 is the default and every management protocol (CDP, VTP, STP) runs on it. I move management to a dedicated VLAN and avoid using VLAN 1 for anything.
Verifying Your VLAN Configuration
After deploying, I always verify with these commands before walking away:
Switch# show vlan brief
Switch# show interfaces trunk
Switch# show interfaces gigabitethernet 1/0/24 switchport
show vlan brief confirms the VLANs exist and which ports are assigned. show interfaces trunk shows active trunks, their allowed VLANs, and native VLAN — this is where I catch most mismatches. show interfaces <port> switchport gives you the full picture of one port's configuration: mode, access VLAN, trunk native VLAN, and tagging status.
If traffic isn't flowing between VLANs, check three things in order:
- The VLAN exists on both switches (
show vlan brief) - The trunk allows that VLAN (
show interfaces trunk) - The router or firewall has an interface in that VLAN and the correct gateway IP
Final Thoughts
VLAN segmentation is one of those fundamentals that pays off every single day — fewer broadcast storms, clearer security boundaries, and easier troubleshooting when something breaks. The configuration itself is simple once you understand access vs trunk ports and the native VLAN trap. The discipline is in the details: restrict allowed VLANs, avoid VLAN 1, route through a firewall, and verify before you leave.
If you're dealing with broader network performance issues beyond segmentation, as I mentioned before in a previous post about finding the real cause of network slowness (https://furkanikkan.com/urun/ag-yavasliginin-gercek-nedenini-bulmanin-7-yolu-50), VLAN configuration is often step one — isolate the traffic first, then measure. It's hard to fix what you can't segment.
Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line
