I'm not good in plain English, it's alien to me (or is foreign correct word? ![:wink:]( "Wink")
)
Warning: config in this post is a hypothetical example and has nothing to do with actual config by @OP
Example: device is used as a switch, so there's a bridge spanning ether1-5 and SFP. There are a few VLANs, e.g. 100, 200 and 300. SFP is trunk port and is thus tagged for all 3 VLANs, ether5 as well. VLAN 300 is management, ether1-4 are access ports of either VLAN 100 or 200.
Config might be something like this:
So in principle management only works via SFP or ether5 if tagged with correct VID.
And in principle traffic should flow between ether1 and ether2 (HW offloaded to switch chip) or between ether3 and ether4 (again HW offloaded) or ether3 and ether5 (again HW offloaded).
Also in principle traffic should flow between ether1 and SFP (via CPU as SFP is not managed by switch chip) or between ether4 and SFP (via CPU).
Only it does not due to bug.
The bug is this: the bridge port and vlan configuration gets translated into switch chip config. I can't write how it looks on MT switch chip (because manual switch chip config on it never existed), but I can translate it into config for Qualcomm switch chips:
Note that "bridge port" in "bridge config" is essentially replaced by "switch1-cpu" interface. And SFP port doesn't appear as it's not run by switch chip.
Now, switch-cpu interconnect (that's switch port named switch1-cpu) is correctly set as tagged member of VLAN 300 because bridge port is marked as tagged member of that VLAN. But what lacks is setting switch-cpu interconnect as tagged member of the rest of VLANs ... indeed it doesn't have to be as bridge port is not member of those VLANs, but interconnect has to be member because there are other bridge ports (SFP in case of hEX S) beyond the interconnect. And because of this, SFP port is cut off the rest of VLANs, traffic can only pass between SFP and ether5 on VID 300 (because switch chip only passes frames with that VID towards CPU).
Deploying the workaround (adding bridge as tagged port to the rest of VLANs) causes ROS to correctly configure the switch1-cpu port of switch chip ... but causes one unwanted side effect (which might not be crucial, but one has to configure some other segments of ROS carefully): CPU becomes accessible via L2 from all VLANs.
E.g. MAC winbox connectivity is possible ... and one has to block it by applying restrictive config elsewhere.
If device is used as router and it routes this way or another between all VLANs, then the bug won't bite ... because bridge port will be member of all VLANs and ROS will correctly configure the switch1-cpu port of switch chip.
)Warning: config in this post is a hypothetical example and has nothing to do with actual config by @OP
Example: device is used as a switch, so there's a bridge spanning ether1-5 and SFP. There are a few VLANs, e.g. 100, 200 and 300. SFP is trunk port and is thus tagged for all 3 VLANs, ether5 as well. VLAN 300 is management, ether1-4 are access ports of either VLAN 100 or 200.
Config might be something like this:
Code:
/interface bridgeadd name=bridge vlan-filtering=yes/interface bridge portadd bridge=bridge interface=ether1 pvid=100add bridge=bridge interface=ether2 pvid=100add bridge=bridge interface=ether3 pvid=200add bridge=bridge interface=ether4 pvid=200add bridge=bridge interface=ether5add bridge=bridge interface=sfp1/interface bridge vlanadd bridge=bridge tagged=sfp1,ether5 untagged=ether1,ether2 vlan-ids=100add bridge=bridge tagged=sfp1,ether5 untagged=ether3,ether4 vlan-ids=200add bridge=bridge tagged=sfp1,ether5,bridge vlan-ids=300/interface vlanadd name=vlan300 interface=bridge vlan-id=300/ip addressadd address=192.168.88.1/24 interface=vlan300So in principle management only works via SFP or ether5 if tagged with correct VID.
And in principle traffic should flow between ether1 and ether2 (HW offloaded to switch chip) or between ether3 and ether4 (again HW offloaded) or ether3 and ether5 (again HW offloaded).
Also in principle traffic should flow between ether1 and SFP (via CPU as SFP is not managed by switch chip) or between ether4 and SFP (via CPU).
Only it does not due to bug.
The bug is this: the bridge port and vlan configuration gets translated into switch chip config. I can't write how it looks on MT switch chip (because manual switch chip config on it never existed), but I can translate it into config for Qualcomm switch chips:
Code:
/interface ethernet switch portset ether1 default-vlan-id=100 vlan-header=always-strip vlan-mode=secure set ether2 default-vlan-id=100 vlan-header=always-strip vlan-mode=secureset ether3 default-vlan-id=200 vlan-header=always-strip vlan-mode=secureset ether4 default-vlan-id=200 vlan-header=always-strip vlan-mode=secureset ether5 vlan-header=leave-as-is vlan-mode=secureset switch1-cpu vlan-header=leave-as-is vlan-mode=secure/interface ethernet switch vlanadd independent-learning=yes ports=ether1,ether2,ether5 switch=switch1 vlan-id=100add independent-learning=yes ports=ether3,ether4,ether5 switch=switch1 vlan-id=200add independent-learning=yes ports=switch1-cpu,ether5 switch=switch1 vlan-id=300Now, switch-cpu interconnect (that's switch port named switch1-cpu) is correctly set as tagged member of VLAN 300 because bridge port is marked as tagged member of that VLAN. But what lacks is setting switch-cpu interconnect as tagged member of the rest of VLANs ... indeed it doesn't have to be as bridge port is not member of those VLANs, but interconnect has to be member because there are other bridge ports (SFP in case of hEX S) beyond the interconnect. And because of this, SFP port is cut off the rest of VLANs, traffic can only pass between SFP and ether5 on VID 300 (because switch chip only passes frames with that VID towards CPU).
Deploying the workaround (adding bridge as tagged port to the rest of VLANs) causes ROS to correctly configure the switch1-cpu port of switch chip ... but causes one unwanted side effect (which might not be crucial, but one has to configure some other segments of ROS carefully): CPU becomes accessible via L2 from all VLANs.
E.g. MAC winbox connectivity is possible ... and one has to block it by applying restrictive config elsewhere.
If device is used as router and it routes this way or another between all VLANs, then the bug won't bite ... because bridge port will be member of all VLANs and ROS will correctly configure the switch1-cpu port of switch chip.
Statistics: Posted by mkx — Tue Feb 06, 2024 10:56 pm