3.4 6 Lab Configure Vlans And Trunking

Imagine you’re sitting in front of a packet tracer topology, three switches blinking like traffic lights, and the lab manual tells you to “configure VLANs and trunking” for the 3.4 6 lab configure vlans and trunking exercise. You’ve read the theory, you’ve seen the diagrams, but now the commands feel like a foreign language. What if I told you the trick isn’t memorizing every line—it’s understanding why each command exists and how the pieces talk to each other? Let’s walk through that lab together, step by step, and turn confusion into confidence.

What Is the 3.4 6 Lab Configure Vlans and Trunking About

This lab is a staple in the CCNA curriculum because it forces you to apply two core switching concepts in a single, interconnected scenario. First, you create VLANs—virtual LANs—to segment broadcast domains on a switch. Second, you set up trunk links so those VLANs can travel between switches without being confined to a single piece of hardware. The topology usually looks like this: Switch 1, Switch 2, and Switch 3 connected in a triangle, with PCs attached to each switch to test connectivity. Plus, your job is to assign the PCs to specific VLANs, create the VLANs on the switches, and then configure the inter‑switch links as 802. 1Q trunks.

Why VLANs Matter in the First Place

Think of a VLAN as a logical fence inside a physical switch. Without it, every device connected to the switch hears every broadcast, which quickly becomes noisy and insecure. Still, by placing devices in different VLANs, you isolate traffic—HR can’t accidentally see finance data, and a misbehaving application in one VLAN won’t flood the whole network. The lab gives you a concrete reason to build those fences: you’ll see PCs in VLAN 10 unable to ping PCs in VLAN 20 until the trunks are properly configured.

What a Trunk Actually Does

A trunk is not a special cable; it’s a regular Ethernet link that carries multiple VLANs simultaneously. That said, it does this by tagging each frame with a VLAN ID (the 802. Worth adding: 1Q header) so the receiving switch knows which VLAN the frame belongs to. If you forget to enable trunking, the link behaves like an access port and drops any tagged frames, leaving your VLANs isolated across switches. The lab makes this visible: after you create the VLANs but before you trunk the links, ping tests fail, and the show interfaces trunk command returns nothing.

How the Lab Works: Configuration Walkthrough

Below is the flow most instructors expect, but I’ll add the little “why” notes that often get skipped in the lab guide.

Step 1: Verify the Starting State

Before you type anything, check what’s already there.

show vlan brief
show interfaces status
show interfaces trunk

You’ll likely see only VLAN 1 (the default) and all ports in access mode. Taking a quick snapshot now saves you from wondering later whether a command actually changed anything Still holds up..

Step 2: Create the VLANs on Each Switch

The lab usually asks for VLAN 10, VLAN 20, and VLAN 30. You can do this globally or per‑switch; I prefer global for consistency.

configure terminal
vlan 10
 name SALES
 exit
vlan 20 MARKETING
 exit
vlan 30 ENGINEERING
 exit
end

Notice the name command—it’s optional but makes the show vlan brief output far more readable. If you skip naming, you’ll see just numbers, which can be confusing when you have more than a handful of VLANs.

Step 3: Assign Access Ports to the Correct VLANs

Now connect the PCs. Suppose PC1 is on Switch 1 Fa0/1 and should be in VLAN 10 Simple, but easy to overlook..

configure terminal
interface fa0/1
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 exit
end

Do the same for the other PCs, adjusting the VLAN ID as the lab specifies. The spanning-tree portfast line isn’t required for the lab to pass, but it prevents the port from going through the listening/learning states, which saves a few seconds during testing.

Step 4: Configure the Trunk Links

Pick the interfaces that connect the switches—often Fa0/24 on each switch. Set them to trunk mode and allow the VLANs you just created.

configure terminal
interface fa0/24
 switchport trunk encapsulation dot1q   # only needed on older switches
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 exit
end

If you’re using a newer switch that auto‑negotiates encapsulation, you can drop the encapsulation line. The key is the allowed vlan statement. By default, a trunk carries all VLANs (1‑4094), but explicitly listing them is a good habit and matches what the lab expects.

Step 5: Verify Your Work

Now run the verification commands again, but focus on the trunk output.

show interfaces trunk
show interfaces fa0/24 switchport
show vlan brief

You should see the trunk status as “trunking,” the native VLAN (usually 1) listed, and the allowed VLANs showing 10,20,30. The show vlan brief will list the ports you assigned as access ports under the correct VLAN IDs Simple, but easy to overlook. That's the whole idea..

Step 6: Test Connectivity

Finally, ping from a PC in VLAN 10 to a PC in VLAN 20. If the trunk is up, you should get replies. If not, double‑check:

• Is the port really in trunk mode? (show interfaces fa0/24 switchport)
• Are the VLANs allowed on the trunk? (show interfaces trunk)
• Did you forget to create the VLAN on the neighboring switch? (VLANs must exist on both ends of a trunk.)

Common Mistakes / What Most People Get Wrong

Even though the lab steps are straightforward, a few slip‑ups trip up almost everyone the first time.

Forgetting to Create the VLAN on Both Switches

It’s easy to create VLAN 10 on Switch 1, assign the access port, and then assume the VLAN magically appears on Switch 2. So naturally, it doesn’t. If VLAN 10 isn’t defined on Switch 2, the trunk will still carry the tag, but the receiving switch has no idea what to do with it, and the frame gets dropped.

Continuing the troubleshooting checklist

If the ping fails, the first thing to verify is that the VLANs are present on both ends of the trunk. A quick show vlan brief on each switch will confirm that VLAN 10, 20, and 30 are listed as active. When a VLAN is missing on one side, the trunk will still negotiate, but the remote switch will discard frames because it has no mapping for that tag That's the part that actually makes a difference..

Another frequent oversight is mismatched native VLANs. And by default, Cisco IOS uses VLAN 1 as the native VLAN on all trunk ports. If you inadvertently configure a different native VLAN on one switch (for example, switchport trunk native vlan 99), frames tagged with the default native VLAN will be sent untagged, while tagged frames from the other side will be dropped. Align the native VLAN on both ends, or explicitly set it to an unused VLAN if you need to keep the default untouched.

Additional pitfalls to watch for

• Incorrect trunk encapsulation – Older Catalyst models require the switchport trunk encapsulation dot1q command, while newer devices auto‑negotiate. If you apply the encapsulation command on a switch that already runs a newer IOS, it can cause a negotiation mismatch, resulting in the trunk staying down. Verify the encapsulation mode with show interfaces trunk and ensure both sides agree The details matter here..

• Speed/duplex mismatches – A trunk operating at 100 Mbps half‑duplex while the connected device runs at 1 Gbps full‑duplex can cause intermittent loss of connectivity. Use show interfaces fa0/24 to confirm that both ends are set to the same speed and duplex settings. If they differ, force the appropriate values with speed and duplex commands.

• Spanning‑tree blocking – Even with portfast on access ports, the trunk ports may be placed in a blocking state by STP if there are redundant links or loops in the topology. Check the STP status with show spanning-tree and look for any ports listed as “Blocking.” If you see the trunk in a blocked state, consider adjusting the priority of the relevant switches or enabling spanning-tree portfast on the trunk only if you are absolutely certain there are no loops.

• VLAN pruning – Some switches automatically prune VLANs that have no active ports, which can remove a VLAN from a trunk if it is not being used on the local device. To prevent this, enable VLAN pruning globally or on the specific interface with no spanning-tree vlan pruning (or the equivalent command on your platform). This ensures the trunk continues to carry all allowed VLANs Easy to understand, harder to ignore..

Best‑practice summary

1. Create each VLAN on every switch before assigning ports.
2. Match native VLANs on both ends of a trunk.
3. Explicitly list allowed VLANs on trunk interfaces; it reduces the chance of accidental VLAN leakage.
4. Confirm speed/duplex consistency across all trunk links.
5. Validate STP convergence to avoid unexpected blocking of trunk ports.
6. Document the VLAN map and the trunk configuration; it makes future troubleshooting far easier.

Conclusion

By systematically assigning each access port to its designated VLAN, establishing trunk links with the correct encapsulation and allowed VLAN list, and then verifying both the configuration and the operational state of the network, you can reliably separate traffic for multiple VLANs while keeping the environment simple to manage. Remember that the most common sources of failure are missing VLANs on one side of a trunk, native VLAN mismatches, and speed/duplex inconsistencies. Addressing these points early, coupled with regular verification commands, will keep the lab—and any production deployment—running smoothly Simple as that..

Quick note before moving on.