Configure Trunk Ports on Cisco Switches

In switched networks, connecting multiple VLANs across devices often requires efficient links that can handle traffic from different segments without needing a separate cable for each one. A trunk port serves this role by allowing frames from various VLANs to travel over a single connection, using tagging to keep them separated. Cisco switches support this through protocols like the industry-standard 802.1Q or their older proprietary ISL. We’ll walk through setting up an 802.1Q trunk between two Catalyst switches, starting with VLAN setup, port assignments, and trunk configuration, while exploring the different modes ports can operate in.

Essential Concepts

Trunks streamline network design by multiplexing VLAN traffic on one physical interface. This avoids the mess of running individual links for every VLAN, which would quickly become unmanageable in larger setups. The 802.1Q method inserts a 4-byte tag into the Ethernet frame to identify the VLAN, while ISL wraps the entire frame in a new header. For compatibility and best practices, 802.1Q is the go-to choice today. Understanding these basics helps when troubleshooting connectivity issues in segmented networks.

Key Points to Remember

  • Trunks bundle multiple VLANs onto a single link using either 802.1Q or ISL encapsulation.
  • On switches that support multiple encapsulation types, specify 802.1Q with the switchport trunk encapsulation dot1q command before enabling trunk mode.
  • Verify your setup with show interfaces trunk to check operational status, encapsulation type, native VLAN, and permitted VLANs.
  • In dynamic auto mode, the port stays in access unless the connected device pushes for a trunk.
  • Dynamic desirable mode proactively tries to establish a trunk with the neighbor.
  • Stick to explicit trunk configuration in real environments to prevent unexpected behavior and enhance security.
  • A mismatch—like one end as access and the other as trunk—can trigger spanning tree protocol errors, potentially blocking the port temporarily.

Before You Start

To follow along, you should already know the fundamentals of VLANs and how to set them up on Catalyst switches. If you’re new to networking layers, reviewing the (“Introduction to the OSI Model“) can clarify how Layer 2 switching fits into the bigger picture.

Setting It Up

Let’s use a simple setup with two Catalyst switches, SW1 and SW2, linked together. SW1 connects to host H1, and SW2 to host H2. Our aim is to put both hosts in the same VLAN 20 and ensure the link between the switches carries that traffic via a trunk.

Configure Trunk

Creating VLAN 20 on Each Switch

Begin by defining the VLAN on SW1:

SW1(config)#vlan 20
SW1(config-vlan)#name Computers
SW1(config-vlan)#exit

Do the same on SW2:

SW2(config)#vlan 20
SW2(config-vlan)#name Computers
SW2(config-vlan)#exit

This step establishes VLAN 20, labeled “Computers,” on both devices. Without it, the switches won’t recognize the segment, and any ports assigned to it would fail to forward traffic properly.

Assigning Ports to VLAN 20

Next, configure the host-facing ports as access ports in VLAN 20. On SW1, for the interface to H1:

SW1(config)#interface fa0/1
SW1(config-if)#switchport access vlan 20

On SW2, for the interface to H2:

text

SW2(config)#interface fa0/2
SW2(config-if)#switchport access vlan 20

Access ports are straightforward—they belong to one VLAN and don’t tag frames. This ensures H1 and H2 send untagged traffic into VLAN 20. Remember, when devices communicate in the same VLAN across switches, the trunk will handle the tagging automatically.

Enabling the Trunk Link

Now, focus on the connection between SW1 and SW2, say on interface fa0/10. Trying to set it to trunk mode right away might hit a snag:

SW1(config)#interface fa0/10
SW1(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is "Auto" can not be configured to "trunk" mode.

The same happens on SW2. This error pops up because the switch defaults to negotiating encapsulation, and it won’t let you force trunk mode without specifying one first.

Choosing 802.1Q Encapsulation

Check your options with:

SW1(config-if)#switchport trunk encapsulation ?
  dot1q      Interface uses only 802.1q trunking encapsulation when trunking
  isl        Interface uses only ISL trunking encapsulation when trunking
  negotiate  Device will negotiate trunking encapsulation with peer on interface

Set it to 802.1Q on both ends:

SW1(config-if)#switchport trunk encapsulation dot1q

And on SW2:

SW2(config-if)#switchport trunk encapsulation dot1q

802.1Q is preferred because it’s open standard and works with non-Cisco gear. It adds a tag to the Ethernet frame, including fields like the Tag Protocol Identifier (TPID) set to 0x8100, Priority Code Point for QoS, Canonical Format Indicator, and the 12-bit VLAN ID. This tag ensures switches can demultiplex the traffic correctly. For deeper insight into frame structures, consider how this relates to Layer 3 headers in the Understanding the IPv4 Packet Header.

Confirming the Encapsulation Change

Run this on SW1:

SW1#show interfaces fa0/10 switchport
Name: Fa0/10
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q

You’ll see similar output on SW2. Notice the encapsulation is now dot1q, but the mode hasn’t shifted yet—it’s still set to dynamic auto, defaulting to access.

Activating Trunk Mode

With encapsulation sorted, enable the trunk:

SW1(config)#interface fa0/10
SW1(config-if)#switchport mode trunk

Repeat on SW2. Now verify:

SW1#show interfaces fa0/10 switchport
Name: Fa0/10
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q

Both sides should match, confirming the trunk is up with 802.1Q in action. At this point, the link can carry tagged frames for multiple VLANs.

Checking Connectivity

From H1, ping H2 (assuming IPs like 192.168.1.1 and 192.168.1.2):

C:\>ping 192.168.1.2
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128

Success means the trunk is working, allowing VLAN 20 traffic to cross. Behind the scenes, when H1 sends a frame, SW1 tags it on the trunk, and SW2 strips the tag before forwarding to H2. If the ping fails initially, it might involve address resolution—check out the understanding Address Resolution Protocol (ARP) for how MAC addresses are discovered in this process.

Useful Show Commands

Viewing VLAN Assignments

Use show vlan on SW2:

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/3, ..., Fa0/24, Gi0/1, Gi0/2
20   Computers                        active    Fa0/2

Trunk ports won’t show here since this command lists only access ports per VLAN. It’s a quick way to confirm your access assignments.

Inspecting Trunk Details

Try show interfaces trunk or specifically show interfaces fa0/10 trunk:

text

Port        Mode             Encapsulation  Status        Native vlan
Fa0/10      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/10      1-4094

Port        Vlans allowed and active in management domain
Fa0/10      1,20

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/10      20

This breaks down the mode (“on” for active trunking), encapsulation, native VLAN (untagged, default 1), all allowed VLANs, active ones in the config, and those forwarding without pruning. Pruning removes unused VLANs to optimize bandwidth, a key STP feature.

Switchport Status for Access Ports

For the host port on SW2:

SW2#show interfaces fa0/2 switchport
Name: Fa0/2
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access

Compare to the trunk:

Administrative Mode: trunk
Operational Mode: trunk

This highlights the difference—access for single VLAN, trunk for multiples.

Available Port Modes

Query with switchport mode ?:

access        Set trunking mode to ACCESS unconditionally
dot1q-tunnel  set trunking mode to TUNNEL unconditionally
dynamic       Set trunking mode to dynamically negotiate access or trunk
private-vlan  Set private-vlan mode
trunk         Set trunking mode to TRUNK unconditionally

Under dynamic:

auto       Set trunking mode dynamic negotiation parameter to AUTO
desirable  Set trunking mode dynamic negotiation parameter to DESIRABLE

These options control how the port behaves during negotiation.

Exploring Dynamic Negotiation Modes

To see how ports decide their role, we’ll test combinations on fa0/10 between SW1 and SW2, observing with show interfaces switchport.

Both in Dynamic Auto

Set:

SW1(config-if)#switchport mode dynamic auto
SW2(config-if)#switchport mode dynamic auto

Outcome: Both end up as static access. Dynamic auto is passive—it won’t initiate a trunk, so they default to access.

Both in Dynamic Desirable

Configure:

SW1(config-if)#switchport mode dynamic desirable
SW2(config-if)#switchport mode dynamic desirable

Result: Trunk forms, operational mode trunk. Desirable actively negotiates, and since both want it, they agree.

Desirable on One, Auto on the Other

SW1(config-if)#switchport mode dynamic desirable
SW2(config-if)#switchport mode dynamic auto

Trunk establishes. The desirable side convinces the auto side to switch.

Auto on One, Trunk on the Other

SW1(config-if)#switchport mode dynamic auto
SW2(config-if)#switchport mode trunk

Trunk up. Auto accepts the fixed trunk proposal.

Auto on One, Access on the Other

SW1(config-if)#switchport mode dynamic auto
SW2(config-if)#switchport mode access

Both become access. No trunk push, so auto follows suit.

Desirable on One, Trunk on the Other

SW1(config-if)#switchport mode dynamic desirable
SW2(config-if)#switchport mode trunk

Trunk forms easily. Compatible intents.

Access on One, Trunk on the Other

SW1(config-if)#switchport mode access
SW2(config-if)#switchport mode trunk

SW1 stays access, SW2 trunk. But SW1 logs STP issues:

%SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/10 VLAN1.
%SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/10 on VLAN0001. Inconsistent port type.
%SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/10 on VLAN0001. Port consistency restored.

The access port gets tagged BPDUs it doesn’t expect, causing a brief block until STP resolves it. Avoid this in practice to prevent loops or outages.

In IP-based networks, understanding these Layer 2 mechanics ties into higher protocols—see the Introduction to Internet Protocol (IP) Version 4 for how packets traverse these setups.

Lets summarize this all into a table:

Port ModeTrunkAccessDynamic AutoDynamic Desirable
TrunkTrunkLimitedTrunkTrunk
AccessLimitedAccessAccessAccess
Dynamic AutoTrunkAccessAccessTrunk
Dynamic DesirableTrunkAccessTrunkTrunk

Wrapping Up

Configuring trunks involves creating VLANs, setting access ports, choosing encapsulation like 802.1Q, and enabling trunk mode explicitly for reliability. Dynamic modes like auto and desirable can automate this but introduce risks in production—better to hard-set trunks. Leverage show commands for verification to spot mismatches early.

Leave a Comment

Your email address will not be published. Required fields are marked *

Download Your Cheat Sheet
Enter your email to get instant access to this cheat sheet. We'll also notify you when new cheat sheets are released.
No spam, ever. Your email is stored securely and never shared.