Implementing Ethernet VLANs for CCNA 200-301: Configuration, Trunking, and Troubleshooting

Brandon Eskew -

Introduction: Why VLANs Matter

VLANs matter because they let you take one physical switching fabric and carve it up into multiple logical Layer 2 networks. In practice, that’s huge. In CCNA terms, that means you’re creating separate broadcast domains, which is the key idea you’ve really got to lock in. In the real world, it means HR, engineering, voice, guest, cameras, printers, and management traffic don’t all end up jammed into one noisy flat network. And trust me, that’s a blessing.

That kind of separation gives you way more control, keeps broadcasts from wandering all over the place, and cuts down the damage when somebody plugs into the wrong port or a device starts blasting traffic like it’s gone off the rails. VLANs show up all the time on CCNA 200-301 because they live right in that awkward space between switching and routing, and honestly, that’s where a lot of candidates start to slip. If you don’t really understand access ports, trunks, 802.1Q tagging, native VLANs, and inter-VLAN routing, VLAN questions can turn ugly fast. Seriously.

VLAN Fundamentals

A VLAN, or Virtual LAN, is basically a logical Layer 2 segment. There’s nothing magic about it. Each VLAN is its own broadcast domain, so think of it like a separate little neighborhood living on the same switch. If a broadcast goes out in VLAN 10, it stays in VLAN 10 — it doesn’t spill over into the other VLANs. It doesn’t wander over into VLAN 20 looking for trouble. That’s the core behavior you want burned into your brain.

And just to keep the terminology straight, VLANs aren’t collision domains. On modern switched Ethernet, each full-duplex switch port is effectively its own collision domain anyway, so VLANs aren’t solving that problem. The exam likes that distinction.

Switches don’t just learn MAC addresses — they also keep track of which VLAN each one was learned in. In practice, the switch stores the MAC address and VLAN ID as a pair, so the same MAC can absolutely appear more than once if it’s learned in different VLANs. Unknown unicast and broadcast traffic only gets flooded within that VLAN, unless you’ve configured something like suppression or storm-control to change that behavior.

In normal enterprise design, one VLAN usually maps to one IP subnet. That’s not some ironclad rule written into the fabric of the universe, but honestly, it’s the cleanest way to run a network. For example, I’d usually map VLAN 10 to something like 192.168.10.0/24 and VLAN 20 to 192.168.20.0/24. That way, your Layer 2 and Layer 3 design stay lined up, and honestly, that makes troubleshooting and day-to-day management a whole lot easier. That alignment isn’t required by the laws of physics or anything, but it’s a smart operational move because your default gateway, DHCP scope, documentation, and troubleshooting all get a lot easier. If you stretch one IP subnet across multiple VLANs, or cram multiple subnets into a single VLAN, you’re basically inviting confusion around ARP, gateway placement, and policy enforcement.

VLAN IDs, Defaults, and a Few Things People Mix Up All the Time

For CCNA, you need to know these Cisco-oriented VLAN ranges:

  • 1-1005 = normal-range VLANs
  • 1006-4094 = extended-range VLANs
  • VLAN 1 = default VLAN on many Cisco switches
  • VLAN 0 and 4095 are reserved and not used as normal user VLANs

Out of the box, a lot of switch ports start life in VLAN 1 until you move them somewhere else yourself. VLAN 1 has also historically been tied to a bunch of default Cisco control-plane behavior, including things like CDP, DTP, PAgP, and VTP depending on the platform and how it’s configured. That’s one reason I’d definitely avoid using VLAN 1 for normal user traffic.

Also keep these terms separate:

  • Access VLAN: the VLAN assigned to an access port for normal untagged host traffic
  • Native VLAN: on an 802.1Q trunk, the VLAN associated with untagged ingress traffic and whose egress traffic is untagged by default
  • Management VLAN: a design choice, usually the VLAN that carries the switch SVI used for in-band management
  • Voice VLAN: a VLAN used by an IP phone on a host-facing access port

Access Ports, Trunks, and 802.1Q

An access port carries one VLAN, and it’s usually what you’d plug a PC, printer, camera, or some other end device into. Most hosts send untagged Ethernet frames, and the switch just drops those frames into whatever access VLAN you assigned.

A trunk carries multiple VLANs over one physical link, and you’ll usually see that between switches or between a switch and something like a router, firewall, or access point. VLAN identity is preserved with IEEE 802.1Q tagging, and that’s really the whole point of a trunk.

802.1802.1802.1Q inserts a 4-byte tag into the Ethernet frame. For exam depth, know the main fields:

  • TPID = typically 0x8100, identifies the frame as 802.1Q-tagged
  • PCP = 3-bit priority field for CoS/QoS
  • DEI = drop eligible indicator
  • VLAN ID = 12-bit field carrying the VLAN number

The switch recalculates the FCS as needed when it tags or untags frames. On modern Catalyst platforms, you usually do not configure trunk encapsulation because 802.1Q is the only supported method; older study materials may show switchport trunk encapsulation dot1q.

Native VLAN behavior is important. If an untagged frame shows up on a trunk, the receiving switch treats it as part of the native VLAN. When native VLAN traffic exits a trunk, Cisco switches typically send it untagged by default. Some platforms support tagging the native VLAN with features such as vlan dot1q tag native, but CCNA questions usually assume default untagged native behavior.

A native VLAN mismatch can throw warnings and create some really messy forwarding problems, especially when untagged traffic is part of the picture. If SW1 is using native VLAN 99 and SW2 is still using native VLAN 1, then an untagged frame from SW1 gets interpreted as VLAN 1 on SW2. That won’t necessarily break every frame on the link, but it can absolutely create some confusing symptoms.

DTP and Trunk Negotiation

DTP, or Dynamic Trunking Protocol, is Cisco-proprietary and definitely exam-relevant. Common modes are access, trunk, dynamic desirable, and dynamic auto.

Trunk negotiation outcomes follow a few common patterns:

  • trunk with trunk: trunk forms
  • trunk with dynamic desirable: trunk forms
  • dynamic desirable with dynamic auto: trunk forms
  • dynamic auto with dynamic auto: no trunk forms
  • access with trunk: mismatch; link behavior is wrong for VLAN transit

Operationally, explicit configuration is preferred: set user ports to access, set uplinks to trunk, and disable negotiation where appropriate with switchport nonegotiate on supported platforms, especially toward non-Cisco devices. Avoid trunking to end hosts unless you’ve got a very specific reason to do it.

Configuration Example: VLANs, Access Ports, and Trunks

Lab topology:

PC1 -- SW1 Fa0/1 Gi0/1 ===== trunk ===== Gi0/1 -- SW2 Fa0/1 -- PC2 Fa0/2 -- PC3 In this lab, VLAN 10 represents HR. In this lab, VLAN 20 is the Engineering VLAN. In this lab, VLAN 99 is our native VLAN.

Alright, let’s go ahead and build the VLANs and then set up the access ports.

On SW1, I’d create VLAN 10 first so the switch actually knows it exists instead of just hoping it’ll magically work later. SW1(config-vlan)# name HR SW1(config)# vlan 20 SW1(config-vlan)# name Engineering SW1(config)# vlan 99 SW1(config-vlan)# name Native SW1(config)# interface fa0/1 This puts the interface in normal access mode instead of letting it try to negotiate a trunk. This puts the port into VLAN 10, so untagged traffic from the connected host gets associated with that VLAN. This helps the port move into forwarding quickly, which is exactly what you want on a port connected to an end device. This brings the interface up if it’s administratively shut down. SW2(config)# vlan 10 SW2(config-vlan)# name HR SW2(config)# vlan 20 SW2(config-vlan)# name Engineering SW2(config)# vlan 99 SW2(config-vlan)# name Native SW2(config)# interface fa0/1 SThis makes the port an access port on SW2 as well. This assigns that SW2 port to VLAN 10 for PC2. This speeds up forwarding for the host-facing port, which is the right move for an access port. This makes sure the interface is enabled. SW2(config)# interface fa0/2 SThis makes the port an access port on SW2 as well. This assigns the port to VLAN 20 for PC3. This speeds up forwarding for the host-facing port, which is the right move for an access port. This makes sure the interface is enabled.

Now let’s configure the trunk:

SW1(config)# interface gi0/1 This turns the link into a trunk, so it can carry multiple VLANs between the switches. This sets VLAN 99 as the native VLAN for that trunk. This limits the trunk to VLANs 10, 20, and 99 only. This shuts off DTP negotiation, which is usually a cleaner and safer choice on a static trunk. This brings the interface up if it’s administratively shut down. SW2(config)# interface gi0/1 This configures the SW2 side as a trunk too, so both ends match. This keeps the native VLAN consistent at 99 on SW2. This allows the same VLANs on the SW2 trunk. This disables DTP negotiation on the SW2 side as well. This makes sure the interface is enabled.

Just creating a VLAN on one switch doesn’t mean it’ll magically work everywhere in the network. I’ve seen people assume that way too often, and it bites them. That VLAN has to exist on every switch that needs to forward it, unless you’re using something like VTP to distribute the VLAN database. VTP does exist and it’s still CCNA-relevant conceptually, but a lot of environments prefer transparent or manual administration because accidental VTP changes have historically been painful. Real painful.

If you use EtherChannel for uplinks, set the trunk parameters on the logical Port-Channel interface and keep the member links consistent. If they don’t match, ports can get suspended or fail to bundle at all.

Management VLAN and Voice VLAN Basics

A management VLAN isn’t some protocol-defined special VLAN. It’s simply the VLAN you choose for in-band management. On a Layer 2 switch, that usually means an SVI plus a default gateway:

Here, we’re building the SVI for VLAN 50, which is commonly used for switch management in a lot of labs and small networks. This gives the switch an IP address in VLAN 50 so you can manage it in-band. This brings the interface up if it’s administratively shut down. This tells the Layer 2 switch where to send traffic destined for other networks.

With a voice VLAN, the port still behaves like an access port for the PC, but the phone uses a separate VLAN for voice traffic. Cisco IP phones commonly learn the voice VLAN through CDP or LLDP-MED, tag their voice traffic, and pass the attached PC’s traffic through untagged. The switch maps the untagged PC traffic to the access VLAN and the tagged phone traffic to the voice VLAN.

interface fa0/10 switchport mode access switchport access vlan 10 switchport voice vlan 30 spanning-tree portfast mls qos trust cos

In production, voice also depends on DHCP, call-control reachability, and often Option 150 or the equivalent platform-specific setting.

Inter-VLAN Routing Basics

If devices are in different VLANs, they need Layer 3 routing before they can talk to each other. Layer 2 switching by itself just won’t cut it. Same VLAN means switching. Different VLANs means routing. That’s the rule of thumb.

Router-on-a-stick uses one physical router interface as a trunk with subinterfaces:

First, we move under the physical interface that will carry the trunk. This enables the physical router interface. First, we move under the physical interface that will carry the trunk..10 This tells the router that the subinterface belongs to VLAN 10 and should tag that traffic with 802.1Q. This gives hosts in VLAN 10 their default gateway. First, we move under the physical interface that will carry the trunk..20 This maps that subinterface to VLAN 20. This gives VLAN 20 its gateway address. First, we move under the physical interface that will carry the trunk..99 This sets VLAN 99 as the native VLAN on the router side. This provides the gateway address for the native VLAN.

Multilayer switching uses SVIs and usually requires ip routing:

SW-MLS(config)# ip routing On a multilayer switch, we create an SVI for VLAN 10. This gives the SVI the Layer 3 address that hosts in VLAN 10 use as their default gateway. This brings the VLAN interface up. Now we create the SVI for VLAN 20. This provides the gateway address for VLAN 20. This brings the VLAN interface up.

SVIs must be up/up to route. On a lot of switches, the VLAN has to exist first, and you’ll usually need at least one active port in that VLAN before the SVI fully comes up. If same-VLAN pings work but different-VLAN pings don’t, start looking at the gateways, SVIs, subinterfaces, and routing first instead of randomly changing access VLANs and hoping for the best.

Verification and Troubleshooting

Use a layered troubleshooting workflow: check the physical link first, then the switchport mode, then whether the VLAN exists, then the trunk state, then STP, then MAC learning, and only after that move up to Layer 3.

Key commands:

show vlan brief show interfaces trunk show interfaces switchport show interfaces status show mac address-table show spanning-tree vlan 10 show ip interface brief show logging

Healthy VLAN output:

SW1# show vlan brief VLAN Name Status Ports 1 default active Fa0/2, Fa0/3 10 HR active Fa0/1 20 Engineering active 99 Native active

This proves local VLAN existence and access-port membership. It does not prove the trunk carries VLAN 10.

SW1# show interfaces trunk Port Mode Encapsulation Status Native vlan Gi0/1 on 802.1q trunking 99 Port Vlans allowed on trunk Gi0/1 10,20,99

This proves the port is trunking and which VLANs are allowed. It does not prove hosts are in the right access VLAN or that routing works.

Common failure patterns:

  • VLAN exists locally but not across switches: trunk missing the VLAN from the allowed list
  • One side trunk, one side access: operational mismatch; traffic fails or lands incorrectly
  • Native VLAN mismatch: warnings in logs or CDP, odd untagged traffic behavior
  • SVI down: VLAN interface configured but line protocol down because the VLAN has no active member port
  • Wrong default gateway: same-VLAN traffic works, inter-VLAN traffic fails
  • STP blocking: trunk is up, but a VLAN may not forward on that path
  • Err-disabled port: interface looks dead because of a protection feature

Example of a trunk problem:

SW1# show interfaces trunk Port Vlans allowed on trunk Gi0/1 20,99

If PC1 and PC2 are both supposed to be in VLAN 10 on different switches, that output tells you exactly why they can’t talk. The fix is to allow VLAN 10 on the trunk at both ends.

For STP, keep in mind that Cisco campus networks commonly use PVST+, Rapid PVST+, or MST, depending on the design.VST+, or MST. PVST+ and Rapid PVST+ maintain a separate STP instance for each VLAN, while MST maps multiple VLANs to shared instances. A trunk can be up and still not forward a given VLAN because of STP state.

Security and Design Best Practices

VLANs provide segmentation, not full security isolation. Harden the design:

  • Avoid VLAN 1 for user traffic
  • Use a non-default native VLAN and make sure it matches on both ends
  • Restrict allowed VLANs on trunks
  • Force user-facing ports to access mode
  • Disable DTP where appropriate with switchport nonegotiate
  • Shut down unused ports and place them in an unused VLAN
  • Use PortFast and BPDU Guard on access ports where it makes sense
  • Think about port security, DHCP snooping, and Dynamic ARP Inspection as nearby campus protections that complement VLAN design

interface range fa0/20-24 switchport mode access switchport access vlan 999 shutdown

Be aware of VLAN hopping as a historical security concept. The practical mitigations are the same hardening steps I just mentioned: don’t leave user ports negotiating trunks, don’t use VLAN 1 casually, and don’t leave unnecessary trunks hanging around.

From an operations standpoint, keep VLANs aligned with purpose and subnetting. Separate user, voice, guest, printer, camera, and management traffic where it makes sense. Don’t build giant Layer 2 domains unless you’ve got a good reason; bigger VLANs mean more ARP and broadcast noise, plus a larger failure domain when something goes sideways.

CCNA Exam Traps and Quick Review

These are the classic gotchas:

  • Seeing VLAN 10 in show vlan brief does not prove VLAN 10 crosses the trunk
  • If hosts in the same VLAN on different switches can’t communicate, the problem usually points to trunking, allowed VLANs, STP, or a bad access-port assignment.
  • If hosts in different VLANs can’t communicate, the issue usually points to missing Layer 3 routing or a wrong default gateway
  • Native VLAN traffic is untagged by default on 802.1Q trunks
  • dynamic auto plus dynamic auto does not form a trunk
  • The management VLAN is not automatically the native VLAN

This topic lines up directly with the CCNA 200-301 objectives around configuring and verifying VLANs, access ports, trunks, and basic inter-VLAN communication.

Final takeaway: access ports carry one VLAN, trunks carry multiple VLANs, 802.1Q preserves VLAN identity, native VLAN settings have to match, VLANs have to exist on the switches that forward them, and different VLANs need Layer 3 routing. If you can read the show commands, figure out whether the problem lives at Layer 2 or Layer 3, and understand what a trunk is actually carrying, you’re in pretty good shape for both the exam and the real network.