7.2 - Router(s) Lock Up When Connecting via Winbox

Yeah, so far, I’ve been able to consistently lock up my RB5009 using the bandwidth test fragtion mentioned and a simple queue with cake attached. In my case it doesn’t seem to be a full lock up though, I’m able to remain connected in winbox if I’m running it from a computer directly connected to the router. Although I have to be connected using the MAC address in order the connection to maintain itself. Happens on the 7.3 beta that was just released as well.

I generated a couple supout files while the router was refusing connections and filed a ticket with Mikrotik. Hopefully they can replicate and pinpoint the issue.

I have similar experience too. When using cake in simple queue, the connection lock up for a while when doing a speed test.

/queue/simple add bucket-size=0.01/0.01  max-limit=960M/960M name=queue-cake queue=\
    cake-ul/cake-dl target=bridge

I found that if I set only the target , it always have problem.
If I also set the dst , for example, , dst=ether8 (the WAN interface), it seems works fine. (at least tested 1 to 2 days of general use, although I finally change back to fq-codel)

/queue/simple add bucket-size=0.01/0.01  dst=ether8 max-limit=960M/960M name=queue-cake queue=\
    cake-ul/cake-dl target=bridge

PS: I am using RB5009

Great find! Testing this out now on my RB5009 as I really want to try cake some more (seems incredibly tasty so far! Generally way more effective & efficient than all other queues in ROS that I’ve tried at least) - but this bug is obviously a major impediment to actually using it.

This won’t technically fix the underlying bug (eg: when using the bwtest method, as that takes place from the router doing the cake). But it conveniently bypasses it, as wan traffic to/from the router itself is no longer affected by the simple queue. This is also good news from a remote wan management perspective (ie OP/@bluebird’s initial approach) as we won’t get locked out of the router remotely anymore from this, unless the CPU/kernel somehow gets hit & we land up with cake in our face :joy:

If it stabilizes all lan<->wan traffic then it’s going to be a great workaround for us in the meanwhile. Hopefully MikroTik will fix the issue soon but for those of us who are more eager to try this out, an effective workaround is a welcome icing for some freshly baked goodness! :grin:

P.S.: @anav I generally don’t consider myself much of a baker either to be honest, but I strongly suggest indulging in a slice if you haven’t - you’ll probably not regret it !

Update @t+2h: Looking pretty solid so far, I think this is good.

I don’t “get” why anyone needs to set a bucket when using cake. Cake has its own shaper.

Setting it on the bridge is usually the wrong thing. You want to set it on the actual physical interface you are trying to shape, so it sees all traffic.

Per customer shaping is different, but elided here.

It’s a requirement of the mikrotik QoS interface. Not setting any value here just defaults to a bucket size of 0.1.