do you have trouble with port flopping? Here is “answer” from support.This “trouble” is writen nowhere in specification. RB3011 is CRAP and Mikrotik makes bad device.
The reason for port flapping is that you have different kind of devices connected to the same switch group. When you have 1Gbps devices connected to the same switch group with 100Mbps devices, the switch buffer needs to be cleared before forwarding traffic to the next port, but when you have mixed speeds it can’t keep up clearing out the buffers so it flops the port. This is a RB3011 switch chip specification, there isn’t much you can do, you must use the same speed Ethernet devices to avoid this.
wtf - the longer you read about experience with new devices the longer you tend to keep good old RB2011’s, but with every second power failure I loose one ot those either.
That’s the worst explanation of egress buffer overflow and port flapping I ever read.
So at least this should be mitigatable by employing flow-control.
A switch must never drop the Layer-1 connectivity, when having issues handling large loads of traffic. So this simply is a sign of resignation over the chosen design.
I confirm the issue. I’ve never experienced the port flappings everyone mentions since RB3011’s release.
I now know why. I didn’t mix Fast ethernet and Gigabit devices on the same switch group.
I just tried it and indeed after I maxed out a fast ethernet all ports flapped.
Oh dear, this is a major slip up on MT behalf. The RB3011 really did have a bright future but then had a huge amount of teething problems when launched (probably due to new arm architecture) and then there was the “loop detected” issue as well.
I wasn’t aware of this however am now a little dubious of this as shortly I had planned on connecting 3 10/100 devices to an RB3011 in a remote location.
Nothing quite says buy a CCR like your existing model failing…
Is it a possibility to put a dumb 10/100 switch after the RB3011? I know, it should not be like that.
Is going back to RB2011 an option? I never had this problem, mixed Gbit and fast ethernet.
And still, how do YOU control the users equipment? Today all users have “old laptops”, with 100 Mbit NIC’s. Tomorrow one guy buys a new laptop and that one has Gigabit connection. So what, after the new laptop he get’s worse performance or reliability? Strange.
I wonder if other RouterBOARD models with the same switch-chip model (QCA8337) suffer from the same problem. According to this wiki page the models in question are: hAP ac, OmniTIK 5 ac (including OmniTIK 5 ac PoE), the old hEX model (RB750Gr2), hEX PoE and PowerBox Pro.
This is either a bad software design on Mikrotik’s part, or bad device design by Mikrotik for using such a switch chip (if indeed the issue is there - any qualcomm/atheros datasheet or documentation pdf confirming this would answer this question).
Either way, this is Mikrotik’s fault IMHO. And even worse, they haven’t posted any announcement on this, so people are still buying a faulty device (yes I consider this a fault since it doesn’t work as advertised).
I wonder if this is the reason that RB3011 was pretty much left on it’s own and we never saw any other models after the RM one. Did they realized they messed up and simply dropped the whole series?
Does anyone know any other devices (routerboards or not) using this specific switch chip? I wonder if we can independently reproduce Mikrotik’s claims.
I have listed other RouterBOARDs where the same switch chip is used several posts above.
They seem to be: hAP ac, OmniTIK 5 ac (including OmniTIK 5 ac PoE), the old hEX model (RB750Gr2), hEX PoE and PowerBox Pro.
It looks like I may now be suffering from this. Have taken relevant screenshot and supout files and sent to support but reading back over RB3011 port issues it looks like I am now falling foul of this.
There won’t be one. Simply don’t mix 10/100 and 10/100/1000 on the same switch group. I’m going to uplink to a CRS112 and use that for for non gigabit devices.
Hello, the discussed RB3011 issue is not hardware related, despite the quoted email in the first post.
We have discovered that it tends to occur due to software after several day uptime, therefore it is harder to reproduce and debug it. Despite all that, we are working on it and plan to apply fixes in upcoming RouterOS versions.
