Update - I was able to run some test configs yesterday and verified the addition of the bridge name in the tagged list didn’t seemingly do anything, and best I could tell had no effect on any traffic whatsoever, so it’s being removed from the production config during the next maintenance window.
I don’t have a test environment I can test and validate something right now and for some reason I’m struggling to remember the correct config for VLAN setup inside a bridge, because I just logged onto a working environment someone setup and see a config that doesn’t make sense and now I’m questioning my memory & reading of VLAN implementation…
This is a situation where multiple ports are added to a bridge (in this case ether3, 4 and 5), and vlan-filtering=yes on the bridge. The goal is to allow tagged VLAN100 traffic in on ether3 and ether5 but not ether4.
This was the config I found
/interface bridge vlan
add bridge=LAN tagged=LAN,ether3,ether5 vlan-ids=100
I thought the correct config should have been
/interface bridge vlan
add bridge=LAN tagged=ether3,ether5 vlan-ids=100
but while I’m at it, because this has me all confused now, would the inclusion of LAN in the tagged list serve to allow any member of the bridge to pass tagged VLAN100 traffic, thus invalidating the need to specify the individual interfaces (and also in this case allow traffic on the port that wasn’t intended)?
/interface bridge vlan
add bridge=LAN tagged=LAN vlan-ids=100
main reason for the question is this is a remotely running production system that I have to schedule making any changes to, and have limited access to test functionality while remote, and as I’m also away right now I don’t have access to my lab for testing before making changes to this system.