CliDeck
PlatformLog in
Workspace

Cisco: How to Add a VLAN to a Trunk (IOS/IOS XE) — Fast Fix + Verification

Network Device Recovery
#cisco add vlan to trunk#switchport trunk allowed vlan add#Network Device Recovery#network-operations
← Back to Blog

Short answer

To add a VLAN to a Cisco IOS or IOS XE trunk, create or confirm the VLAN, add it to the interface’s allowed VLAN list, and verify both the trunk state and end-to-end connectivity. Avoid replacing the existing allowed list when the goal is to add only one VLAN.

Quick Answer (Safe Copy/Paste)

Add VLAN 10 to trunk interface Gi1/0/48 without overwriting the current list:

conf t
int gi1/0/48
 switchport mode trunk
 switchport trunk allowed vlan add 10
end
wr

Verify:

show interfaces trunk
show interfaces gi1/0/48 switchport

If you need to add multiple VLANs:

conf t
int gi1/0/48
 switchport trunk allowed vlan add 10,20,30
end
wr

Why VLANs “Disappear” on Trunks (The Real Reason People Get Stuck)

Most outages happen because someone uses:

switchport trunk allowed vlan 10

…and doesn’t realize this replaces the entire allowed list on many IOS/IOS XE setups (depending on how it’s already configured). That means VLAN 20/30/99 might silently stop passing. If you’re fixing something live, the word you want is add:

switchport trunk allowed vlan add 10

That’s the difference between “quick fix” and “why did half the building lose network.”

Step 1) Confirm You’re Editing the Right Interface

Find which port is actually trunking (especially helpful on stacks and uplinks):

show interfaces trunk

Look for the interface you care about (example: Gi1/0/48) and confirm it’s in trunk mode and up.

Step 2) Add a VLAN to the Trunk (The Safe Way)

Add a single VLAN

conf t
int gi1/0/48
 switchport trunk allowed vlan add 10
end
wr

Add multiple VLANs

conf t
int gi1/0/48
 switchport trunk allowed vlan add 10,20,30
end
wr

Add a VLAN range

conf t
int gi1/0/48
 switchport trunk allowed vlan add 100-110
end
wr

Step 3) Make Sure the VLAN Exists (Common Oversight)

If VLAN 10 is allowed on the trunk but the VLAN isn’t created locally, you’ll still get confusing behavior.

Check VLANs:

show vlan brief

Create it if needed:

conf t
vlan 10
 name USERS
end
wr

Important: Do this on both switches if the VLAN should pass end-to-end.

Step 4) Verify It’s Actually Passing (Not Just “Allowed”)

Verify trunk + allowed VLANs

show interfaces trunk

You want to see your VLAN under:

  • Allowed VLANs
  • and ideally also in the forwarding list (depending on STP state and topology)

Verify the interface mode and trunk details

show interfaces gi1/0/48 switchport

This helps catch situations where the port is not really trunking (or negotiated into something unexpected).

Common Problems and Fast Fixes

Problem: VLAN is allowed but traffic still doesn’t pass

Checklist:

  • VLAN exists on both sides (show vlan brief)
  • Trunk is up and trunking (show interfaces trunk)
  • VLAN is not being filtered elsewhere (port-channel config, vtp domain mismatch, or policy)

Problem: Native VLAN mismatch warnings

If your environment uses a native VLAN, set the same native VLAN on both ends:

conf t
int gi1/0/48
 switchport trunk native vlan 99
end
wr

If you do not intentionally use a native VLAN standard, don’t “randomly set one” to silence warnings—understand what your network expects first.

Problem: You accidentally overwrote the allowed list

If you used switchport trunk allowed vlan 10 and it broke other VLANs, you need to restore the previous list. If you don’t know it, check the running config (or your change history), then set the full list explicitly:

show running-config interface gi1/0/48

Then apply the correct full allowed list:

conf t
int gi1/0/48
 switchport trunk allowed vlan 10,20,30,99
end
wr

Problem: Port-channel (EtherChannel) trunks

If the link is in a Port-Channel, you usually need to set allowed VLANs on the Port-Channel interface (and keep members consistent). Start by checking trunk output and interface names:

show interfaces trunk
show etherchannel summary

Minimal Troubleshooting Cheatsheet

Run these and you’ll usually spot the issue in under a minute:

show interfaces trunk
show interfaces gi1/0/48 switchport
show vlan brief
show running-config interface gi1/0/48

FAQ

Do I need to add the VLAN to the trunk on both switches?

Yes. If there’s a trunk between SW1 and SW2, both ends must allow that VLAN (and the VLAN should exist where needed).

Should I allow all VLANs on a trunk?

In small labs it’s fine, but in real networks an explicit allow list is easier to audit and prevents surprises.

What’s the safest command if I’m not sure what’s already allowed?

Use:

switchport trunk allowed vlan add <VLAN>

It appends without wiping the existing list.

Real-world tip (why this keeps happening)

A trunk outage is rarely about “VLAN knowledge.” It’s usually about working under pressure: multiple tabs, multiple switches, and trying not to break what’s already live.

That’s why the best habit here is: change one thing, then verify immediately with show interfaces trunk. If you do it that way every time, you avoid the most expensive VLAN mistake: “I thought I added it, but I actually replaced the list.”

If you want, I can also generate a matching 2:3 hero image for this article in the same CliDeck blog style as the previous one.

Who this is for

This guide is for network engineers, operations teams, field technicians, and lab engineers who need to make and verify a controlled network configuration or recovery change on approved network devices inside a planned change or lab scope.

When to use this

Use this guide when:

  • The task is inside an approved change, recovery, lab, or troubleshooting scope.
  • You need a practical checklist before touching a production or customer device.
  • You need to verify the result and document what changed.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Workflow

  • Confirm device identity, access path, and approved scope.
  • Collect read-only baseline information before making changes.
  • Run only the commands or checks required for the task.
  • Verify the final state with commands, logs, or observable behavior.
  • Document the result, exceptions, and next action.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace can help keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace. Console Server Go is useful for portable rack-side console access, while Net Controller is better for repeatable multi-device processing and evidence-style results.

Related guides