I had to debug it, and as a side effect I have found that there is an issue in at least 6.43.2 (see in gray below).
To use secure
mode for tagged frames on etherX in 6.43.2
, it is enough to set just two things in the switch chip configuration provided that the /interface vlan is hosted directly on etherX
(which is your case):
- the etherX must be listed in the ports list of /interface ethernet switch vlan row for the vlan-id in question,
- the vlan-mode of etherX must be set to secure
If you use a port on AR8327 and the connected equipment expects tagged frames from you, the default-vlan-id
be set to the VID in question, as the AR8327 would untag frames tagged with that VID on egress. So your default-vlan-id=60
would be a mistake on a port of AR8327, but is harmless in your particular configuration.
If the /interface vlan
is hosted on a bridge
of which etherX
is a member port, also the CPU port of the switch must be listed in the ports
list of /interface ethernet switch vlan
row for the vlan-id
in question (regardless what is the vlan-mode
on the CPU port).
So all in all - something may behave differently in 6.40.9 than it does in 6.43.2, and the only way to find out is to try the same configuration on both.
But most important - as you have attached the /interface vlan
directly, not via a master port, an upgrade to 6.41+ won't change anything about how it works without vlan filtering on the switch chip. Only master-port configurations are auto-converted to bridge configurations by the upgrade.
So the only advantage of vlan filtering in the switch chip is that frames tagged with other than permitted VIDs are dropped already by the switch chip and never make it to the CPU.
On RB2011, ether1 to ether5 are on AR8327, which can both tag on ingress and untag on egress depending on the default-vlan-id value. And it works, as tested elsewhere.
However, ether6 to ether10 are on AR8227, which tags on ingress depending on the default-vlan-id value, but is unable to untag on egress selectively depending on VID - according to the manual, you can either keep tagged frames tagged and untagged frames untagged (leave-as-is), or you can untag everything (always-strip), or you can even tag tagless frames on egress (add-if-missing) - but I've never tested what it really does.
And the issue I've found is that always-strip simply doesn't work at least in 6.43.2 (on hAP ac lite, I have no RB2011 to test on), at least for frames which ingress via the CPU port. Whichever of the three modes of tag handling on egress you configure on the ethernet port, it keeps emitting tagged frames to the wire. I don't exclude that it is related to the way how the CPU informs the chip through which port it should egress the frame - a proprietary tag is used for this purpose, which doesn't exist on frames forwarded from one non-CPU port to another.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.