Indeed, this changed somewhere around the time of master-port removal. I was gaslighting myself if it used to be required and I was right, it was not. See the old copy of wiki where the flow is essentially:@mkx:
The basic idea, mentioned everywhere in the docs, is that switched ports are members of bridge. The fact, that it works for you if not all ports are bridge members, is some kind of gray area ... and hence behaviour might change from version to version.
- Set random port as "master-port"
- Use "/interface/ethernet/switch/port" to set trunk/access and PVID
- Configure VLAN table in "/interface/ethernet/switch/vlan"
You seem to be 100% right. I opened documentation from 2018 and there they specifically call this change and both constructions being equivalent, even if normally "bridge" isn't related to hardware switch:@mkx:
As to question #2: when bridge got introduced (around 6.41), it replaced "master switch port" as means for CPU to communicate with bridged ports (the CPU-facing bridge port). (...)
Code:
# pre-v6.41 master-port configuration/interface ethernetset ether3 master-port=ether2#...# post-v6.41 bridge hw-offload configuration/interface bridgeadd name=bridge1 igmp-snooping=no protocol-mode=none/interface bridge portadd bridge=bridge1 interface=ether2 hw=yes#...This is exactly my point here - the bridge makes sense if you want bridge on the CPU side. However, it appears that the "bridge" silently fiddles with hardware configuration even if CPU is deliberately cut off of the traffic. As for CPU communicating with non-bridge member@mkx:
And, as I already mentioned, the idea is to have gridge as complete as it gets. If certain L2 functions have to be configured elsewhere this doesn't mean that bridge can be left only partially built
It doesn't seem to be the case. The "switch1-cpu" must be added explicitly, as I did for VLAN 20 for the CPU to be able to get the traffic. The ROS appears to be completely cut off from the networking if the "switch1-cpu" isn't added somewhere. I poked around using serial console in such state and removal of "switch1-cpu" is a death sentence for any network traffic between CPU and switch chip@mkx:
I'm wondering (perhaps you could test it) if switch's CPU can communicate with device, connected to port which is not bridge member (in your case ether5).
---------------
Curiously the 2014s docs don't have this note for the Atheros one (QCA wasn't a thing yet). In 2016 docs the QCA8337 is there but note isn't still. BUT you may be spot on with the ignore part! In 2019s documentation the note reads:@mkx:
3. My understanding is that QCA8337 and AR8327 simply ignore that setting for ports with default-vlan set and go with tagging/untagging regardless. I tend to set it to "always-strip" on access ports. I guess it wouldn't be the right setting on hybrid ports, so it's just good that switch chip knows better.
In QCA8337 and Atheros8327 chips when vlan-mode=secure is used, it ignores switch port vlan-header options. VLAN table entries handle all the egress tagging/untagging and works as vlan-header=leave-as-is on all ports. It means what comes in tagged, goes out tagged as well, only default-vlan-id frames are untagged at the egress of port.
Documentation from 2021 changed it to "The vlan-header is set to leave-as-is and cannot be changed" but still mentioned being ignored. The old documentation on the wiki as of today still mentions ignoring the setting. The new documentation repository changed the verbage to this confusing "should use"...
I wish MikroTik left that bit, as "it is being ignored" makes me sleep better than "don't do it", as the later implies some undefined behavior may be caused by changing "vlan-header" to value other than "leave-as-is".
Statistics: Posted by kiler129 — Wed Feb 05, 2025 11:01 am
