Thanks for testing and using standalone port one is the best results expected on ports two and four and I went back to my previous setup.
I looked in bridge which switch ports are assigned to the physical ports and surprise and that could be caused by me using a hEX-S that also can use an SPF besides 5 ether ports.
Physical port and then switch port in the CPU:
1 → 5
2 → 1
3 → 2
4 → 3
5 → 4
Looking at the schematics posted earlier of the MT7621 there is a RGMII and I assume the SPF is using that as entrance to the switch/CPU. Also notice the fifth arrow is not straight but curved.
Check in Bridged Port - Status if on a non hEX-S the ordering of the switch different.
PS: What I wrote so far above, regarding ports used during tests, I was referring to the etherX interfaces listed in the interface menu which coincide with the labels on the physical ports (except ether1 which is labeled “Internet” but that is pretty obvious since the others are 2,3,4,5)
For example “bridged: 2,3,4,5; stand-alone: 1” means “bridged: ether2,ether3,ether4,ether5; stand-alone: ether1;”
To avoid any confusion.
Good news! they managed to reproduce my findings and they will try to fix the issue in an upcoming RouterOS version, no ETA for now though.
So there is indeed hope for even greater power from this tiny box.
Thank you all for testing and feedback (even the negative ones, the world needs you too!).
Cheers!
The two links in a bridged configuration will (hopefully) be used as described in the “Enabled Switching Diagram”: the ports outside the bridge on a link, and the bridged ports on the other link.
They mentioned that for now the only “predictable CPU lane layout” setup is the disabled switching one (no bridge?, didn’t test, will do).
Or any preferable config from my tests.
I went with WAN on ether1, and bridged 2,3,4,5; but with a device connected to ether2 and a switch connected to ether4, and all other devices behind that switch; nothing connected on ether3 and ether5 on RB750gr3 (since any traffic on ether3 and ether5 will “eat” from the bandwidth available for ether1, and I want ether1 (WAN) to have a full lane for itself to the CPU).
I’ve done some tests with 7.1rc5 (seeing this in the changelog: bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP)), and it seems to be fixed now, altough it isn’t mentioned, but they did something, that’s for sure.
And to be sure that rc5 fixed it, I went back to 7.1rc4 and it was still broken.
Anyway, hEX is great again! (or greater than it ever was?).
Thank you, MikroTik!
Znevna, you need to capture what is in effect NOW, working on the latest vers7,
This thread is a mess to follow.
All I have got out of it so far is the following:./
\
the port assigned to WAN will go through the wire speed switch portion but then traverse to the non-switched GB connection to the CPU’
the bridge and its ports will go through the wire speed switch portion and will then traverse to the Switched GB connection to the CPU.
In other words, MKX’s diagram seems to the be most accurate description I can find for the traffic flow.
You indicate that something was broken and is now fixed, so how should the traffic flow with the fix ???
