The problem: you connect a trunk between two switches from different vendors, the tagged VLANs mostly work, and then something odd shows up. One VLAN leaks into another, or untagged traffic vanishes, or a log message complains about a mismatch. Nine times out of ten the native VLAN is the culprit.
Here is the procedure I follow, and I would like to hear how others do it.
Terms first, because vendors disagree
The standard is 802.1Q. One vendor says "trunk" and "native VLAN." Another says "tagged" and "untagged" members, or "PVID." They describe the same thing. On a trunk, every VLAN is tagged except one, and that one travels with no tag at all. Whichever VLAN a switch assigns to untagged frames arriving on that port is the native VLAN. If the two ends disagree, untagged frames from one side land in a different VLAN on the other side. It is like two roads meeting at a junction where one calls the unmarked lane "local" and the other calls it "express."
The procedure
- Check the cable and link first. Confirm speed and duplex agree and that the port is up on both ends. A layer 1 fault will waste your afternoon faster than any VLAN setting.
- Decide on the VLAN list before you touch either switch. Write it down. Allow only the VLANs you need on the trunk, not all of them.
- Pick a native VLAN on purpose. I prefer an unused VLAN with no hosts, so stray untagged frames go nowhere useful. Configure the same ID on both ends.
- On a vendor that uses the trunk model, set the mode to trunk, the allowed list, and the native ID. On a vendor that uses the tagged/untagged model, tag every VLAN on the port except the native one, and set the PVID to the native ID.
- Verify on both switches. Do not assume the second switch matches because you typed the same numbers.
On Linux or a Proxmox host, you can see what is really on the wire with a capture:
tcpdump -i eth0 -e -n vlan
The -e flag prints the link-level header, so you can see the VLAN tag on each frame. Untagged frames will not show a tag, which is exactly what you want to see for the native VLAN and nothing else.
Things that bite people
- Some vendors default the native VLAN to 1, others let you leave it unset. Check, do not guess.
- Some switches silently drop untagged frames on a trunk if you disable the native VLAN. That is fine if intended and baffling if not.
- Spanning tree and discovery protocols may behave differently across vendors. I have not tested every combination, so I will not claim to know how yours will behave.
- Allowed lists that differ at each end give you a VLAN that works one direction only, or not at all.
I keep the port, mode, native ID and allowed list for each trunk in the binder, one line per end.
Two questions for the group. Which commands do you use to confirm the native VLAN on each vendor you work with? And do you leave the native VLAN at its default, or move it to an unused ID? Report back.