After 2 years of ticketing about performance problems on mikrotik PPPOE server the only answer from sopirte was that ppp is processed on 1 core. SUP-110632
Is it so difficult to balance the consumption of the pppoe server process on several cores?
What is the point of having a good amount of cores in my mikrotik, particularly talking about 1036 and 2116?
Mikrotik knows that their equipment is largely used as a PPPOE server, why do they limit their performance then?
Interesting that they just responded with, “it uses one core and that’s how it is,” because I am not seeing this. What exact hardware and RouterOS version are you using?
At that time I’m sure it was on some very new stable v7 version… today it’s running on v7.16.1 with the same behavior… one core decouples and goes to 100% while other cores are below 30 or 40%.
There is not much to check I will have about 25 raw rules and 3 or 4 NAT rules a lot of that to redirect debtors which will be 4 or 5 users today, authentication on radius and accounting as well.
This happens with 2.5 to 3GB of peak traffic with 850 to 900 active pppoe sessions.
This is what mikrotik support told me in the ticket.
“It’s important to note that in RouterOS, packets from a single connection are typically handled by a single CPU core. This includes PPPoE traffic, which is treated as a single PPPoE connection at the L2 level and is often processed by a single core. However, this does not mean that the handling of IP packets, including tasks such as firewall and NAT, will not use multiple CPU cores. Only the PPPoE encapsulation process itself is typically limited to a single CPU core.”
My work around was always just to use multiple vlans with multiple PPPOE servers which would make sense why it seems to work given the response. So for example if I have two OLT’s I would run a different VLAN to each with there own IP pool range. Never knew why it seemed to work just that it did.
I understand it, although I don’t agree that mikrotik can’t solve this in another way, I wish some mikrotik engineer could tell us if in the future we will be able to use those 16 or 32 cores without the need to do some configuration maladjustments to cover optimization failures…
i think there is something specific in your scenario that makes this more notorious, maybe you are pushing heavy traffic across a single pppoe tunnel or a single tcp/ip connection
also keep in mind balancing cpu load across multiple cores is not a trivial task, as they say traffic with same characteristics go by the same cpu core, i think mostly to keep packets delivered in order, also some years ago has been explained that “moving” packets from one cpu core to another is “expensive” so its sometimes create more cpu load than it saves
if you have a high amount of traffic concentrated on a single pppoe or a single tcp/ip connection maybe you could consider moving that special/specific load to a diferentt scheme
Actually the scenario is pretty standard, pppoe server running over a sfp+2 physical interface using radius for authentication and accounting, 1 queue per client (dynamically generated by radius) with symmetric speeds between 50 and 300mbps… I could tell you that there is very little saturation in those queues, very few users get to saturate their queue, I would say none but at times there may be 5 or 6 that have a higher traffic probably because of some download.
30 raw rules and 1 firewall filter, 4 NAT rules that only apply to debtor users (4 or 5 generally).