I noticed the VLAN1 example in Switch_Chip_Features is wrong, at least for Atheros 8327 on RBD52G-5HacD2HnD with ROS 6.45.1. Here is what I finally came up with in order to have traffic correctly taggued on egress with VLAN 2 on trunked port:
In opposition with the documentation, the vlan tag is stripped from trunk port if it has the default vlan id. Hence the solution to create a fake vlan 0 with an additional switch rule to avoid leaking it outside. Unsure why I had to add all the access ports as well to that switch vlan but that's the only solution I have found which works.

Hope it helps others...

Implicit default VLAN ID in ROS is 1. If you leave it that way and if you don't use VLAN with ID 1 the you don't have to create any work arounds.

BTW, setting default VID on port means (with most vendors) that you want to have that VLAN untagged on that interface. If you want it tagged, then setting it as default doesn't make any sense because it has to be treated just like all other tagged VLANs passing that interface.

And I agree, documentation on switch-chip VLAN peculiarities is somehow inadequate, not all specual "features" of individual switch chips are documented. If I understand MT right, they woukd like to make switch-chip specific configurations obsolete (bridge should take over) and I don't expect them to care about documentation of old school config too much.

Thanks for reply. I don't see why VLAN 1 would behave differently but if it does then I prefer not to use it

Untagged traffic in secure mode should be rejected ingress so why would anyone send back untagged traffic ?

I have not made an analysis of other vendors, but on my allied and tplink switches I can force tag on egress even if it is the default for the port. I think vendors should not assume if we want tagging or not but let us choose exactly how we want things to behave. I think it is a place where explicit configuration should clearly prevails. I really hope MT would improve because the current situation with Bridge HW -> Switch -> Bridge SW is close to nightmare for configuration and predictability.

In my opinion, they should add as an interface an explicit switch port matching with switch CPU port (for device that have a switch of course). Also it should be possible to assign an ethernet port either to the switch or not (based on the HW capabilities). If the port is allocated to the switch it should not be available as a standalone interface anymore. That would match more closely the HW in hand and be much easier to work with. (The former master port concept was not so far away from a good solution but they went ahead with a solution that would never works as intended in practice)

Thanks for reply. I don't see why VLAN 1 would behave differently but if it does then I prefer not to use it

VLAN 1 doesn't behave any differently than any other VLAN set as default (2 in your case). The only gotcha with VLAN 1 is, as I wrote, that it's set as default VLAN in default settings and it's easier to overlook that ...

Untagged traffic in secure mode should be rejected ingress so why would anyone send back untagged traffic ?

Behaviour of link partner is not defined by settings of this end. In addition, this setup is secure:

The above setup configures ether1 as hybrid port (tagged VID 42 and untagged VID 40). vlan-mode=secure makes sure no other VLANs can be injected on ingress. And the same setup configures ether2 as trunk port for both VLANs.
In the similar manner one would set vlan-mode=secure on an access port (with default-vlan-id set) to make sure that on ingress no other VLANs are allowed.

In short: secure mode is not so much about untagged traffic, it's about VLANs (in general, untagged can be thought of another VLAN) on ingress.

I have not made an analysis of other vendors, but on my allied and tplink switches I can force tag on egress even if it is the default for the port.

My interpretation of how VLANs work in MT (not necessarily shared by other distinguished members of this forum) is that (when we start to work with VLANs) frames always pass bridge/switch tagged ... including those untagged frames ingressing port with default_vlan/pvid set. And that frames get stripped off VLAN tag if they should be tagless on egress. And my interpretation is that this process of tagging/untagging happens even for frames which flow from untagged towards untagged (switch/bridge may or might not analyze destination MAC address immediately upon ingress, if they don't they can't know whether VLAN header is needed or not). So to force header be included on egress it's vital to tag untagged frames on ingress ... and have port as normal (tagged) member of certain VLAN.
And I don't get an idea why would one accept untagged frames on ingress and force them tagged on egress ... if remote device can't handle tagged frames on (its) egress, why serve it tagged on (its) ingress ... unless one wants to mock around bug in windows network drivers which strip VLAN headers as one if first things on ingress.

I think vendors should not assume if we want tagging or not but let us choose exactly how we want things to behave. I think it is a place where explicit configuration should clearly prevails. I really hope MT would improve because the current situation with Bridge HW -> Switch -> Bridge SW is close to nightmare for configuration and predictability.

Different vendors (MT included) have different ways of doing the same thing. Your habit of setting default VLAN ID for tagged-only port should not become a standard.

As I already wrote, with MT exact configuration even slightly depends on particular switch chip type. However MT, introducing the bridge VLAN filtering, IMHO made a big step towards simpler and unified way of configuring things.

In my opinion, they should add as an interface an explicit switch port matching with switch CPU port (for device that have a switch of course). Also it should be possible to assign an ethernet port either to the switch or not (based on the HW capabilities). If the port is allocated to the switch it should not be available as a standalone interface anymore. That would match more closely the HW in hand and be much easier to work with. (The former master port concept was not so far away from a good solution but they went ahead with a solution that would never works as intended in practice)

As I wrote before: (not so) recent move by MT towards bridge-centric configuration shows that MT would like us to forget about HW peculiarities when configuring devices. And this is IMHO a good move. The only problem with this approach is that currently only a few device types support it in hardware (CRS3xx series), the rest do it in software. One can hope that this will improve with ROS v7.

Thanks for the clear and detailed answer. I did a lot of monitoring with wireshark on each end. I think your interpretation is correct regarding tagging, it is the very first step made by the switch fabric. Also the removal of default PVID is automatic as the last step of the process. It even happen when using the port copy applying whatever setting is defined on the target port.

Regarding the untagged+secure, you are fully right, it's the tables here that made me think they would be ignored. I have now set secure for all ports and simplified the settings. I am unsure why I could not get it right the first time. In between I have finished the migration of my L3 config so I could upgrade to latest version and firmware, it seems the firmware upgrade helped.

The new bridge as a lot of potential on paper. But I need wiring speed switching and filtering that includes VLAN, so that's still a no go outside CRS3xx serie.

I just found this note in MT documentation.

Note: QCA8337 and Atheros8327 switch chips ignore the vlan-header property and uses the default-vlan-id property to determine which ports are access ports. The vlan-header is set to leave-as-is and cannot be changed while the default-vlan-id property should only be used on access ports to tag all ingress traffic.

This is the actual reason of the switch stripping tag when default-vlan-id is set. The vlan-header can be changed with winbox (3.20) which is probably to be reported as bug then.