A VLAN trunk can look perfectly healthy while users experience intermittent packet loss, DHCP failures, or connectivity problems between network segments.
The interface is up. The link light is green. The trunk appears to be forwarding traffic.
Yet something is wrong.
In real-world network operations, these problems are often caused by configuration inconsistencies, VLAN mismatches, spanning-tree behavior, or MTU issues rather than a failed switch.
Here is a practical, layer-by-layer checklist I use to narrow down VLAN trunk problems without making unnecessary configuration changes.
1. Confirm That the Physical Link Is Actually Healthy
Start with the basics.
Check both ends of the trunk for:
- Interface status and recent link flaps
- CRC and input errors
- Output drops and queue congestion
- Speed and duplex inconsistencies
- Optical power levels, if the link uses fiber
A trunk can remain operational while experiencing intermittent physical-layer errors.
Useful commands vary by vendor. On Cisco IOS, for example:
show interfaces
show interfaces counters errors
show logging
Look for counters that increase during the problem, not just counters that have accumulated over months.
If errors are increasing, investigate the physical link before changing VLAN configuration.
2. Verify the Allowed VLAN List on Both Ends
One of the easiest mistakes to overlook is an inconsistent allowed VLAN list.
For example:
Switch A: VLANs 10,20,30,40
Switch B: VLANs 10,20,30
VLAN 40 may work on one part of the network but fail to cross this trunk.
Check the effective allowed VLAN list on both sides. Also verify that the VLANs exist and are active where required.
On Cisco IOS:
show interfaces trunk
show vlan brief
Do not assume that configuring a VLAN globally means it is automatically permitted across every trunk.
3. Check Native VLAN or Untagged Traffic Behavior
Native VLAN behavior can create confusing symptoms, especially when devices on opposite ends of a trunk have different expectations about untagged frames.
For example:
Switch A: Native VLAN 10
Switch B: Native VLAN 20
Depending on the platform and configuration, this mismatch can result in traffic being classified into different VLANs or trigger a warning.
Check:
- Native VLAN configuration on both ends
- Whether untagged traffic is expected
- Whether the platform uses native VLAN tagging
- Whether the trunk configuration matches the network design
On Cisco IOS:
show interfaces trunk
show logging
Avoid changing the native VLAN simply to silence a warning. First establish which VLAN should carry untagged traffic, if any.
4. Investigate Spanning Tree
A trunk may be physically up but not forwarding traffic for a particular VLAN.
Spanning Tree Protocol can place a port into a blocking or alternate state to prevent Layer 2 loops.
Check the spanning-tree state for the affected VLAN rather than looking only at the physical interface status.
On Cisco IOS:
show spanning-tree vlan 10
show spanning-tree inconsistentports
Replace VLAN 10 with the affected VLAN.
Look for:
- A port in blocking or alternate state
- Unexpected topology changes
- Root bridge changes
- Inconsistent port states
- A recently introduced redundant link
Do not disable spanning tree as a troubleshooting shortcut. That can turn a localized connectivity problem into a Layer 2 loop.
5. Check MTU and Frame-Size Differences
MTU mismatches are particularly difficult to diagnose because small packets may work while larger packets fail.
Typical symptoms include:
- Applications connecting but transferring data unreliably
- Large pings failing while small pings succeed
- Problems appearing only on paths that cross specific links
- Encapsulated traffic failing unexpectedly
Check the configured MTU on the relevant interfaces and the maximum frame size supported along the entire path.
For IPv4, a basic ping test can help compare small and large packets.
Linux:
ping -M do -s 1472 <destination-ip>
Windows:
ping -f -l 1472 <destination-ip>
These examples test an IPv4 packet with a 1500-byte IP MTU when the 28 bytes of IPv4 and ICMP headers are included.
However, a failed test does not automatically prove an MTU mismatch. Firewalls may block ICMP, and some paths handle fragmentation or filtering differently.
Test progressively smaller payloads and compare results across the suspected path.
6. Verify MAC Learning and the Actual Forwarding Path
Sometimes the trunk is configured correctly, but traffic is not reaching the expected destination because of MAC learning or forwarding behavior.
Check:
- Whether the source MAC is learned in the correct VLAN
- Whether the destination MAC is present
- Whether the MAC address moves between ports unexpectedly
- Whether port security or other Layer 2 controls are dropping traffic
On Cisco IOS:
show mac address-table dynamic
show mac address-table dynamic vlan 10
If the MAC address appears on an unexpected interface, investigate the topology and forwarding path before clearing tables or restarting interfaces.
Clearing the MAC table may temporarily change symptoms without resolving the underlying problem.
7. Compare Both Ends and Capture Traffic if Necessary
If the previous checks do not explain the issue, compare the effective configuration on both ends of the trunk.
Pay particular attention to:
- Trunk mode and negotiation
- Allowed VLANs
- Native VLAN settings
- MTU
- Link aggregation membership, if applicable
- Spanning-tree state
- Interface counters
Then capture traffic at an appropriate observation point.
A packet capture can help answer three important questions:
- Does the frame arrive at the sending switch?
- Does it leave the trunk with the expected VLAN tagging?
- Does it arrive at the receiving switch?
A SPAN or mirror session can help, but remember that the capture point and switch platform affect what tags and frames you see.
If the frame leaves one switch but never appears at the next observation point, you have narrowed the problem considerably.rom the simplest and least disruptive checks toward deeper packet-level investigation.
| Order | Check | What It Helps Identify |
|---|---|---|
| 1 | Physical interface and counters | Link errors and instability |
| 2 | Allowed VLANs | Missing VLANs across the trunk |
| 3 | Native VLAN behavior | Untagged traffic inconsistencies |
| 4 | Spanning tree | VLAN-specific forwarding states |
| 5 | MTU and frame size | Large-packet failures |
| 6 | MAC address learning | Unexpected Layer 2 forwarding |
| 7 | Packet capture | Where frames disappear or change |
This order is a starting point, not a universal rule. If the symptoms clearly point to one layer, investigate that layer first.
Final Thoughts
A green interface does not guarantee a working VLAN trunk.
The most effective troubleshooting approach is to verify the physical link, compare both ends of the trunk, inspect forwarding state, and then follow the actual traffic path.
Most importantly, change one variable at a time and record the result. That makes the diagnosis repeatable and reduces the risk of introducing a second problem while trying to fix the first.
For more practical network engineering tools and troubleshooting resources, visit NetEngineerLab.
What is the most difficult VLAN trunk issue you have encountered in production?
Top comments (0)