I’m seeing some odd behavior on my hEXr3 (RB750Gr3), on 7.10.1
(Or my understanding is somehow incorrect, which is probably more likely)
This configuration causes the bridge to not see the other bridge on ether5 (It remains thinking it’s the root bridge with priority 2000, rather than seeing the other bridge at priority 1000 as root. The port on the other bridge is stuck at RSTP Learning and never gets into forwarding state.
Take a read through that thread, there are at least some things you can look at.
That it works when you disable HW makes me think it may be a bug that may have been introduced in recent firmware.
Just to make sure I understand, you have a bridge defined with only a single bridge-port? Is there some reason you need the bridge? Perhaps to give you more control over frame type filtering?
Just to make sure I understand, you have a bridge defined with only a single bridge-port? Is there some reason you need the bridge? Perhaps to give you more control over frame type filtering?
I’ll be adding additional ports and configuration for more VLANs in the near future. For right now I’m just trying to get management setup and working, and banging my head on this issue.
So it looks like Mikrotik has acknowledged a BPDU filtering issue on “hAP ax lite HW offloaded trunk ports.”
The Switch Features chart indicates hAP ax lite uses a MT7531 switch chip. That’s a different model, but the same vendor as the MT7621 in my hEXr3. I wonder if there’d be any benefit opening a support ticket to make sure they’re aware the issue affects both chips?
Probably worth reporting it. They will want Supout.rif files from both ends. What is the on the other end of the link? Is it a MikroTik device as well (not that it has to be, just that if it is, it may be easier for them to reproduce the problem).
I have a hex S (also based on the MT7621) and I had tested tagged (part of hybrid) / untagged access port using the same vlan id on two different bridge ports, but the other end was a Ubiquiti ER-X (also based on the MT7621) but the ER-X was using the vlan-aware switch0 (which does not support spanning tree, so that wasn’t in play), and perhaps that is why I never saw any problems. And I think my testing was with v7.4 (possibly a higher version, but I still have v7.8 loaded).
It is possible that the problem exists with the MT7621 (the "switch in the MT7621 is is similar to the MT7530 ASIC according to the links in this post And It seems likely that the MT7530 and MT7531 switch ASICs may be very similar as well, so it would not surprise me if the two switch ASICs have a very similar set of “configuration” registers, and probably use very similar C driver code, and the hex and hap ax lite may share some common C source code to configure the switch ASIC part of the bridge.
(links reproduced below)
Another indication that the switch ASIC in the hAP ax lite MT7531 and the hEX (MT721/MT7530) are similar is that both show up in the same “column” in the chart.
The reply was pretty terse. Here’s the whole thing
Hello,
Thank you for the report!
We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide a release date now.
Few possible workarounds for hEX: disable RSTP, disable HW offloading, or setting trunk ports as “edge=yes”.
Just curious, have you reached out to them about your previous ticket? Did they ever send you any update? Edit: I was mixed up, it was @thn80 that opened the ticket (see this post) And the was using hap ax lite, not hEX.
When I reported a problem with CSS106-5G-1S (in 2017?) I got a message and a test version before it was put into a firmware update.
Not sure if the procedure has changed.
Perhaps you should at least make a comment in the v7.11rc is released! thread with the test you did, and why you don’t think it is fixed.
Same on AX Lite. Not fixed.
But RSTP and HW offload can be used now.
Only problem: VLAN filtering needs to be deselected to make it working. Can’t be the intention, I guess…
Edit: STUPIDO !! Bridge needs to be added to tagged ports.
It DOES work.
hmm uploaded 7.11rc2 to my hex switch and it became comatose well no beeps just flashing ports then no lights, then flashing etc. Had to netinstall it.
I upgraded mine just today and I must say to my feeling, it took quite a bit longer then it used to for beeping again after reboot.
But it came through eventually.
I tested by turning Edge=Yes to Edge=Auto on my hEXr3 and watching the RB5009 on the other end of the link drop out of Forwarding state until I reversed the change, same as the initial observation.
As I have another hEXr3 lying around, I’ve just quickly labbed this up, and the same condition persists with an extremely simplified configuration.
edit: As before, turning off Hardware Offload on Ether1 on the hEXr3, allows the bridges to recognize each other and pings between the IPs to work. Leaving Hardware Offload on, and setting Edge=yes, allows pings to work but the bridges won’t see each other.
edit again: Further simplified the configuration files by removing extraneous bits of default RouterOS settings.
edit3: Further simplified configuration by removing management bridge - you’ll need two computers or two ethernet interfaces (or a small ethernet switch) to manage both test routers at the same time. RB951G.rsc (616 Bytes) hEXr3.rsc (613 Bytes)
