Trunks, Native VLANs & 802.1Q

Trunk

A switch link that can carry traffic for multiple VLANs across one physical interface.

802.1Q

The common Ethernet tagging standard that inserts VLAN information into frames so switches can preserve VLAN identity across trunk links.

Tagged VLAN

A VLAN whose frames cross the trunk with an 802.1Q tag identifying their VLAN membership.

Native VLAN

The VLAN associated with untagged traffic on an 802.1Q trunk. Native VLAN behavior must match on both ends of the link.

Allowed VLAN list

The set of VLANs permitted to cross a trunk. Restricting the list can reduce unnecessary Layer 2 exposure.

Trunk mismatch

A condition where two ends disagree about trunk mode, native VLAN, or allowed VLANs and cause connectivity or security problems.

Frame enters on an access port

A workstation sends a normal Ethernet frame into its assigned access VLAN.

Switch associates the frame with a VLAN

The access port tells the switch which VLAN the frame belongs to.

Frame reaches the trunk

If the destination path crosses another switch, the frame must traverse a trunk.

802.1Q preserves VLAN identity

The switch tags the frame for its VLAN unless the traffic belongs to the trunk's native VLAN.

Remote switch reads the tag

The receiving switch uses the VLAN tag to place the frame back into the correct VLAN context.

Frame exits through the correct local port

The remote switch forwards the frame toward the destination access port in the same VLAN.

TPID

Identifies the presence of an 802.1Q tag in the Ethernet frame.

Priority information

Includes quality-of-service related bits used for traffic priority.

DEI

Provides drop-eligibility information in the tag.

VLAN ID

Identifies which VLAN the frame belongs to on the trunk.

Display active trunk interfaces, native VLAN, allowed VLANs, and forwarding VLAN state.

Inspect administrative and operational switchport mode, native VLAN, and trunk properties on one interface.

Review the exact configuration on the suspected trunk.

Confirm required VLANs exist locally on the switch.

Observe learned MAC addresses and whether remote VLAN devices appear through the expected trunk.

Check whether spanning-tree state allows forwarding for the VLAN across the intended path.

Identify connected Cisco neighbors and interface relationships where CDP is enabled.

Review physical link state and identify interfaces operating as trunks or access links on supported platforms.

Verify the peer

Confirm the interface really connects to the expected switch or infrastructure device.

Inspect current trunk state

Check administrative mode, operational mode, native VLAN, and negotiated behavior.

Inspect active trunks

See which interfaces are actually trunking and what VLANs are carried.

Enter the interface

Work only on the confirmed infrastructure link.

Set trunk mode

Configure the interface as a static trunk on platforms that support this command.

Restrict allowed VLANs

Permit only the VLANs the topology actually requires.

Set native VLAN if required

Use only when the design explicitly calls for a specific native VLAN and both ends will match.

Verify both ends

Confirm trunk state, allowed VLANs, native VLAN, and forwarding behavior on both switches.

Allowed does not mean active

A VLAN can be permitted on the trunk but still not exist or be active on the local switch.

Active does not mean forwarding

A VLAN can exist and be allowed yet still be blocked by spanning-tree or another condition.

More is not always better

Allowing every VLAN across every trunk increases unnecessary broadcast reach and expands the impact of mistakes.

Restrict carefully

Removing a required VLAN from the allowed list can disconnect an entire segment across the trunk.

Verify both directions

A trunk configuration must be logically compatible at both ends. Inspect both devices where possible.

Document dependencies

Before pruning a VLAN, identify downstream access ports, gateways, services, management paths, and wireless or virtualization dependencies.

Untagged traffic

On a standard 802.1Q trunk, traffic belonging to the native VLAN is commonly sent untagged unless platform settings alter that behavior.

Both ends must agree

If one end uses native VLAN 99 and the other uses native VLAN 1, untagged frames can be interpreted as different VLANs.

Mismatch warnings matter

Cisco devices may report native VLAN mismatches through CDP or logs, which is valuable troubleshooting evidence.

Native VLAN is not automatically management

Some designs use a dedicated management VLAN, but the native VLAN role is separate from the question of management addressing.

Avoid assumptions about VLAN 1

Default behavior often involves VLAN 1, but the scenario may intentionally use another native VLAN.

Do not change one side alone

Changing native VLAN on only one trunk endpoint can create immediate inconsistency.

Operational trunk

The interface is actively carrying multiple VLANs as a trunk.

Administrative trunk, not operational trunk

The local configuration expects a trunk, but link state or peer configuration prevents active trunking.

Access mode

The interface carries one access VLAN and is not functioning as a trunk.

Dynamic mode

Some Cisco switch platforms support negotiation-based modes. Static trunk or access settings are often clearer in controlled competition environments.

Vlans allowed on trunk

The configured allowed list. These VLANs are permitted in principle.

Vlans allowed and active

The subset that is both allowed and present/active locally.

Vlans in spanning tree forwarding state and not pruned

The VLANs currently eligible to forward across that trunk.

Native VLAN

The VLAN associated with untagged traffic on that trunk.

Add VLAN 40 to an existing allowed list without replacing the entire list on supported IOS versions.

Remove VLAN 40 from the allowed list on supported IOS versions.

Set the allowed list to exactly the VLANs shown, replacing the previous list.

Permit all supported VLANs across the trunk.

Trunking and spanning-tree interact

A VLAN can be correctly configured on a trunk yet still not forward on that interface if spanning-tree blocks the path.

Blocked is not broken

Spanning-tree blocking can be intentional loop prevention rather than a fault.

Check per VLAN when supported

Different VLANs can have different spanning-tree states depending on platform and mode.

Do not force forwarding blindly

Changing spanning-tree simply because a trunk port is blocked can create loops and widespread outages.

Dynamic Trunking Protocol

Some Cisco switches can negotiate trunk formation using DTP.

Dynamic auto

A passive mode that can form a trunk if the peer actively negotiates.

Dynamic desirable

An active mode that attempts to form a trunk with a compatible peer.

Static mode is easier to audit

In controlled lab and competition environments, explicit access or trunk configuration often reduces ambiguity.

Platform support varies

Packet Tracer models and modern switch families may expose different DTP commands and defaults.

Minimize unnecessary VLAN carriage

A trunk should carry the VLANs required by the topology, not every VLAN by default when tighter scope is practical.

Keep unused access ports out of trunk mode

Endpoint ports should not accidentally negotiate or operate as trunks.

Protect management paths

If the management VLAN must cross a trunk, verify it deliberately because removing it can lock out remote administration.

Do not rely on native VLAN changes alone

Changing the native VLAN is not a substitute for broader switch security and proper allowed-VLAN design.

Static roles reduce ambiguity

Explicitly configured access and trunk roles are easier to audit than relying on dynamic negotiation.

Verify before saving

A trunk change can impact many VLANs, so test required paths before persisting the configuration.

VLAN 10 works across the trunk but VLAN 20 does not

Verify VLAN 20 exists on both switches, is allowed on the trunk, is active, and is not blocked by spanning-tree.

No VLANs work across an expected inter-switch link

Check physical state, operational trunk mode, peer configuration, encapsulation support, and whether the wrong interface was configured.

Hosts in the same VLAN work locally on each switch but not across switches

Inspect the trunk, allowed VLAN list, VLAN existence, and spanning-tree state for that VLAN.

CDP reports a native VLAN mismatch

Compare native VLAN configuration on both ends before changing either side.

One trunk carries unexpected VLANs

Review the allowed VLAN list and confirm which downstream dependencies actually require those VLANs.

A trunk is up but MAC addresses for one remote VLAN never appear

Check allowed/active VLAN state, downstream endpoint activity, VLAN presence, and whether spanning-tree is forwarding.

VLAN 10 works across SW1-SW2, but VLAN 20 hosts only work locally.

show interfaces trunk lists VLAN 30 as allowed but not active.

One side uses native VLAN 99 and the other uses native VLAN 1.

An endpoint port unexpectedly appears as a trunk.

A teammate wants to use allowed vlan all to fix a missing VLAN.

A trunk is operational, but the management subnet becomes unreachable after pruning VLANs.

Peer role

Both ends of the link are intended infrastructure peers.

Operational mode

The interface is actually trunking, not merely configured to try.

Native VLAN

Both ends use the same native VLAN according to the design.

Allowed VLANs

Every required VLAN is permitted and unnecessary VLANs are not carried without reason.

Active VLANs

Required VLANs exist and are active on the relevant switches.

Spanning-tree

Required VLANs are forwarding across the intended path.

MAC learning

Remote endpoint MAC addresses appear through the expected trunk.

End-to-end traffic

Same-VLAN hosts communicate across switches and required management remains reachable.