Table of Contents
Basic VLAN configuration barely scratches the surface of what the CCIE Enterprise Infrastructure lab actually expects. At this level, you need fluency with extended-range VLANs under VTP version 3, Private VLANs for sub-segmenting a broadcast domain, 802.1Q tunneling (QinQ) for carrying customer VLANs across a provider infrastructure, and the diagnostic instincts to fix trunking and VTP failures fast, under time pressure. This guide covers all four, building from advanced configuration scenarios through to a practice-ready command workbook.
Advanced VLAN Configuration Scenarios for the CCIE Lab
Beyond standard VLAN creation, the lab expects fluency with several advanced mechanisms working together. Here's how to approach each one.
- Master extended-range VLANs under the version that actually matters for the lab. Extended-range VLANs (1006–4094) require VTP transparent mode under VTP v1/v2, since those versions can't propagate or store them in the VLAN database. If the topology specifies VTP v3, extended VLANs are supported in server mode as well — know which version you're working with before troubleshooting a VLAN that "won't stick."
switch(config)# vtp version 3
switch(config)# vtp mode server
switch(config)# vlan 2000
switch(config-vlan)# name EXTENDED_LAB_VLAN
- Configure Private VLANs for sub-segmentation within a single broadcast domain. A private VLAN scenario typically asks you to isolate hosts sharing the same subnet without giving them full Layer 2 visibility of each other — start by defining the primary VLAN and its secondary (isolated or community) VLANs, then associate them.
switch(config)# vlan 100
switch(config-vlan)# private-vlan primary
switch(config)# vlan 101
switch(config-vlan)# private-vlan isolated
switch(config)# vlan 100
switch(config-vlan)# private-vlan association 101
- Assign host and promiscuous ports correctly. Private VLAN scenarios almost always test whether you understand which port type goes where — host ports connect end devices to the isolated/community VLAN, while the promiscuous port (typically facing a router or firewall) can communicate with every secondary VLAN under the primary.
switch(config)# interface gigabitEthernet 1/0/10
switch(config-if)# switchport mode private-vlan host
switch(config-if)# switchport private-vlan host-association 100 101
switch(config)# interface gigabitEthernet 1/0/1
switch(config-if)# switchport mode private-vlan promiscuous
switch(config-if)# switchport private-vlan mapping 100 101
- Configure 802.1Q tunneling (QinQ) for provider-style VLAN transparency. QinQ scenarios simulate a service-provider edge, where an entire customer's tagged VLAN traffic needs to cross the provider network inside a single outer (provider) VLAN tag, without the provider switches needing awareness of the customer's internal VLAN structure.
switch(config)# vlan 300
switch(config-vlan)# name PROVIDER_TUNNEL
switch(config)# interface gigabitEthernet 1/0/20
switch(config-if)# switchport access vlan 300
switch(config-if)# switchport mode dot1q-tunnel
switch(config-if)# l2protocol-tunnel cdp
- Enable the global QinQ ethertype if the lab topology requires 802.1ad compliance. Some scenarios specifically test whether you know to change the tunneling ethertype from Cisco's default to the 802.1ad standard value, since interoperability with non-Cisco gear depends on it.
switch(config)# vlan dot1q tag native
switch(config)# ethertype 88a8
- Verify every layer before moving to the next configuration task. In a timed lab environment, confirming each piece works immediately — rather than building the whole topology and testing at the end — saves far more time than it costs.
switch# show vlan private-vlan type
switch# show interfaces gigabitEthernet 1/0/20 switchport
switch# show vtp status
With PVLANs and QinQ both available as isolation tools, the natural next question in a lab scenario is which one actually fits the requirement being tested — and that's a distinction worth having memorized cold.
Private VLANs vs. QinQ: Choosing the Right Isolation Mechanism
Both technologies restrict Layer 2 visibility between devices, but they solve different problems and get tested differently in the lab.
| Criteria | Private VLANs (PVLAN) | 802.1Q Tunneling (QinQ) |
|---|---|---|
| Primary purpose | Isolate hosts within the same subnet/broadcast domain from each other | Transparently carry a customer's multiple VLAN tags across a provider network inside one outer VLAN |
| Scope of isolation | Within a single VLAN (via primary/secondary VLAN pairs) | Between the customer's VLAN structure and the provider's — customer VLANs stay invisible to the provider core |
| Typical lab trigger phrase | "Hosts must not communicate with each other but must reach the gateway" | "Customer VLANs must traverse the provider network without provider switches learning about them" |
| Port roles involved | Host ports (isolated/community) and a promiscuous port | Access ports in dot1q-tunnel mode facing the customer edge |
| VLAN tag behavior | Single VLAN tag; isolation enforced by port type, not by additional tagging | Double-tagging — customer's original 802.1Q tag preserved inside an added provider tag |
| Requires special hardware/software support | Yes — requires PVLAN-capable switches (most Catalyst platforms support it, but verify per-platform in lab prep) | Yes — requires dot1q-tunnel and L2 protocol tunneling support on the switch |
| Common lab pitfall | Forgetting to associate secondary VLANs to the primary, or assigning the wrong port mode | Forgetting to enable L2 protocol tunneling for CDP/STP/VTP, causing unexpected protocol behavior across the tunnel |
| Interacts with VTP | Private VLAN configuration itself isn't propagated via VTP v1/v2; treat similarly to extended-range VLAN considerations covered above | VLAN used for tunneling still follows normal VTP propagation rules for that VLAN ID |
The quick mental shortcut for the lab: if the requirement is about isolating devices within the same subnet, it's a PVLAN scenario; if the requirement is about transparently carrying someone else's VLAN tags across your network, it's QinQ. Misreading which one a task is actually asking for is a more common point-loss cause than misconfiguring the commands themselves.
Troubleshooting VLAN Trunking, Native VLAN Mismatches, and VTPv3 Sync Failures
Even a well-understood configuration can fail in the lab due to a small mismatch — here's a systematic diagnostic sequence for the most common Layer 2 failures at this level.
- Check for a native VLAN mismatch first when a trunk seems partially broken. This is one of the most common CCIE lab trip-ups — if both ends of a trunk don't agree on the native VLAN, the switch will generate a console warning, and untagged traffic can end up in the wrong VLAN on one side.
switch# show interfaces gigabitEthernet 1/0/48 trunk
Compare the native VLAN reported on both ends of the link directly against each other.
- Confirm allowed VLAN lists match expectations on both trunk ends. A VLAN that's pruned or missing from the allowed list on just one side will silently fail to pass traffic, without necessarily generating an obvious error.
switch# show interfaces trunk
- Verify VTP domain name and password match exactly across the topology. Under VTP v3, a domain name or password mismatch prevents synchronization just as it would under earlier versions — and case sensitivity matters.
switch# show vtp status
switch# show vtp password
- Check the VTP v3 primary server role if VLANs aren't syncing. VTP v3 introduces the concept of a primary server, which must be explicitly elected — a common lab mistake is assuming VLAN changes will propagate without ever promoting a switch to primary server role.
switch# vtp primary
switch# show vtp status
- Confirm private VLAN port associations if isolated hosts can't reach the gateway. A frequent PVLAN troubleshooting scenario is a host port associated with the wrong secondary VLAN, or a promiscuous port missing the mapping to a newly added secondary VLAN.
switch# show interfaces gigabitEthernet 1/0/10 switchport
switch# show vlan private-vlan
- Check for QinQ tunnel misbehavior involving STP or CDP. If customer-side switches are unexpectedly participating in provider-side STP or exchanging CDP information across the tunnel, confirm L2 protocol tunneling was actually enabled on the tunnel port — this is easy to configure the access/tunnel mode correctly while still forgetting this step.
switch# show l2protocol-tunnel
- Use systematic elimination rather than re-typing entire configs. In a timed lab, resist the urge to remove and recreate configuration blocks when something doesn't work — the verification commands above almost always pinpoint the exact mismatched parameter faster than a rebuild.
Working through native VLAN, allowed VLAN lists, VTP domain/password, and VTP v3 primary server role in that order resolves the overwhelming majority of Layer 2 sync issues that show up in lab scenarios, without needing to fall back on a full reconfiguration.
CCIE Lab VLAN Practice Workbook: Topology and Configuration Templates
Use the templates below as a starting skeleton for building your own timed practice scenarios covering everything above.
CCIE LAB VLAN PRACTICE TOPOLOGY TEMPLATE
==========================================
Suggested minimum topology:
SW1 (VTP primary server, v3) -- trunk -- SW2 (VTP server, v3)
SW2 -- trunk -- SW3 (VTP client)
SW3 -- access -- Host-A, Host-B (private VLAN isolated hosts)
SW3 -- promiscuous port -- R1 (gateway)
SW1 -- dot1q-tunnel port -- "Customer" switch simulating QinQ edge
Practice scenario checklist:
[ ] Configure VTP v3 with SW1 as primary server
[ ] Create extended-range VLAN 2000, confirm it syncs via VTPv3
[ ] Configure primary VLAN 100 + isolated VLAN 101 on SW3
[ ] Assign Host-A and Host-B to isolated VLAN 101
[ ] Assign R1-facing port as promiscuous, mapped to 100/101
[ ] Verify Host-A cannot reach Host-B, both reach R1
[ ] Configure dot1q-tunnel on SW1 facing "Customer" switch
[ ] Enable L2 protocol tunneling for CDP and STP
[ ] Intentionally mismatch native VLAN on one trunk link
[ ] Practice diagnosing and fixing the native VLAN mismatch
using only verification commands, no config removal
QUICK CONFIG TEMPLATE — FILL IN THE BLANKS
=============================================
# VTP v3 baseline
vtp domain ____________
vtp version 3
vtp mode ____________ # server / client / transparent
vtp password ____________
# Extended VLAN
vlan ____________ # 1006-4094
name ____________
# Private VLAN pair
vlan ____________ # primary
private-vlan primary
vlan ____________ # secondary
private-vlan isolated # or: community
vlan ____________ # (primary again)
private-vlan association ____________
# Private VLAN port roles
interface ____________
switchport mode private-vlan host
switchport private-vlan host-association ____________ ____________
interface ____________
switchport mode private-vlan promiscuous
switchport private-vlan mapping ____________ ____________
# QinQ tunnel port
vlan ____________ # provider tunnel VLAN
interface ____________
switchport access vlan ____________
switchport mode dot1q-tunnel
l2protocol-tunnel ____________ # cdp / stp / vtp as required
Time yourself running through this checklist end to end, then intentionally break one parameter at a time (native VLAN, VTP password, a missing PVLAN association) and practice diagnosing it using only the verification commands from the troubleshooting section above — that rebuild-free diagnostic habit is exactly what the timed lab format rewards.
Bringing It All Together
Advanced VLAN work at the CCIE level isn't really about knowing more commands — it's about recognizing which mechanism a scenario is actually asking for (isolation within a subnet versus transparent tunneling across one), keeping VTP version behavior straight since it governs whether your extended and private VLAN work even survives a sync, and diagnosing failures through targeted verification commands rather than reflexive reconfiguration. Build the practice topology above, break it deliberately, and fix it using only show commands — that's the exact skill the lab is testing, and it's the fastest way to turn these concepts into muscle memory before exam day.
