DEV Community: NetEngineerLab

VLAN Trunk Troubleshooting: 7 Checks Before You Blame the Switch

NetEngineerLab — Wed, 28 Oct 2026 09:14:38 +0000

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?

networking #devops #cisco #networkengineering

Why Is One LACP Link at 100% While the Other Is Almost Idle?

NetEngineerLab — Sat, 24 Oct 2026 08:57:40 +0000

Imagine you have two 10 Gbps links bundled together using LACP.

The port-channel provides 20 Gbps of aggregate capacity. Both physical links are up, and the configuration looks correct.

Yet during peak traffic, one link is congested while the other is barely utilized.

Applications slow down. Packet drops increase. Meanwhile, your monitoring dashboard still shows spare bandwidth across the bundle.

What is going on?

The answer is that aggregate bandwidth does not guarantee balanced traffic distribution.

Let's examine a practical example and identify what network engineers should check before upgrading their uplinks.

1. Understanding the Topology

Consider this simple design:

           SWITCH A
               |
        +------+------+
        |             |
      10 Gbps       10 Gbps
        |             |
        +------+------+
               |
           SWITCH B

      LACP Bundle: 20 Gbps

Both interfaces are active members of the same LACP bundle.

The total theoretical bandwidth is:

2 × 10 Gbps = 20 Gbps

It is tempting to assume that traffic will automatically be distributed evenly between the two links.

In reality, traffic distribution depends on the platform's forwarding algorithm, traffic characteristics and hash inputs.

2. Why LACP Does Not Guarantee Equal Utilization

LACP coordinates link aggregation. It does not, by itself, guarantee a 50/50 traffic split.

Switches commonly use a hash based on some combination of:

Source and destination MAC addresses
Source and destination IP addresses
TCP or UDP port numbers
Other platform-specific packet fields

Under conventional per-flow hashing, packets from the same flow generally follow the same physical member to help preserve packet ordering.

This means that a large flow may consume most of one 10 Gbps member while the other member has substantial unused capacity.

For example, a single flow cannot normally use the full 20 Gbps aggregate simply because two 10 Gbps links are bundled together.

The exact behavior depends on the hardware and forwarding implementation.

3. A Practical Congestion Scenario

Suppose four independent flows generate the following offered traffic:

Flow	Offered demand
Flow A	6 Gbps
Flow B	5 Gbps
Flow C	2 Gbps
Flow D	1 Gbps
Total	14 Gbps

The aggregate demand utilization is:

14 / 20 × 100 = 70%

At the bundle level, 70% utilization may appear acceptable.

However, imagine the hash distributes the flows like this:

             LACP BUNDLE
                20 Gbps
                   |
          +--------+--------+
          |                 |
        LINK A            LINK B
         10 Gbps           10 Gbps
          |                 |
       Flow A: 6G        Flow C: 2G
       Flow B: 5G        Flow D: 1G
          |                 |
       Demand: 11G       Demand: 3G
       Capacity: 10G     Capacity: 10G
          |                 |
       CONGESTION         HEADROOM

Link A receives 11 Gbps of offered demand but can transmit no more than its 10 Gbps physical capacity.

The excess demand may result in queue buildup, packet drops or reduced application throughput.

Meanwhile, Link B has 7 Gbps of nominal unused capacity.

The important distinction is that 11 Gbps represents offered demand, not actual transmitted traffic on the 10 Gbps interface.

This is why monitoring only aggregate port-channel utilization can hide a real bottleneck.

4. Five Troubleshooting Checks

Before changing the configuration, collect evidence.

Check 1: Verify LACP Member State

Confirm that both physical interfaces are actively forwarding in the intended aggregation group.

Check:

LACP member state
Negotiated link speed
Partner identity
Port-channel membership
Suspended or standby interfaces

A physically up interface is not necessarily an active forwarding member.

Check 2: Compare Physical Interface Counters

Measure each member independently over the same observation interval.

Review:

Transmit and receive utilization
Output drops
Interface errors
Queue congestion
Peak utilization
Short traffic bursts

Do not rely exclusively on five-minute averages. Brief congestion can affect applications even when long-term averages look healthy.

Check 3: Identify the Largest Traffic Flows

Use available flow telemetry or traffic monitoring to determine which endpoints and applications generate the most traffic.

Look for:

Large backup transfers
Storage replication
Video traffic
Application synchronization
High-throughput server connections

A small number of high-volume flows can create uneven utilization even when many smaller flows are distributed reasonably well.

Check 4: Review the Hashing Policy

Inspect the platform's documented load-distribution algorithm.

A hash using only source and destination IP addresses may distribute traffic differently from one that also includes transport-layer ports.

Changing the hash policy can improve distribution for some workloads, but it does not guarantee perfect balancing.

Test proposed changes with representative traffic before applying them in production.

Check 5: Compare Single-Flow and Multi-Flow Tests

A single-stream throughput test may use only one physical member.

A multi-stream test can reveal how additional independent flows are distributed across the bundle.

Run controlled tests while monitoring individual interface counters.

Use an approved test environment or maintenance window for production-sensitive testing.

5. Should You Add More Links or Upgrade to 25G?

Not necessarily.

Adding links increases aggregate capacity, but it does not guarantee that an individual flow can use multiple physical members.

Before upgrading, answer three questions:

Is the bottleneck caused by uneven flow distribution?
Is a single flow approaching the physical member's bandwidth limit?
Can the network handle the expected demand after one member fails?

Consider the same 14 Gbps of offered demand.

With two active 10 Gbps links:

Normal aggregate capacity: 20 Gbps
Offered demand: 14 Gbps
Nominal aggregate headroom: 6 Gbps

Now suppose one member fails.

Remaining aggregate capacity:

1 × 10 Gbps = 10 Gbps

Capacity deficit:

14 - 10 = 4 Gbps

Even with perfectly balanced traffic under normal conditions, the remaining link cannot carry the full offered demand.

This is an N-1 capacity problem, not simply a load-balancing problem.

For a more systematic approach, see the Switch Oversubscription and N-1 Capacity Guide.

6. Calculate Your Uplink Requirements

Before purchasing additional interfaces or optical modules, compare different designs:

2 × 10G uplinks
4 × 10G uplinks
2 × 25G uplinks

Evaluate aggregate capacity, expected demand, failure-state capacity and the impact of traffic distribution.

The free Switch Uplink Bandwidth and Oversubscription Calculator can help estimate bandwidth requirements and capacity headroom.

Remember that a capacity calculator cannot predict the exact LACP hash assignment or guarantee the absence of packet drops. Those require real device counters and representative traffic measurements.

7. A Practical Troubleshooting Checklist

Before closing a congestion incident, verify the following:

[ ] Both LACP members are actively forwarding.
[ ] Physical member utilization has been measured over matching intervals.
[ ] Interface errors, output drops and queue congestion have been checked.
[ ] The largest traffic flows have been identified.
[ ] The platform's hashing behavior has been reviewed.
[ ] Proposed changes have been tested against representative workloads.
[ ] Remaining capacity has been evaluated for an N-1 failure.
[ ] Upgrade decisions are supported by actual measurements.

Final Thoughts

A 20 Gbps LACP bundle does not guarantee two perfectly balanced 10 Gbps links.

It also does not guarantee that a single connection can transmit at 20 Gbps.

Reliable network design requires engineers to evaluate three separate factors:

Aggregate capacity, physical member utilization and failure-state capacity.

Ignoring any one of these factors can lead to unexpected congestion and unnecessary infrastructure upgrades.

For more practical network engineering tutorials and free engineering tools, visit NetEngineerLab.

Question for network engineers: Have you encountered an LACP bundle where one member was heavily congested while another had significant spare capacity? What did you find was the root cause?

How Many Uplinks Does a 4-Switch Stack Need? A Practical Network Design Guide

NetEngineerLab — Mon, 12 Oct 2026 15:42:34 +0000

The Real-World Design Question

Imagine you're designing a campus network with the following topology:

4 access switches in a single stack
48 × 1 Gbps access ports per switch
2 distribution switches
10 Gbps or 25 Gbps uplink options

You have 192 access ports in total.

Should you connect the access stack to the distribution layer using two, four, or eight uplinks?

The answer depends on traffic demand, redundancy requirements, stack architecture, and failure scenarios — not simply the number of switches in the stack.

1. Start With Two Redundant Uplinks

For many enterprise access networks, two appropriately sized uplinks are a reasonable starting point.

A simplified topology looks like this:

       Distribution Layer
       +-------+  +-------+
       | Dist A|  | Dist B|
       +---+---+  +---+---+
           |          |
         10/25G     10/25G
           |          |
     +-----+----------+-----+
     |     Access Stack     |
     | SW1--SW2--SW3--SW4  |
     +----------------------+

Ideally, the uplinks terminate on different stack members to reduce the impact of a single member failure.

However, connecting to two distribution switches does not automatically create a working port channel.

A cross-device LAG requires a supported technology such as stacking, MLAG, or an equivalent vendor-specific solution.

Otherwise, consider a supported Layer 3 design or another appropriate redundancy mechanism.

2. Calculate the Oversubscription Ratio

Suppose each access switch has 48 × 1 Gbps ports.

Four switches provide:

192 × 1 Gbps = 192 Gbps

With two active 10 Gbps uplinks:

192 / 20 = 9.6:1

With two active 25 Gbps uplinks:

192 / 50 = 3.84:1

Uplink configuration	Aggregate nominal capacity	Oversubscription
2 × 10G	20 Gbps	9.6:1
2 × 25G	50 Gbps	3.84:1
4 × 10G	40 Gbps	4.8:1
4 × 25G	100 Gbps	1.92:1

These figures assume all listed uplinks are active and usable for the traffic being considered.

They describe nominal port-capacity ratios, not measured network utilization.

3. Estimate Real Traffic Demand

Not every connected device transmits at full line rate simultaneously.

Suppose:

192 connected access ports
30% average busy-hour demand per port
1 Gbps access port speed

Estimated demand:

192 × 1 × 0.30 = 57.6 Gbps

In this scenario, two 10G uplinks would not provide sufficient capacity if all 57.6 Gbps actually needed to cross the uplinks simultaneously in the same direction.

But this calculation is only a simplified planning assumption.

Real demand depends on endpoint activity, application behavior, traffic locality, and directional traffic patterns.

For a more accurate design, measure or estimate traffic that actually needs to traverse the distribution uplinks.

4. Don't Ignore N-1 Redundancy

One of the most important questions is:

What happens when an uplink or distribution switch fails?

Consider two active 10G uplinks.

Normal aggregate nominal capacity:

2 × 10 = 20 Gbps

After losing one uplink:

1 × 10 = 10 Gbps

If your required peak traffic is 15 Gbps, the remaining link cannot carry that demand without congestion.

This is why redundancy should be evaluated separately from normal operating capacity.

For critical environments, size the network so the remaining path can support the required traffic after a single failure.

5. Consider Stack Bandwidth

If uplinks are connected only to SW1 and SW2, traffic originating from SW3 and SW4 may need to traverse the stacking fabric.

That isn't automatically a problem.

Modern stacking systems may provide substantial internal bandwidth, but the actual performance depends on:

Stack topology
Stack interconnect capacity
Traffic forwarding architecture
Stack member failure behavior
Vendor-specific limitations

A ring topology may provide better resilience than a simple chain, depending on the platform.

Always verify the manufacturer's stacking specifications.

6. Why More Uplinks Aren't Always Better

Adding uplinks increases potential aggregate capacity, but it can also introduce additional cost and operational complexity.

7. A Practical Design Checklist

Before deciding how many uplinks to deploy, answer these questions:

How much traffic actually crosses the distribution layer during peak periods?
Are 10G or 25G interfaces available on both sides?
Do the distribution switches support MLAG, stacking, or another suitable redundancy design?
Can the remaining uplink handle critical traffic after a failure?
Is the stacking fabric capable of carrying traffic from members without direct uplinks?
Are interface discards, queue congestion, and peak utilization being monitored?
Can additional uplinks be added later without major redesign?

8. Use a Calculator to Validate the Design

You can explore switch port capacity, uplink bandwidth, and oversubscription scenarios using the free engineering tools at:

Switch Uplink Bandwidth & Oversubscription Calculator

A calculator can help compare different uplink configurations, but final designs should always consider actual traffic measurements and equipment capabilities.

Final Recommendation

For a four-member enterprise access stack, I would generally begin by evaluating two appropriately sized, redundant uplinks.

I would not automatically deploy eight uplinks simply because the stack contains four switches.

The right decision depends on actual traffic demand, acceptable oversubscription, distribution architecture, and N-1 failure requirements.

Design for real traffic and failure conditions, not just the number of ports.

Written by NetEngineerLab — practical tools and technical guides for network engineers.