Configure Allowed VLANs on Cisco Trunk Ports

Learn how to restrict, add, remove, verify, and troubleshoot allowed VLANs on Cisco switch trunk ports, including EtherChannel considerations.

A Cisco trunk can carry traffic for multiple VLANs between switches and other VLAN-aware devices. An allowed VLAN list controls which VLAN IDs may cross one specific trunk. This lesson covers Cisco IOS configuration, verification, two-sided requirements, EtherChannel behavior, and common recovery procedures.

Why Restrict VLANs on a Trunk?

A VLAN is a logical Layer 2 network segment that creates a separate broadcast domain. An access port normally carries traffic for one assigned VLAN and connects to an endpoint such as a computer, printer, or server.

A trunk port carries traffic for multiple VLANs. Trunks are commonly used between switches, routers, firewalls, wireless access points, and other VLAN-aware devices. IEEE 802.1Q adds VLAN identification information to frames crossing the trunk, allowing the receiving device to associate each frame with the correct VLAN.

By default, a trunk may permit many or all VLANs supported by the platform. The allowed VLAN list narrows that behavior. For example, an uplink may need to carry only user VLAN 10, voice VLAN 20, server VLAN 30, and management VLAN 99.

It reduces unnecessary VLAN propagation.
It supports segmentation and operational control.
It makes the intended VLAN path easier to document and troubleshoot.
It limits accidental extension of VLANs to switches or devices that do not need them.

Trunking Fundamentals

802.1Q Tags and the Native VLAN

On an 802.1Q trunk, most Ethernet frames are identified with a VLAN ID in an 802.1Q tag. The native VLAN is the VLAN associated with untagged frames on the trunk. Both ends of a trunk should use the same native VLAN unless a specific design intentionally uses another compatible arrangement.

A native VLAN mismatch can cause traffic to be placed into the wrong VLAN, produce switch warnings, and create connectivity or security problems. Correct allowed VLAN settings do not eliminate native VLAN mismatch problems.

VLAN ID Ranges

Cisco switches commonly use VLAN IDs from 1 through 4094. VLANs 1 through 1005 are generally called the normal range, while VLANs 1006 through 4094 are generally called the extended range. Exact support and configuration behavior depend on the switch platform, software release, and VLAN database mode. Always confirm platform-specific restrictions before using extended-range VLANs.

Two Ends Must Permit the VLAN

For a VLAN to cross an inter-switch trunk successfully, the VLAN must be permitted on both connected interfaces, and the VLAN must exist and be active where required. If either end blocks VLAN 40, VLAN 40 traffic cannot cross that link.

Configuration Workflow

Identify the VLANs that must cross the link. Consider user, voice, management, wireless, routing, and service requirements.
Confirm that each required VLAN exists locally and is active.
Identify the physical trunk interfaces and the devices connected at both ends.
Apply matching or intentionally compatible trunk and allowed VLAN policies on both ends.
Save the configuration.
Verify trunk mode, native VLAN, allowed VLANs, active VLANs, and forwarding VLANs.
Test connectivity for hosts in every intended VLAN.

Configure a Static Trunk and Allowed VLAN List

The following example creates VLANs and restricts a trunk to VLANs 10, 20, 30, and 99. VLAN 999 is used as the native VLAN in the example; the native VLAN must be configured consistently on the connected device.

configure terminal
vlan 10
 name USERS
vlan 20
 name VOICE
vlan 30
 name SERVERS
vlan 99
 name MANAGEMENT
end

configure terminal
interface gigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,99
end
copy running-config startup-config

The comma-separated syntax permits individual VLAN IDs. A hyphen specifies a contiguous range.

configure terminal
interface gigabitEthernet1/0/2
 switchport mode trunk
 switchport trunk allowed vlan 100-110,999
end

The command without add or remove replaces the current allowed VLAN list. This behavior is a frequent source of outages.

Allowed VLAN Command Behavior

Command form	Effect on current allowed VLAN list	Typical use case	Risk or caution
`switchport trunk allowed vlan 10,20,30`	Replaces the existing list with the specified list.	Set a complete, known policy.	Previously allowed VLANs are removed unless included again.
`switchport trunk allowed vlan add 40`	Appends VLAN 40 to the existing list.	Add a newly deployed wireless or service VLAN.	Still verify that the VLAN is needed on this trunk and exists locally.
`switchport trunk allowed vlan remove 30`	Removes VLAN 30 from the existing list.	Decommission a VLAN after confirming dependencies.	Removing a management VLAN can cause remote lockout.
`switchport trunk allowed vlan except 50,60`	Allows all applicable VLANs except the specified VLANs.	Exclude a small number of known VLANs.	Future VLANs may become permitted automatically, which may conflict with least-privilege design.
`switchport trunk allowed vlan all`	Permits all supported VLANs for the trunk.	Restore the platform's all-VLAN behavior during recovery or testing.	It may propagate VLANs that have no business requirement on the link.
`switchport trunk allowed vlan none`	Prevents normal user VLANs from forwarding where supported.	Temporarily disable normal VLAN forwarding on a trunk.	Support and behavior are platform-specific; verify the result before relying on it.

Add, Remove, and Restore VLAN Permissions

Add a VLAN Without Replacing Existing Entries

Use the add keyword when introducing VLAN 40 to an existing policy.

configure terminal
interface gigabitEthernet1/0/1
 switchport trunk allowed vlan add 40
end

Remove a VLAN

Remove VLAN 30 only after confirming that no endpoint, access switch, routed service, or management function still requires it.

configure terminal
interface gigabitEthernet1/0/1
 switchport trunk allowed vlan remove 30
end

Restore Permissions After an Accidental Overwrite

If an administrator accidentally replaced the list, restore the complete intended list explicitly or add the missing VLANs.

configure terminal
interface gigabitEthernet1/0/1
 switchport trunk allowed vlan 10,20,30,40,99
end

Using all can restore broad forwarding during recovery, but it should be followed by a review and replacement with the intended restricted policy.

configure terminal
interface gigabitEthernet1/0/1
 switchport trunk allowed vlan all
end

Verification Commands

show interfaces trunk
show interfaces gigabitEthernet1/0/1 switchport
show running-config interface gigabitEthernet1/0/1
show vlan brief
show etherchannel summary

show interfaces trunk

This command is the primary trunk summary. It can show trunk status and mode, encapsulation, native VLAN, the configured allowed list, VLANs that are both allowed and active, and VLANs currently in a forwarding state.

Output field	Meaning	What to verify	Possible problem indication
Status	Whether the interface is operationally trunking.	The link is up and operating as a trunk.	The interface may be down, an access port, or failing trunk negotiation.
Encapsulation	The trunk tagging method, normally 802.1Q.	The expected encapsulation is in use.	An incompatible or unexpected encapsulation may prevent trunk operation.
Native VLAN	VLAN used for untagged trunk frames.	It matches the remote endpoint and design.	A mismatch can cause warnings and misclassified traffic.
VLANs allowed on trunk	The configured filter list.	Every required VLAN is present.	A missing VLAN is blocked on this interface.
VLANs allowed and active	Allowed VLANs that are also present and active locally.	Required VLANs appear here.	A configured VLAN may not exist or may be inactive.
VLANs in spanning-tree forwarding state	Allowed and operational VLANs that can forward on this link.	Required VLANs are forwarding on this path.	Spanning Tree or another Layer 2 condition may prevent forwarding.

Other Verification Commands

show interfaces gigabitEthernet1/0/1 switchport displays administrative and operational mode, encapsulation, native VLAN, and allowed VLAN information for one interface.
show running-config interface gigabitEthernet1/0/1 confirms the commands currently in the running configuration. It does not by itself prove that the VLAN is active or forwarding.
show vlan brief confirms that VLANs exist and shows their active status and access-port assignments.
show etherchannel summary checks whether a port-channel is formed and whether member links are bundled.

A VLAN can appear in the configured allowed list but not in the active list if it does not exist locally, is inactive, or is not recognized by the platform. It can be active but absent from the forwarding list because of Spanning Tree topology, a failed link, or a remote-side restriction.

Matching Trunk Policies Across Devices

Connected switches do not necessarily need textually identical configurations, but they must be operationally compatible. A VLAN blocked on either end cannot pass. If Switch A allows VLANs 10, 20, and 30 while Switch B allows only 10 and 20, VLAN 30 traffic stops at that link.

Compare the allowed lists on both ends.
Compare native VLAN settings.
Confirm that both interfaces are operational trunks.
Check every trunk segment when the path includes several switches.
Keep redundant paths and distribution-layer links consistent with the topology design.

Allowed VLANs with EtherChannel

An EtherChannel combines multiple physical links into one logical connection, usually represented by a port-channel interface. Member links should have consistent Layer 2 settings, including trunk mode, native VLAN, allowed VLAN list, and channel parameters.

According to platform practice, configure and verify the trunk policy on the logical port-channel interface, while ensuring that member interfaces have compatible settings.

configure terminal
interface port-channel 1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,99
end
show etherchannel summary
show interfaces trunk

Inconsistent settings can prevent links from bundling or cause unexpected traffic behavior. Compare member interfaces if the channel does not form correctly.

Operational and Security Considerations

Allow only VLANs with a documented need to cross a trunk.
Avoid using the default VLAN for production user traffic when organizational policy calls for a dedicated VLAN.
Use a dedicated, unused native VLAN when required by the design, and configure it consistently on both ends.
Document trunk policies and update every required trunk when introducing a new VLAN.
Protect management VLAN availability before pruning or changing uplinks.
Remember that an allowed VLAN list is not a complete security boundary. Combine it with correct access-port configuration, routing policy, authentication, and other Layer 2 and Layer 3 controls.

Common Mistakes and Recovery

Symptom	Likely cause	Verification step	Corrective action
One VLAN has no connectivity	The VLAN is missing from one trunk, inactive, or blocked by Layer 2 topology.	Check `show interfaces trunk` on both ends and `show vlan brief`.	Allow and activate the VLAN as required, then check forwarding state.
Remote management is unreachable	The management VLAN was removed from an uplink.	Identify the management VLAN and inspect the uplink allowed list.	Use console or an alternate path, then reallow the management VLAN.
New VLAN works locally but not across switches	The VLAN was not allowed on every trunk in the path.	Trace the VLAN across each trunk and compare both endpoints.	Use `switchport trunk allowed vlan add` on each required trunk.
Port-channel does not bundle correctly	Member trunk settings are inconsistent.	Use `show etherchannel summary` and compare mode, native VLAN, and allowed VLANs.	Make Layer 2 settings consistent and apply the intended policy to the port-channel.
Native VLAN mismatch warning	The two trunk endpoints use different native VLAN IDs.	Compare native VLAN output on both interfaces.	Configure the same intended native VLAN on both ends.

Accidental Replacement of the Allowed List

Forgetting add replaces the previous list. Review the running configuration and compare it with the intended policy. Restore the complete list explicitly, or add the missing VLANs.

Wrong Interface or Access Port

The allowed VLAN command belongs on a trunk interface. If it is applied to the wrong interface, the intended uplink remains unchanged. Confirm the interface identifier, neighbor connection, operational mode, and cabling before making changes.

End-to-End Troubleshooting Example

Suppose VLAN 40 hosts communicate with one another on a local switch but cannot reach devices beyond the uplink. Check VLAN 40 on every trunk in the path, confirm that it exists and is active on the relevant switches, inspect the forwarding VLAN list, and verify the far-end trunk. Add VLAN 40 to each required trunk, then test the host-to-gateway and host-to-destination paths.

Exam-Relevant Notes

An access port normally carries one VLAN; a trunk carries multiple VLANs.
The allowed VLAN list filters VLAN traffic on a specific trunk.
A VLAN must be permitted on every trunk segment in its path.
A new explicit allowed list replaces the old list unless add is used.
add appends entries and remove deletes entries.
Configured, active, and forwarding VLAN lists describe different conditions.
Native VLAN settings must be compatible at both ends.
EtherChannel members require consistent Layer 2 settings.