VLAN aware bridge, VLAN pruning and tagging the native VLAN


Hi all,

while configuring a VLAN aware bridge to not use an untagged (so called native) VLAN on trunks to other switches, I was confused by the documentation "Configuring a VLAN-aware Bridge," "VLAN Filtering/VLAN Pruning," and "Dropping Untagged Frames."

As I understood the documentation, restricting the VIDs of a port to not include the bridge default PVID (which doubles as native VLAN for trunks) would prune it from the uplink. My assumption is based on experience with other vendors (Arista, Cisco, Enterasys, Extreme, HP, and other, more obscure ones) and the short section on VLAN Filtering/Pruning.

My understanding of the effect of bridge-allow-untagged no was that untagged frames are dropped, changing nothing else, similar to the ExtremeEOS (formerly Enterasys) command set port discard untagged.

The actual switch behavior as observed using net show bridge vlan was different:
  • bridge-allow-untagged no results in tagging the native VLAN
  • pruning the native VLAN (aka bridge-pvid) from an uplink requires both to prune it using bridge-vids and to tag the native VLAN using bridge-allow-untagged no on the uplink
IMHO the observed behavior is better than my initial assumptions, since the bridge-allow-untagged no option is similar to the Cisco IOS vlan dot1Q tag native command and thus more generally useful than the ExtremeEOS set port discard untagged command.

BTW, NCLU seems to have an issue with pruning the native VLAN by specifying a bridge-vids list without the native VLAN. The command was accepted, but net pending showed no change. Applying the pending configuration using net commit did not change the configuration file /etc/network/interfaces. Thus I manually edited /etc/network/interfaces and restarted networking.service, which achieved the desired effect (as observed with net show bridge vlan).

Have I got the above right? I did not verify the behavior with a sniffer and traffic generator, but used NCLU show commands only.

Would it be possible to improve the documentation to say that bridge-allow-untagged no changes the native VLAN to tagged, and that the native VLAN is included in a trunk unless it is both pruned and changed to tagged?

Thanks,
Erik

7 replies

Userlevel 3
Hi Erik, thanks for the detailed post about your issues. I’ll verify this all with engineering and update the docs accordingly. I’ll also see if you’ve found bug in NCLU.
Userlevel 3
Erik, could you provide the output for "pruning the native VLAN by specifying a bridge-vids list without the native VLAN." please?

And could you let us know what you mean by "changes the native VLAN to tagged"?
Hi Pete,

I'll try to get you the output over the weekend. Just for info, what I described above was from Cumulus Linux version 3.3.2.

With "changes the native VLAN to tagged" I mean that before adding bridge-allow-untagged no, net show bridge vlan displays the bridge-pvid VLAN as untagged on the port. After adding the command, net show bridge-pvid vlan shows it without comments, the same as every other trunk port.

Thanks,
Erik
Userlevel 3
Erik Auerswald wrote:

Hi Pete,

I'll try to get you the output over the weekend. Just for info, what I described above ...

Thanks Erik. Looking forward to your config and for the explanation. I'll be curious to see your config and the results of 'net show bridge vlan' before and after applying the 'bridge-allow-untagged no'.
Erik Auerswald wrote:

Hi Pete,

I'll try to get you the output over the weekend. Just for info, what I described above ...

Hi Pete,

I've just been playing with Cumulus in the Cloud, and there net add interface swpX bridge allow-untagged no results in pruning the native VLAN from the trunk, as described in the manual.

There is no need for manual editing of /etc/network/interfaces as described in my original post either.

I'll look into setting up Cumulus VX 3.3.2 to check it there.

Thanks,
Erik
Erik Auerswald wrote:

Hi Pete,

I'll try to get you the output over the weekend. Just for info, what I described above ...

Hi Pete,

I cannot reproduce what I described in my original post with Cumulus VX 3.3.2 either. It works just as described in the documentation:

cumulus@cumulus:~$ net add bridge bridge ports swp1-2
cumulus@cumulus:~$ net add bridge bridge pvid 1000
cumulus@cumulus:~$ net add bridge bridge vids 11,47
cumulus@cumulus:~$ net commit
--output omitted--
cumulus@cumulus:~$ net show bridge vlan
Interface VLAN Flags
----------- ------ ---------------------
swp1 11
47
1000 PVID, Egress Untagged
swp2 11
47
1000 PVID, Egress Untagged
cumulus@cumulus:~$ net add interface swp1 bridge allow-untagged no
cumulus@cumulus:~$ net commit
--output omitted--
cumulus@cumulus:~$ net show bridge vlan
Interface VLAN Flags
----------- ------ ---------------------
swp1 11
47
swp2 11
47
1000 PVID, Egress Untagged
I observed what I described in my original post while helping with the VLAN configuration of a Vagrant setup (PoC for real deployment) that was configured already. The VLAN configuration was not as intended, but bridges and switch ports already existed.

What I remember seeing is as follows:
$ net add interface swp1 bridge allow-untagged no
$ net show bridge vlan
Interface VLAN Flags
----------- ------ ---------------------
swp1 11
47
1000
swp2 11
47
1000 PVID, Egress Untagged
That is what I meant with "native vlan tagged."

To remove the VLAN 1000 from swp1 I edited /etc/network/interfaces to include:
iface swp1
bridge-vids 11 47
After restarting networking.service the output of net show bridge vlan looked as expected. (net add interface swp1 bridge vids VLANLIST does not make any changes in 3.3.2, but works as expected in 3.5.2, at least in my tests this weekend.)

Sorry for the noise.

Thanks,
Erik
Userlevel 3
Erik Auerswald wrote:

Hi Pete,

I'll try to get you the output over the weekend. Just for info, what I described above ...

Thanks for the continued testing. Overall I'm glad everything is working for you now, so thank you for taking the time to troubleshoot and report back.

If something does seem awry, please hit us up again.

Reply