It began with a netlab situation describing totally different interpretations of VLAN 1 in a trunk. Whereas Cumulus NVUE (the way in which the netlab configuration template configures it) assumes that the VLAN 1 in a trunk is tagged, Arista EOS assumes it’s the native VLAN.
At that time, I ought to have stated, “that’s loopy, we shouldn’t enable that” and implement the “VLAN 1 must be used as a local VLAN” rule. Alas, 20/20 hindsight by no means helped anybody.
TL&DR: Don’t use VLAN 1 in VLAN trunks; if it’s important to, use it as a local VLAN.
A Little bit of a Historical past
Let’s strive to determine what quirks of historical historical past introduced us to the present quagmire earlier than going into the bizarre stuff I encountered whereas attempting to implement the tagged VLAN 1 concept:
Nevertheless, as individuals began utilizing VLANs on issues that must be auto-provisioned (servers, entry switches), they found an fascinating conundrum:
- The auto-provisioned units don’t know they need to use a VLAN trunk on their uplink earlier than they’re configured.
- DHCP requests are thus despatched as untagged packets and would land in VLAN 1.
- Utilizing the identical VLAN 1 in all places for auto-provisioning would set off alerts throughout any semi-competent safety audit, so we would have liked one other answer.
- Distributors rapidly realised one may assign any VLAN tag to untagged packets and we acquired the performance to make use of any VLAN as a local VLAN in a VLAN trunk. In spite of everything, an entry VLAN port is nothing else however a trunk port with a single native VLAN.
Anyway, whereas it’s completely OK to not enable VLAN 1 on a VLAN trunk, most (sane) individuals growing community working techniques saved assuming that if one desires to make use of VLAN 1 in a trunk, it will be used because the native VLAN.
A Maze of Tiny Rabbit Trails, All Alike
Again to 2025. As a substitute of posting the above paragraph in response to the above-mentioned GitHub situation and shutting it, I made a decision to do the loopy factor and determine which distributors might be persuaded to ship and obtain tagged packets in VLAN 1 on a VLAN trunk.
I created a new integration take a look at with three VLAN trunks:
- Tagged VLAN 700 and VLAN 1
- Native VLAN 1 and tagged VLAN 700
- Native VLAN 700 and tagged VLAN 1
Subsequent, I ran the take a look at on most units supported by the netlab VLAN configuration module. A few of them handed with flying colours; many wanted configuration tweaks starting from a single command to horrible issues one shouldn’t do in a real-life community:
- Aruba CX and Arista EOS wanted a configuration command saying, “we need to tag native VLAN packets.” Yeah, I do know that seems like a sq. circle, however that’s the system CLI for you.
- There is no such thing as a such command on Cisco IOS or Nexus OS, however I may make VLAN 1 tagged by configuring a pretend VLAN as a local VLAN. I used VLAN 1002 on Cisco IOS layer-2 pictures and the highest accessible VLAN on Nexus OS. For extra Cisco IOS particulars, learn Encapsulation of PDUs On Trunk Ports by Daniel Dib.
- Cisco IOSv makes use of subinterfaces to implement bridging, and there’s no option to say, “this subinterface makes use of tagged VLAN 1”. The encapsulation dot1q 1 command at all times will get the native key phrase connected to it.
- I needed to change the VyOS configuration template to configure VLAN 1 instantly on the built-in bridge interface (all different VLANs are configured on vif subinterfaces of br0)
- Junos switches labored like a appeal, however our router configuration template makes use of pretend VLAN 1 configuration on unit 0. We may change that to use one other pretend VLAN, however I might love a cleaner method.
- Dell OS10 makes use of VLAN 1 as an inside VLAN, and flat-out refuses to make use of it in a VLAN trunk until you change the interior VLAN to one thing else.
To recap: Don’t use tagged VLAN 1 in VLAN trunks. Simply since you may doesn’t imply that you need to.
