Troubleshooting Layer 2 — VLAN & Trunk Issues

Once Layer 1 is confirmed healthy — cables connected, no CRC errors, interfaces up/up — the next tier of failure lives at Layer 2. VLAN and trunk misconfigurations are among the most common and deceptive faults in switched networks: the physical link is perfectly functional, devices can see each other at Layer 1, yet no traffic flows because the logical segmentation is broken. A host assigned to the wrong VLAN cannot reach its default gateway. A trunk that fails to negotiate carries no tagged traffic between switches. A native VLAN mismatch silently drops untagged frames — or worse, enables VLAN hopping attacks.

The three primary diagnostic commands for Layer 2 VLAN and trunk troubleshooting are show vlan, show interfaces trunk, and debug dtp. Together they reveal the complete picture: which VLANs exist, which ports belong to them, whether trunks have formed, which VLANs are permitted and active across each trunk, and whether DTP negotiation is succeeding or failing. Understanding how to read and act on these three commands resolves the majority of Layer 2 connectivity problems without packet capture tools.

This guide assumes Layer 1 has been verified healthy — if interfaces are not up/up, resolve those first using Troubleshooting Layer 1. For the underlying VLAN and trunk concepts see VLAN Tagging, 802.1Q VLAN Tagging, and Access & Trunk Ports. For inter-VLAN routing issues that appear after Layer 2 is confirmed healthy, see Router-on-a-Stick and Layer 3 Switch Routing.

1. Layer 2 VLAN & Trunk — Core Concepts

The Layer 2 Fault Categories

Layer 2 VLAN and trunk faults fall into four distinct categories. Identifying which category applies before touching any configuration prevents fixing the wrong thing:

Fault Category Symptom Primary Diagnostic
VLAN does not exist Port assigned to VLAN that has never been created — port shows as inactive in show vlan show vlan brief — confirm VLAN is listed. See VLAN Creation and Management.
Port in wrong VLAN Host can reach some devices but not others — wrong broadcast domain. Ping to default gateway fails show vlan brief — verify port is listed under the correct VLAN. See Assigning VLANs to Switch Ports.
Trunk not forming No inter-switch traffic at all — trunk shows as access port or not trunking show interfaces trunk — confirm port appears in the trunking list. See Trunk Port Configuration.
VLAN not allowed or active on trunk Specific VLAN traffic cannot cross a trunk — other VLANs work normally show interfaces trunk — check allowed and active VLAN lists
Native VLAN mismatch Untagged traffic mis-delivered across trunk, CDP/STP warnings in syslog, potential VLAN hopping show interfaces trunk — compare native VLAN on both ends. Check show cdp neighbors detail for CDP warning.

How DTP (Dynamic Trunking Protocol) Works

DTP is a Cisco proprietary protocol that negotiates trunk formation between adjacent switches automatically. Understanding DTP mode combinations is essential — misconfigured DTP modes are the most common cause of trunk negotiation failures. For the full trunk configuration lab see Trunk Port Configuration:

Port Mode IOS Command Sends DTP Responds to DTP Result with Peer
dynamic auto switchport mode dynamic auto Yes (passive) Yes Trunks only if peer is desirable or trunk. Two auto ports = access
dynamic desirable switchport mode dynamic desirable Yes (active) Yes Trunks with auto, desirable, or trunk peer
trunk switchport mode trunk Yes Yes Always trunks regardless of peer mode
access switchport mode access No No Always access — never trunks. See Assigning VLANs to Switch Ports.
nonegotiate switchport nonegotiate No No Trunk without DTP — used with switchport mode trunk to disable DTP entirely

DTP Mode Combination Outcome Matrix

Switch A Mode Switch B Mode Result Trunks?
trunk trunk Trunk ✅ Yes
trunk dynamic desirable Trunk ✅ Yes
trunk dynamic auto Trunk ✅ Yes
dynamic desirable dynamic desirable Trunk ✅ Yes
dynamic desirable dynamic auto Trunk ✅ Yes
dynamic auto dynamic auto Access ❌ No — both wait passively
trunk access Access (mismatched) ❌ No — mode conflict
access access Access ❌ No (correct for edge ports)
Best practice: On inter-switch links, always explicitly configure switchport mode trunk and switchport nonegotiate on both ends. Never rely on DTP auto-negotiation for production trunk links — it adds negotiation overhead and the auto/auto failure mode is a common exam and real-world trap. On access ports facing end devices, always set switchport mode access to disable DTP entirely and prevent rogue devices from negotiating a trunk. See Trunk Port Configuration and Assigning VLANs to Switch Ports.

The Four show interfaces trunk Columns

show interfaces trunk output has four distinct sections. Reading them in order from top to bottom solves the majority of trunk VLAN visibility problems:

  Port        Mode         Encapsulation  Status        Native vlan
  Gi0/1       on           802.1q         trunking      1            ← Section 1: Is it trunking?

  Port        Vlans allowed on trunk
  Gi0/1       1-4094                                                 ← Section 2: What's permitted?

  Port        Vlans allowed and active in the management domain
  Gi0/1       1,10,20,30                                             ← Section 3: What VLANs exist locally?

  Port        Vlans in spanning tree forwarding state and not pruned
  Gi0/1       1,10,20,30                                             ← Section 4: What's actually forwarding?

  ─────────────────────────────────────────────────────────────────
  A VLAN must pass ALL FOUR sections to carry traffic across this trunk:
    Section 1 — trunk must be in "trunking" status
    Section 2 — VLAN must not be excluded by switchport trunk allowed vlan
    Section 3 — VLAN must exist in the local VLAN database (show vlan)
    Section 4 — VLAN must not be pruned and must be in STP forwarding state
  

2. Lab Topology & Scenario

This lab presents six Layer 2 fault scenarios across a two-switch topology with a router providing inter-VLAN routing. Each scenario is independent and starts from a known symptom:

  [PC1 – VLAN 10 – 192.168.10.10]──Fa0/1──┐
  [PC2 – VLAN 20 – 192.168.20.10]──Fa0/2──┤
  [PC3 – VLAN 30 – 192.168.30.10]──Fa0/3──┤              [PC5 – VLAN 10]──Fa0/1──┐
  [PC4 – VLAN 10 – 192.168.10.20]──Fa0/4──┤              [PC6 – VLAN 20]──Fa0/2──┤
                                     NetsTuts_SW1──Gi0/2──NetsTuts_SW2
                                     Gi0/1│                       Gi0/1│
                                          │                            │
                              NetsTuts_R1 (Router-on-a-Stick)   (uplink to SW1)
                              Sub-interfaces:
                              Gi0/0.10 – 192.168.10.1/24  (VLAN 10 gateway)
                              Gi0/0.20 – 192.168.20.1/24  (VLAN 20 gateway)
                              Gi0/0.30 – 192.168.30.1/24  (VLAN 30 gateway)

  Fault Scenarios:
    Scenario 1 — PC1 cannot ping its default gateway (VLAN not created on SW1)
    Scenario 2 — PC4 cannot reach PC1 despite being in same VLAN (wrong VLAN assignment)
    Scenario 3 — No traffic between SW1 and SW2 at all (trunk not forming — auto/auto)
    Scenario 4 — VLAN 30 traffic cannot cross the SW1–SW2 trunk (VLAN pruned from trunk)
    Scenario 5 — Native VLAN mismatch between SW1 and SW2 (CDP warning in syslog)
    Scenario 6 — SW1–R1 trunk not forming (one side access, one side trunk)
  
Scenario Affected Device/Port Symptom Root Cause
1 SW1 — all VLAN 10 ports PC1 cannot ping 192.168.10.1 VLAN 10 not created in VLAN database
2 SW1 Fa0/4 PC4 cannot reach PC1 (same VLAN) Fa0/4 assigned to VLAN 20 instead of VLAN 10
3 SW1 Gi0/2 / SW2 Gi0/1 No inter-switch traffic Both ports in dynamic auto — trunk never forms
4 SW1 Gi0/2 (trunk) VLAN 30 unreachable from SW2 side VLAN 30 removed from allowed VLAN list on trunk
5 SW1 Gi0/2 / SW2 Gi0/1 CDP native VLAN mismatch warning, untagged traffic misdirected SW1 native VLAN 1, SW2 native VLAN 99 on same trunk
6 SW1 Gi0/1 / R1 Gi0/0 Router sub-interfaces up but no inter-VLAN routing SW1 Gi0/1 left as access port — R1 Gi0/0 expecting 802.1Q trunk

3. Scenario 1 — VLAN Does Not Exist

PC1 (192.168.10.10) cannot ping its default gateway (192.168.10.1). Layer 1 is healthy — Fa0/1 is up/up. The port was assigned to VLAN 10 during initial configuration but nobody confirmed that VLAN 10 was actually created. See VLAN Creation and Management for the full VLAN database process.

Step 1 — Check the VLAN Database

NetsTuts_SW1#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/2
20   VLAN0020                         active    Fa0/2
30   VLAN0030                         active    Fa0/3
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup
  
VLAN 10 is entirely absent from the VLAN database — it was never created. Notice that Fa0/1 and Fa0/4 (the VLAN 10 ports) do not appear under any VLAN. When a port is assigned to a non-existent VLAN it becomes inactive — the switch will not forward frames in or out of that port because its VLAN has no entry in the forwarding database. The port LED may show green (Layer 1 up) but no Layer 2 traffic flows.

Step 2 — Confirm Port Assignment

NetsTuts_SW1#show running-config interface FastEthernet0/1
Building configuration...
interface FastEthernet0/1
 switchport access vlan 10
 switchport mode access
!

! ── Port IS configured for VLAN 10 — VLAN just doesn't exist yet
NetsTuts_SW1#show interfaces FastEthernet0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 10 (Inactive)
Trunking Native Mode VLAN: 1 (default)
  
The key field is Access Mode VLAN: 10 (Inactive) — IOS explicitly flags the VLAN as inactive because it does not exist in the VLAN database. This single field immediately confirms the diagnosis: the port configuration is correct, but the VLAN it references does not exist. Creating the VLAN will restore the port to active without any port-level changes.

Step 3 — Create the VLAN and Verify

! ── Create VLAN 10 with a descriptive name ───────────────────────
NetsTuts_SW1(config)#vlan 10
NetsTuts_SW1(config-vlan)#name Staff
NetsTuts_SW1(config-vlan)#exit

! ── Verify VLAN is now active and ports are assigned ─────────────
NetsTuts_SW1#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/2
10   Staff                            active    Fa0/1, Fa0/4
20   VLAN0020                         active    Fa0/2
30   VLAN0030                         active    Fa0/3

! ── Confirm port is no longer inactive ───────────────────────────
NetsTuts_SW1#show interfaces FastEthernet0/1 switchport | include VLAN
Access Mode VLAN: 10 (Staff)
  
Once VLAN 10 is created, the switch immediately activates all ports assigned to it — Fa0/1 and Fa0/4 both appear under VLAN 10 without any port-level configuration changes. The (Inactive) flag is replaced by the VLAN name (Staff). PC1 can now reach its gateway. This scenario is extremely common in new deployments where access port VLANs are configured before VLANs are created in the database. See VLAN Creation and Management and Assigning VLANs to Switch Ports.

4. Scenario 2 — Port Assigned to Wrong VLAN

PC4 (192.168.10.20) and PC1 (192.168.10.10) should be in VLAN 10 and able to communicate directly. PC4 can reach 192.168.20.x hosts instead — it is clearly in the wrong broadcast domain.

Diagnosing with show vlan

NetsTuts_SW1#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/2
10   Staff                            active    Fa0/1
20   VLAN0020                         active    Fa0/2, Fa0/4
30   VLAN0030                         active    Fa0/3
  
Fa0/4 appears under VLAN 20 — not VLAN 10 where PC4 belongs. PC4's traffic is being switched into the VLAN 20 broadcast domain, where it receives IP addresses and ARP responses from VLAN 20 hosts and the VLAN 20 gateway (192.168.20.1) — explaining why it can reach VLAN 20 hosts but not VLAN 10 hosts. The fix is a single interface command. See Assigning VLANs to Switch Ports for the full access port assignment workflow.

Fix and Verify

NetsTuts_SW1(config)#interface FastEthernet0/4
NetsTuts_SW1(config-if)#switchport access vlan 10
NetsTuts_SW1(config-if)#exit

NetsTuts_SW1#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/2
10   Staff                            active    Fa0/1, Fa0/4
20   VLAN0020                         active    Fa0/2
30   VLAN0030                         active    Fa0/3
  
Fa0/4 now appears under VLAN 10 alongside Fa0/1. The switchport access vlan [number] command moves a port from one VLAN to another instantly — no reload or port bounce needed. After the fix, PC4 should be able to ping PC1 (same switch, same VLAN — Layer 2 only, no routing needed) and its correct gateway at 192.168.10.1. Always release and renew the PC's DHCP lease or clear its ARP cache after a VLAN reassignment so it obtains a correct IP address for the new VLAN.

show vlan vs show interfaces switchport — Two Views of the Same Data

Command Best Used For Key Output Fields
show vlan brief Seeing all ports under all VLANs at once — overview of the entire switch VLAN number, name, status (active/inactive), all assigned ports in one line
show vlan id [number] Deep dive on a specific VLAN — all ports, status, and MTI info Same as brief but filtered to one VLAN — useful for large switches with many ports
show interfaces [name] switchport Full detail on one specific port — admin vs operational mode, access VLAN, trunk VLANs, DTP state Administrative Mode, Operational Mode, Access Mode VLAN (with active/inactive flag), Native VLAN, Trunking VLANs
show running-config interface [name] Confirming what was explicitly configured vs what IOS defaulted Presence of switchport access vlan, switchport mode, switchport trunk commands

5. Scenario 3 — Trunk Not Forming (DTP auto/auto)

No traffic passes between SW1 and SW2 — hosts on SW2 cannot reach hosts on SW1 or the router. The physical link between SW1 Gi0/2 and SW2 Gi0/1 is up/up (Layer 1 healthy). Both switches are Cisco Catalyst and both ports were left at their default DTP mode.

Step 1 — Check Trunk Status

NetsTuts_SW1#show interfaces trunk

! ── Output is empty — no trunk interfaces listed ─────────────────
  
An empty show interfaces trunk output means no ports on this switch are currently trunking. Gi0/2 — the inter-switch link — is not in the trunk list. This is the clearest possible indicator that the trunk has not formed. The port is up/up at Layer 1 but operating as an access port, not a trunk.

Step 2 — Check the DTP Mode

NetsTuts_SW1#show interfaces GigabitEthernet0/2 switchport
Name: Gi0/2
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL

NetsTuts_SW2#show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
...
  
Both ports are in Administrative Mode: dynamic auto — the default on most Catalyst switches. The Operational Mode: static access confirms they have settled into access mode rather than trunk mode. Two dynamic auto ports both wait passively for the other to initiate trunk negotiation — neither sends active DTP solicitations, so the trunk never forms. This is the classic auto/auto failure mode.

Step 3 — Fix Both Ends

! ── Fix on SW1 ───────────────────────────────────────────────────
NetsTuts_SW1(config)#interface GigabitEthernet0/2
NetsTuts_SW1(config-if)#switchport mode trunk
NetsTuts_SW1(config-if)#switchport nonegotiate
NetsTuts_SW1(config-if)#exit

! ── Fix on SW2 ───────────────────────────────────────────────────
NetsTuts_SW2(config)#interface GigabitEthernet0/1
NetsTuts_SW2(config-if)#switchport mode trunk
NetsTuts_SW2(config-if)#switchport nonegotiate
NetsTuts_SW2(config-if)#exit
  
switchport mode trunk sets the port to unconditional trunking mode — it does not wait for negotiation. switchport nonegotiate disables DTP entirely on the port — the switch stops sending DTP frames, which is the security best practice for inter-switch links. Without nonegotiate, a mode trunk port still sends DTP frames, which could be exploited by a rogue switch to negotiate a trunk and gain access to all VLANs. See Trunk Port Configuration for the complete trunk setup lab.

Step 4 — Verify Trunk Formation

NetsTuts_SW1#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      1
Gi0/2       on           802.1q         trunking      1

Port        Vlans allowed on trunk
Gi0/1       1-4094
Gi0/2       1-4094

Port        Vlans allowed and active in the management domain
Gi0/1       1,10,20,30
Gi0/2       1,10,20,30

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/1       1,10,20,30
Gi0/2       1,10,20,30
  
Both Gi0/1 (uplink to router) and Gi0/2 (inter-switch link) now appear as trunking with 802.1Q encapsulation. All four VLANs (1, 10, 20, 30) appear in sections 3 and 4 — they exist locally and are in STP forwarding state. Traffic between SW1 and SW2 will now flow for all four VLANs. Verify end-to-end with ping.

Using debug dtp — Live DTP Negotiation Trace

! ── Enable DTP debugging — use on a quiet link only ──────────────
NetsTuts_SW1#debug dtp
DTP debugging is on

! ── Bounce the interface to trigger fresh negotiation ─────────────
NetsTuts_SW1(config)#interface GigabitEthernet0/2
NetsTuts_SW1(config-if)#shutdown
NetsTuts_SW1(config-if)#no shutdown

! ── Sample debug output ──────────────────────────────────────────
DTP: Gi0/2: Rcvd trunk neg packet, V2, domain=  , myaddr=0c1a.3b2f.0201, ta=0c1a.3b2f.0201
DTP: Gi0/2: Sending trunk neg packet, V2, domain=  , myaddr=0c1a.3b2f.0201
DTP: Gi0/2: No WS change, Operational state TRUNK(6)
DTP: Gi0/2: Setting trunk config on: TRUNK mode(6)

NetsTuts_SW1#undebug all
  
debug dtp shows every DTP packet sent and received — the operational state TRUNK(6) confirms the port transitioned to trunking. If the peer were in access mode, debug output would show DTP packets being sent but no trunk state change — the port would remain in access mode. Always run undebug all immediately after the test. Use debug dtp only during a maintenance window on low-traffic links — on busy inter-switch trunks the output volume is substantial.

6. Scenario 4 — VLAN Not Allowed on Trunk

After adding VLAN 30 (for the new server segment) to SW1 and SW2, PC3 on SW1 (VLAN 30) cannot reach any host on SW2. VLANs 10 and 20 cross the trunk fine. The trunk itself is confirmed trunking (Section 1 of show interfaces trunk is healthy).

Diagnosing Through All Four Trunk Sections

NetsTuts_SW1#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/2       on           802.1q         trunking      1             ← Section 1 OK

Port        Vlans allowed on trunk
Gi0/2       1,10,20                                                 ← Section 2: VLAN 30 MISSING

Port        Vlans allowed and active in the management domain
Gi0/2       1,10,20

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/2       1,10,20
  
Section 2 is the smoking gun — VLAN 30 does not appear in "Vlans allowed on trunk." This means an explicit switchport trunk allowed vlan command removed VLAN 30 from the permitted list on this port. Because VLAN 30 is blocked in Section 2, it naturally also disappears from Sections 3 and 4. When a VLAN is absent from all sections below Section 1, always check Section 2 first — it is the most common cause of a specific VLAN failing to cross an otherwise healthy trunk.

Finding the Cause in Running Config

NetsTuts_SW1#show running-config interface GigabitEthernet0/2
Building configuration...
interface GigabitEthernet0/2
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1,10,20
 switchport mode trunk
 switchport nonegotiate
!
  
The explicit switchport trunk allowed vlan 1,10,20 line confirms that VLAN 30 was intentionally or accidentally excluded. This command replaces the default (allow all VLANs 1–4094) with an explicit whitelist. When a new VLAN is created after this command was issued, it is not automatically added to the allowed list — it must be explicitly added. This is a very common operational oversight when VLANs are added to a network after the initial trunk configuration. Use show running-config | section interface to audit all trunk port configurations.

Fix — Add VLAN 30 to the Allowed List

! ── WRONG — this replaces the entire allowed list with only VLAN 30
NetsTuts_SW1(config-if)#switchport trunk allowed vlan 30
! ── Result: Gi0/2 now only allows VLAN 30 — breaks VLANs 10 and 20

! ── CORRECT — use 'add' keyword to append without overwriting ─────
NetsTuts_SW1(config)#interface GigabitEthernet0/2
NetsTuts_SW1(config-if)#switchport trunk allowed vlan add 30
NetsTuts_SW1(config-if)#exit

! ── Verify ────────────────────────────────────────────────────────
NetsTuts_SW1#show interfaces trunk
Port        Vlans allowed on trunk
Gi0/2       1,10,20,30
  
The add keyword is critical — omitting it replaces the entire allowed VLAN list with only the specified VLAN, silently breaking all other VLANs on the trunk. This is one of the most common configuration mistakes on Cisco switches. The safe keywords for modifying the allowed VLAN list are: add (append), remove (delete specific VLANs), and except (allow all except specified). Using the bare switchport trunk allowed vlan [list] without a keyword always replaces the full list. See Trunk Port Configuration for the complete allowed VLAN list management guide.

Allowed VLAN List Command Reference

Command Effect Use Case
switchport trunk allowed vlan 10,20,30 Replaces the entire allowed list with exactly VLANs 10, 20, 30 Initial configuration when you want precise control from the start
switchport trunk allowed vlan add 30 Appends VLAN 30 to the existing allowed list — other VLANs unchanged Adding a new VLAN to an existing trunk without disturbing current traffic
switchport trunk allowed vlan remove 30 Removes VLAN 30 from the allowed list — other VLANs unchanged Removing a decommissioned VLAN from a trunk
switchport trunk allowed vlan all Restores the default — allows all VLANs 1–4094 Removing all explicit filtering and returning to default behaviour
switchport trunk allowed vlan except 40 Allows all VLANs except VLAN 40 Blocking a specific VLAN from crossing a trunk while allowing all others

Section 3 Failure — VLAN Exists on One Switch But Not the Other

! ── Scenario: VLAN 30 allowed on trunk but missing from Section 3 ─
NetsTuts_SW2#show interfaces trunk
Port        Vlans allowed on trunk
Gi0/1       1,10,20,30                ← Section 2 OK — VLAN 30 allowed

Port        Vlans allowed and active in the management domain
Gi0/1       1,10,20                   ← Section 3: VLAN 30 missing here

! ── Diagnosis: VLAN 30 exists on SW1 but not in SW2's VLAN database
NetsTuts_SW2#show vlan brief
VLAN Name                  Status    Ports
1    default                active    ...
10   Staff                  active    Fa0/1
20   VLAN0020               active    Fa0/2
! ── VLAN 30 absent from SW2 ─────────────────────────────────────

NetsTuts_SW2(config)#vlan 30
NetsTuts_SW2(config-vlan)#name Servers
NetsTuts_SW2(config-vlan)#exit
  
Section 3 of show interfaces trunk shows only VLANs that are both allowed (Section 2) and exist in the local VLAN database. If a VLAN passes Section 2 but disappears in Section 3, the VLAN database is the fault — create the VLAN with vlan [number]. This commonly happens when VLANs are created on one switch but the configuration is not propagated to neighbouring switches (VTP is not in use or is misconfigured). See VLAN Creation and Management.

7. Scenario 5 — Native VLAN Mismatch

The syslog server shows a repeating CDP warning: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/2. Some untagged management traffic appears to be reaching unexpected hosts. The trunk itself is functioning for tagged VLANs.

Understanding Native VLAN

  On an 802.1Q trunk, ALL frames are tagged with a VLAN ID — except frames
  belonging to the native VLAN. Native VLAN frames are sent UNTAGGED.

  When both ends agree on the same native VLAN (e.g., both use VLAN 1):
    SW1 sends untagged frame → SW2 receives it → assigns to VLAN 1 ✅

  When ends DISAGREE on the native VLAN (SW1 = VLAN 1, SW2 = VLAN 99):
    SW1 sends untagged frame (VLAN 1 traffic) → SW2 receives it →
    assigns to VLAN 99 (SW2's native) → VLAN 1 frame arrives in VLAN 99 ❌

  This silently moves untagged frames between VLANs — a security risk
  known as VLAN hopping. CDP detects and warns about this mismatch
  because both switches advertise their native VLAN in CDP packets.
  

Diagnosing the Native VLAN Mismatch

NetsTuts_SW1#show interfaces trunk
Port        Mode         Encapsulation  Status        Native vlan
Gi0/2       on           802.1q         trunking      1

NetsTuts_SW2#show interfaces trunk
Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      99
  
The native VLAN column in Section 1 immediately reveals the mismatch — SW1 shows native VLAN 1 and SW2 shows native VLAN 99 on the same physical link. These values must match for correct operation. CDP detects this because both switches advertise their native VLAN ID in CDP neighbour packets — when the received native VLAN differs from the local native VLAN, IOS generates the %CDP-4-NATIVE_VLAN_MISMATCH syslog message and logs it at severity level 4 (warning).

Fix — Align Native VLANs on Both Ends

! ── Best practice: change native VLAN to a dedicated unused VLAN
!    (not VLAN 1 — avoids VLAN 1 being untagged on trunks)

! ── Option A: Match SW2 — change SW1 to native VLAN 99 ───────────
NetsTuts_SW1(config)#interface GigabitEthernet0/2
NetsTuts_SW1(config-if)#switchport trunk native vlan 99
NetsTuts_SW1(config-if)#exit

! ── Option B: Match SW1 — change SW2 to native VLAN 1 ───────────
NetsTuts_SW2(config)#interface GigabitEthernet0/1
NetsTuts_SW2(config-if)#switchport trunk native vlan 1
NetsTuts_SW2(config-if)#exit

! ── Best practice: use a dedicated VLAN (e.g., 999) on BOTH ends ─
NetsTuts_SW1(config)#vlan 999
NetsTuts_SW1(config-vlan)#name Native-Trunk
NetsTuts_SW1(config-vlan)#exit
NetsTuts_SW1(config)#interface GigabitEthernet0/2
NetsTuts_SW1(config-if)#switchport trunk native vlan 999
NetsTuts_SW1(config-if)#exit

NetsTuts_SW2(config)#vlan 999
NetsTuts_SW2(config-vlan)#name Native-Trunk
NetsTuts_SW2(config-vlan)#exit
NetsTuts_SW2(config)#interface GigabitEthernet0/1
NetsTuts_SW2(config-if)#switchport trunk native vlan 999
NetsTuts_SW2(config-if)#exit

! ── Verify — native VLAN now matches ─────────────────────────────
NetsTuts_SW1#show interfaces trunk
Port        Mode         Encapsulation  Status        Native vlan
Gi0/2       on           802.1q         trunking      999
  
Using a dedicated, unused VLAN (999 here) as the native VLAN on all trunks is a security best practice — it ensures no user traffic is ever sent untagged, eliminating the VLAN hopping attack surface. VLAN 999 should have no ports assigned to it and no IP addressing. The CDP native VLAN mismatch warning will clear within 60 seconds once both ends are aligned. Optionally, enable switchport trunk native vlan tag globally (vlan dot1q tag native) to force 802.1Q tagging even on native VLAN frames — this eliminates untagged frames on the trunk entirely.

Native VLAN and VLAN Hopping Risk

Condition Security Risk Mitigation
Native VLAN mismatch on trunk Untagged frames silently moved between VLANs — data from one VLAN received by another Align native VLANs on both trunk ends immediately
Native VLAN = VLAN 1 (default) Management traffic (CDP, STP BPDUs) travels untagged — slightly increased attack surface Change native VLAN to a dedicated unused VLAN on all trunks
Access port native VLAN = trunk native VLAN Double-tagging VLAN hop — an attacker sends double-tagged frames from an access port to reach the trunk's native VLAN on the far side Ensure the trunk native VLAN is never assigned to any access port. Use a dedicated VLAN never used for hosts. See DHCP Snooping & DAI.

8. Scenario 6 — Switch-to-Router Trunk Not Forming

Sub-interfaces on R1 (Gi0/0.10, .20, .30) are configured and show as up/up. But hosts in all VLANs cannot reach their default gateways. Inter-VLAN routing is completely broken. The switch-to-router link (SW1 Gi0/1 to R1 Gi0/0) is up/up at Layer 1. See Router-on-a-Stick Inter-VLAN Routing for the full configuration reference.

Checking the Switch Port Mode

NetsTuts_SW1#show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
  
Administrative Mode: static access — the switch port connected to the router is configured as an access port. It is permanently in access mode and will never trunk. The router's sub-interfaces are expecting 802.1Q-tagged frames for each VLAN — but the switch is sending and receiving only untagged frames for VLAN 1. Sub-interfaces for VLANs 10, 20, and 30 receive no traffic because their VLAN tags never arrive. The router interfaces show up/up because Layer 1 is healthy — but no tagged frames reach them.

Checking the Router Sub-Interface Configuration

NetsTuts_R1#show running-config | section interface GigabitEthernet0/0
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
!
interface GigabitEthernet0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0
!
  
The router configuration is correct — each sub-interface has the right encapsulation dot1Q [vlan-id] and IP address. The parent interface (Gi0/0) correctly has no IP address. The fault is entirely on the switch side. This is a common scenario where the router was correctly configured but the switch port was not changed from its default access mode to trunk mode. See Router-on-a-Stick Inter-VLAN Routing for the complete sub-interface configuration reference.

Fix — Convert Switch Port to Trunk

NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#switchport trunk encapsulation dot1q
NetsTuts_SW1(config-if)#switchport mode trunk
NetsTuts_SW1(config-if)#switchport nonegotiate
NetsTuts_SW1(config-if)#exit

! ── Verify trunk formed and all VLANs are active ─────────────────
NetsTuts_SW1#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      1
Gi0/2       on           802.1q         trunking      999

Port        Vlans allowed on trunk
Gi0/1       1-4094
Gi0/2       1-4094

Port        Vlans allowed and active in the management domain
Gi0/1       1,10,20,30
Gi0/2       1,10,20,30

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/1       1,10,20,30
Gi0/2       1,10,20,30
  
switchport trunk encapsulation dot1q is required on some older Catalyst switch models that support both ISL and 802.1Q — it explicitly selects 802.1Q as the trunking encapsulation. Newer Catalyst platforms support only 802.1Q and do not require this command. After the fix, Gi0/1 appears in show interfaces trunk with all four VLANs active in Section 3 and forwarding in Section 4. Hosts in all VLANs can now reach their sub-interface gateways on R1. Verify with ping 192.168.10.1.

Router-on-a-Stick vs Layer 3 Switch — Common Trunk Fault Points

Topology Common Layer 2 Fault Diagnostic
Router-on-a-Stick Switch port to router left as access — sub-interfaces never receive tagged frames show interfaces [sw-port] switchport — check Administrative Mode is trunk
Router-on-a-Stick Sub-interface missing encapsulation dot1Q [vlan] — sub-interface ignores frames for that VLAN show running-config | section GigabitEthernet0/0 — verify each sub-interface has the correct encapsulation
Layer 3 Switch (SVI) SVI created but VLAN not in VLAN database — SVI stays down/down show ip interface brief — SVI shows down/down. Fix: vlan [number] in global config
Layer 3 Switch (SVI) No active ports in the VLAN — SVI comes up only when at least one access port in that VLAN is up/up show vlan brief — confirm active ports under the VLAN. show ip interface brief — SVI shows down

9. Full Diagnostic Command Reference

show interfaces trunk — Complete Field Guide

NetsTuts_SW1#show interfaces trunk

! ─── SECTION 1: Trunk Status ─────────────────────────────────────
Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      1
Gi0/2       on           802.1q         trunking      999

! Mode:          on = hardcoded trunk (switchport mode trunk)
!                desirable/auto = DTP-negotiated
! Encapsulation: 802.1q (dot1Q) — only standard on modern IOS
!                isl — legacy Cisco proprietary, avoid
! Status:        trunking = operational trunk
!                not-trunking = DTP negotiation failed or port is access
! Native vlan:   untagged VLAN — must match on both ends of the trunk

! ─── SECTION 2: Allowed VLANs ────────────────────────────────────
Port        Vlans allowed on trunk
Gi0/1       1-4094
Gi0/2       1,10,20,30,999

! Default is 1-4094 (all). Modified by switchport trunk allowed vlan.
! A VLAN absent here is explicitly blocked — check running-config.

! ─── SECTION 3: Active VLANs ─────────────────────────────────────
Port        Vlans allowed and active in the management domain
Gi0/1       1,10,20,30
Gi0/2       1,10,20,30,999

! A VLAN in Section 2 but missing here means it does not exist in
! the local VLAN database. Fix: create the VLAN with vlan [number].

! ─── SECTION 4: Forwarding VLANs ─────────────────────────────────
Port        Vlans in spanning tree forwarding state and not pruned
Gi0/1       1,10,20,30
Gi0/2       1,10,20,30,999

! A VLAN in Section 3 but missing here is either:
!   - In STP blocking state on this port (check show spanning-tree)
!   - VTP pruned (check show vtp status and switchport trunk pruning)
  

Layer 2 Troubleshooting Decision Tree

Symptom First Check If Found Fix
Port shows (Inactive) for VLAN show vlan brief VLAN not in database vlan [number] in global config. See VLAN Creation.
Host in wrong broadcast domain show vlan brief Port under wrong VLAN number switchport access vlan [correct]. See Assigning VLANs.
No inter-switch traffic at all show interfaces trunk Trunk port absent (not trunking) Check DTP modes — set both to switchport mode trunk. See Trunk Config.
Specific VLAN not crossing trunk show interfaces trunk Section 2 VLAN absent from allowed list switchport trunk allowed vlan add [vlan]
VLAN allowed but still not crossing show interfaces trunk Section 3 VLAN absent from active list Create VLAN on the switch: vlan [number]. See VLAN Creation.
VLAN active but still no traffic show interfaces trunk Section 4 VLAN absent from forwarding list Check STP state (show spanning-tree vlan [id]) or VTP pruning
CDP native VLAN mismatch warning show interfaces trunk Native vlan column Different native VLAN each end switchport trunk native vlan [same-value] on both ends
Router sub-interfaces up but no routing show interfaces [sw-port] switchport Switch port is access mode switchport mode trunk + switchport trunk encapsulation dot1q. See Router-on-a-Stick.
SVI down/down show vlan brief + show ip int brief VLAN not created or no active ports Create VLAN, ensure at least one access port in VLAN is up/up. See Layer 3 Switch Routing.
Trunk not forming — unsure why debug dtp during brief port bounce No DTP exchange or mismatch visible Hardcode: switchport mode trunk + switchport nonegotiate both ends

Key Points & Exam Tips

  • Always verify Layer 1 first — a port cannot trunk if it is down/down. Use Troubleshooting Layer 1 before investigating Layer 2 VLAN issues.
  • A port assigned to a non-existent VLAN becomes inactiveshow interfaces [port] switchport shows Access Mode VLAN: [number] (Inactive). Fix: create the VLAN with vlan [number] in global config. See VLAN Creation and Management.
  • Two dynamic auto ports facing each other will never form a trunk — both wait passively for the other to initiate. Always explicitly configure switchport mode trunk on inter-switch links. See Trunk Port Configuration.
  • The four sections of show interfaces trunk must all pass for a VLAN to carry traffic: (1) port is trunking, (2) VLAN is allowed, (3) VLAN exists locally, (4) VLAN is in STP forwarding state and not pruned.
  • Always use the add keyword when adding VLANs to an existing trunk allowed list — switchport trunk allowed vlan add [vlan]. Omitting add replaces the entire allowed list with only the specified VLAN.
  • Native VLAN must match on both ends of an 802.1Q trunk. A mismatch causes untagged frames to be delivered to the wrong VLAN and generates a CDP warning in the syslog. Best practice: use a dedicated, unused VLAN as the native VLAN on all trunks.
  • For Router-on-a-Stick, the switch port connected to the router must be a trunk — not an access port. Sub-interfaces on the router are irrelevant if the switch never sends 802.1Q-tagged frames. See Router-on-a-Stick.
  • switchport nonegotiate disables DTP on a port — use it on all inter-switch trunk links (mode trunk + nonegotiate) and on all access ports to prevent rogue trunk negotiation. Also consider Port Security and DHCP Snooping on access ports.
  • debug dtp shows live DTP negotiation events — use it briefly during a port bounce to diagnose trunk formation failures. Always undebug all immediately after.
  • On the CCNA exam: know the DTP mode combination matrix (especially auto/auto = access), the four sections of show interfaces trunk, the native VLAN mismatch symptom and fix, and the add keyword for allowed VLAN list modification.
  • A STP blocking state on a port causes its VLANs to disappear from Section 4 of show interfaces trunk — use show spanning-tree vlan [id] to identify the port role. For edge ports, PortFast can be enabled on access ports to bypass STP.
Next Steps: With Layer 2 VLAN and trunk issues resolved, advance to Layer 3 troubleshooting. For inter-VLAN routing verification see Router-on-a-Stick and Layer 3 Switch Routing. For STP issues that cause VLANs to disappear from Section 4 of show interfaces trunk see STP Overview, STP Port Roles, and PortFast & BPDU Guard. For VTP pruning that removes VLANs from Section 4 see VLAN Tagging. For the underlying access and trunk port concepts see Access & Trunk Ports and 802.1Q VLAN Tagging. For access port security, see Port Security, DHCP Snooping & DAI, and Voice VLAN Configuration.

TEST WHAT YOU LEARNED

1. show interfaces FastEthernet0/3 switchport shows Access Mode VLAN: 30 (Inactive). The port was configured with switchport access vlan 30. What does "(Inactive)" mean and what is the fix?

Correct answer is B. The "(Inactive)" label in show interfaces switchport output is IOS explicitly indicating that the VLAN referenced by the port does not exist in the VLAN database. The port-level configuration (switchport access vlan 30) is correct — IOS accepted and stored the command. But until the corresponding VLAN is created with vlan 30 in global configuration mode, the switch has no VLAN 30 entry in its forwarding table and treats the port as inactive — no frames are forwarded. Creating the VLAN instantly activates all ports referencing it without requiring any port-level changes. See VLAN Creation and Management and Assigning VLANs to Switch Ports.

2. Two Cisco switches are connected back-to-back. SW1 Gi0/1 is set to switchport mode dynamic auto and SW2 Gi0/1 is also set to switchport mode dynamic auto. show interfaces trunk shows no trunk interfaces on either switch. Why?

Correct answer is D. DTP dynamic auto is a passive mode — it will respond to a DTP solicitation from the peer but never initiates one. When both sides are passive, neither sends the DTP frames needed to initiate negotiation, and the link defaults to access mode. This is a well-known CCNA exam topic and a real-world trap — it most often appears when switch ports are left at their factory defaults (many Catalyst switches default to dynamic auto). The fix is to configure both inter-switch ports as switchport mode trunk with switchport nonegotiate to form a deterministic trunk without relying on DTP negotiation at all. See Trunk Port Configuration.

3. An engineer runs switchport trunk allowed vlan 40 on a trunk port that previously allowed VLANs 10, 20, and 30. Immediately after, users in VLANs 10, 20, and 30 lose connectivity across that trunk. What happened?

Correct answer is A. This is one of the most impactful and common Cisco IOS configuration mistakes. The command switchport trunk allowed vlan [list] without any keyword (add, remove, except, all) does not append — it completely replaces the allowed VLAN list with exactly what is specified. The previous list of VLANs 10, 20, and 30 is discarded and replaced with only VLAN 40. The result is an immediate outage for all traffic on VLANs 10, 20, and 30 across that trunk, which can affect many users simultaneously. The safe practice is to always use add when adding VLANs to an existing list. To recover: switchport trunk allowed vlan add 10,20,30 restores the previous VLANs. Alternatively, switchport trunk allowed vlan all returns to the default of allowing all VLANs 1–4094. See Trunk Port Configuration.

4. show interfaces trunk on SW1 shows VLAN 40 in Section 2 (allowed) but not in Section 3 (active). What does this mean and how is it fixed?

Correct answer is C. Section 3 of show interfaces trunk ("Vlans allowed and active in the management domain") applies two filters simultaneously: the VLAN must be in the allowed list (Section 2) AND must exist in the local VLAN database. A VLAN appearing in Section 2 but dropping out in Section 3 has exactly one cause: the VLAN does not exist locally. This commonly happens when a VLAN is created on one switch but not propagated to a neighbouring switch (VTP is not being used or the VTP domain is misconfigured), or when the allowed list is configured before the VLAN is created. The fix is always to create the VLAN: vlan 40 in global configuration mode. STP blocking would cause a VLAN to drop from Section 4, not Section 3. VTP pruning also affects Section 4.

5. A syslog message reads: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/2 (1), with NetsTuts_SW2 GigabitEthernet0/1 (99). What is the security risk and the correct fix?

Correct answer is D. The native VLAN mismatch is both a functional problem and a security risk. Functionally: any untagged frame arriving on SW1's Gi0/2 is assumed to be VLAN 1 traffic by SW1, but when SW2 receives that same untagged frame on Gi0/1 it assigns it to VLAN 99 — its native VLAN. This silently moves traffic between VLANs. Security risk: a VLAN hopping attack can exploit this — an attacker connected to a VLAN 1 access port on SW1 sends untagged frames which SW2 places into VLAN 99, potentially reaching hosts and services that should be in a separate security zone. Disabling CDP (Option C) hides the symptom but does not fix the underlying mismatch. The correct fix is to align both ends using switchport trunk native vlan and ideally use a dedicated native VLAN that is never assigned to any access port. See also DHCP Snooping & DAI for complementary Layer 2 security.

6. R1 has sub-interfaces Gi0/0.10 (192.168.10.1) and Gi0/0.20 (192.168.20.1), both showing up/up. Hosts in VLAN 10 and VLAN 20 cannot reach their gateways. show interfaces GigabitEthernet0/1 switchport on SW1 shows Administrative Mode: static access. What is wrong and how is it fixed?

Correct answer is B. Router-on-a-Stick depends entirely on the connected switch port being a trunk. The router sub-interfaces use encapsulation dot1Q [vlan-id] to identify which VLAN each sub-interface belongs to — they expect to receive 802.1Q-tagged Ethernet frames where the tag matches their configured VLAN ID. When the switch port is an access port, it strips all VLAN tags and sends only untagged frames for a single VLAN (typically VLAN 1). The router sub-interfaces for VLANs 10 and 20 never receive any frames because no 802.1Q-tagged frames arrive. The parent physical interface (Gi0/0) and sub-interfaces show up/up because Layer 1 is healthy and IOS keeps sub-interfaces up as long as the parent is up — this is the deceptive part of this fault. The router configuration is correct; only the switch port mode needs to change. Verify with ping 192.168.10.1 after the fix.

7. show interfaces trunk on SW1 shows VLAN 50 in Section 3 (active) but not in Section 4 (forwarding state). What are the two most likely causes?

Correct answer is C. Section 4 of show interfaces trunk applies two additional filters beyond Section 3: Spanning Tree Protocol state and VTP pruning. A VLAN that passes all the way to Section 3 (exists and is allowed) but disappears in Section 4 has been stopped by one of these two mechanisms. STP blocking: if this port is not the designated or root port for VLAN 50's spanning tree instance, STP may have placed it in blocking state to prevent a loop — show spanning-tree vlan 50 will show the port role (Root, Designated, Alternate, or Backup). VTP pruning: if VTP is in server/client mode and VTP pruning is enabled, VTP may have pruned VLAN 50 from this trunk because no ports in VLAN 50 exist on the downstream switch — this is intentional bandwidth optimisation. For PortFast and BPDU Guard context on access ports, see the dedicated guide.

8. What is the purpose of switchport nonegotiate, and why should it be configured on both inter-switch trunk ports and access ports facing end devices?

Correct answer is A. DTP (Dynamic Trunking Protocol) is a Cisco proprietary protocol that negotiates trunk formation. While convenient, DTP is also a security vulnerability: a malicious device connected to a switch port can send DTP frames claiming to be a switch and negotiate a trunk, gaining 802.1Q tagged access to all VLANs on the switch — a DTP-based VLAN hopping attack. switchport nonegotiate stops the switch from sending or responding to DTP frames on that port, eliminating the attack surface. For inter-switch trunks, mode trunk + nonegotiate creates a static trunk that does not advertise DTP. Complement this with Port Security and DHCP Snooping & DAI on access ports for comprehensive Layer 2 security.

9. A VLAN 10 SVI (interface vlan 10) on a Layer 3 switch shows as "down/down" in show ip interface brief even though VLAN 10 exists in the VLAN database and several access ports are assigned to it. What is the most likely cause?

Correct answer is D. A Layer 3 switch SVI (Switched Virtual Interface) behaves differently from a routed physical interface. An SVI represents a VLAN at Layer 3 — it is only meaningful when the VLAN has active Layer 1/2 connectivity. IOS brings an SVI up only when at least one physical port in that VLAN is in the up/up state. If all access ports in VLAN 10 are physically disconnected, err-disabled (e.g., due to port security violation), or administratively shut, the SVI has no active VLAN membership to represent and stays down/down. Fix: ensure at least one Fa or Gi access port in VLAN 10 is up/up. SVIs do not need no shutdown explicitly — they come up automatically when the VLAN has active members. See Layer 3 Switch Routing.

10. An engineer needs to verify which VLANs are actually forwarding traffic across a specific trunk, and why VLAN 60 is not crossing it despite being listed in show vlan brief. What is the correct sequence of diagnostic commands and what does each reveal?

Correct answer is C. This is the complete Layer 2 VLAN trunk diagnostic workflow. The four sections of show interfaces trunk are a structured elimination process: Section 1 establishes that the trunk itself is operational; Section 2 identifies whether the VLAN was explicitly removed from the allowed list (the most common cause of a specific VLAN failing on an otherwise healthy trunk); Section 3 identifies whether the VLAN exists on this switch (the second most common cause — VLAN created on one switch but not the other; see VLAN Creation and Management); Section 4 identifies STP or VTP-related suppression. The fact that VLAN 60 appears in show vlan brief means it exists locally, so Section 3 would pass — this narrows the search to Section 2 (allowed list) or Section 4 (STP/VTP). After confirming the fix, verify end-to-end with ping.