Trunk & EtherChannel Troubleshooting Quick Reference

A trunk carries multiple VLANs over one link, each frame tagged with its VLAN ID (802.1Q) except the native VLAN, which crosses untagged.

Both ends of a trunk must agree on: encapsulation (dot1q), native VLAN, and the allowed-VLAN list. A mismatch on any one of these produces a specific, recognizable symptom — not a generic 'link down.'

If the two ends disagree on native VLAN, TAGGED traffic still crosses correctly — only untagged (native) traffic gets reinterpreted as a different VLAN by each side. This means basic connectivity for tagged VLANs can look completely fine while a real, loggable problem (CDP native VLAN mismatch warnings) exists underneath.

Don't rely on 'can the endpoints ping each other' alone — check 'show interfaces trunk' on both ends and compare the Native vlan column directly.

DTP negotiates trunk formation automatically between two switches. In production, disable it explicitly ('switchport nonegotiate') after hardcoding trunk/access mode — leaving DTP active on a port an attacker can reach lets them potentially negotiate a trunk and access every VLAN it carries.

Bundles multiple physical links into one logical link — more aggregate bandwidth, and Spanning Tree sees one link instead of a real Layer 2 loop between two physical paths.

Both ends' channel-group mode must be compatible: LACP active pairs with active or passive; PAgP desirable pairs with desirable or auto. Mismatched modes (or mismatched protocols entirely) mean the bundle never forms — the physical links stay up individually but Port-channel never comes up.

'show etherchannel summary' — a flag of (P) means bundled/working; (I) means individual (not bundled) — always check this after configuring, not just interface up/down state.