But I can only get the expected ingress performance by:
Setting the Simple queue limits to Unlimited and the Cake specific limit to my target
Setting the target slightly lower than the real speed because we are missing the Ingress keyword to compensate
My requests are:
Please add the Ingress keyword (trivial change)
Give us the ability to create “really mega simple” queues that do not seperate the shaper and qdisc so that we can entirely bypass HTB and only use Cake shaper
Please Mikrotik
.B ingress
.br
Indicates the qdisc is used on ingress (typically done with an IFB device).
Most notably, this counts drops as data transferred, making ingress shaping
more accurate, since packets will have already traversed the link before Cake
gets to choose what to do with them.
In addition, drops are also counted as data transferred for maintaining
fairness. This leads to the possibly unexpected result that with host fairness
enabled (see the
.B FLOW ISOLATION PARAMETERS
section), IPs with more simultaneous TCP flows may show lower total goodput than
IPs with fewer flows. This is expected, and is due to proportionally more
packets being dropped for congestion control when there are more active flows.
Clients can avoid this possible loss in goodput by either using fewer flows, or
enabling ECN for greater efficiency.
on hapAC2 (arm32) basic functionality is fine bridging/nat/filtering/fasttrack/eoip/wireguard/openvpn/queue/dhcp/dhcp snooping and wifi
not tested
igmp-proxy/ospf/bgp/capsman/cake/codel/fq_codel/pppoe and hotspot
not working
cloud backup you can’t upload if you do have previous upload from 6.48.4 but it’s not listed in the UI so you can’t remove previous version, workaround is to go back to 6.48.4 and delete the file there and go back to rc2 to make a backup
You are right, it does not advertise any BGP routes on CHR either! (configured without any route filters - I presume that would by default advertise all connected routes)
Oh lol. Actually the only config change I did before upgrading - and without reboot - was to generate a lets-encrypt certificate (because I had an SUPEE opened for that - now resolved). Maybe the upgrade did not like that LE-certificate residing somewhere in the void of router-storage omg. I am possibly the only one here that issued a LE-certificate and performed an upgrade. hahahahahaha. Always those edge-cases…
–
As far I observed the process of updating it works this way:
backup user config
format & install
restore user config
These steps are apparently not atomic and if step 3 fails - you’re screwed.
I believe in a previous beta that was working. You had to add a static route for each prefix you wanted to advertise.
I don’t remember for sure if that was the case exactly, but I remember that I really didn’t like the new approach (as mentioned by others too).
Cake is very stable now on RB4011, no crash, I played a lot with the settings, leaving Winbox open for a very long time. Had a 36 hours uptime with the rc2 release someone posted in the rc1 thread.
Anyone noticed that L2TP clients can no longer login after upgrade from rc1 to rc2?
I do receive a message “l2tp,info INFO: first L2TP UDP packet received from 3911:3f65:551f:861e:54a6:d222:cd76:6a5” many times.
Reverting back to rc1 makes L2TP login possible right away, upgrading to rc2 again makes them fail.
That is correct, I did see it working as well. I have a test router (CHR) which has a BGP session with our main router, normally it shows no prefixes but when I added a bridge with a dummy address that address was advertised and the prefix count went to 1. Not anymore.
I do not like the new method so much either, it is nice that it reduces the work to maintain “BGP networks” but it will likely increase the work on “Routing filters” and/or the number of mistakes.
Maybe there should be a new attribute “BGP advertised yes/no” with static and connected routes?
I removed the max limit on my inboud/outbound queues
I created 2 Cake queue types (inboud/outbound) which I assigned to the appropriate queues
In the Cake config for the outbound, I set the bandwidth very close to my actual speed and it works great
For the inbound, I really have to lower the bandwidth so that Cake does not try to go over my actual connection speed.. like 87% of my 100 mbit (so bandwidth=87M) Overhead seems to be ok for me.
If you have any ideas on how to not loose so much bandwidth for Cake to work, I am all ears..
EDIT: ok I think I get what you mean, by default if not specified, Cake assumes an egress queue.. by specifying an ingress queue, it will be better for ingresses. Yes please Mikrotik, add a check box/dropdown to specify ingress/egress
