Dear MikroTik,
I’d like to request a feature that would greatly benefit many FTTH deployments: PPPoE Offloading/Multithreading.
Currently, PPPoE is processed on a single CPU core, which can become a bottleneck . Offloading PPPoE or leveraging multiple cores would boost performance and by eliminate single-core limitations,
Thank you for considering this enhancement.
Best regards.
I do hope that is on their roadmap.
Personally, I’ve only had encountered DHCP FTTH, but there’s a lot of people here on the forums with PPPoE FTTH.
+1.
+1
Do need to implement this, other band has implement hardware offload to create high speed NAT.
+1 too, I’m ready to get XGS-PON (on PPPoE) but need to get rid of Mikrotik first due to … no PPPoE support, even CCR2116 won’t handle 10gbit on PPPoE
Ubiquiti’s UCG Fiber supports PPPoE hardware offloading. For their flaws over the years, with privacy concerns around their management portal etc, they seem to have ramped up on the prosumer/SoHo front and now have a decent offering of new hardware offloaded devices, PoE switches capable of 2.5G (soon 10G) and good access points. We could be waiting a decade before seeing any traction on this in RouterOS.
At this point I’m considering a switch so that
MikroTik is too slow to the punch. My area was upgraded to XGS-PON and I now have symmetrical speeds. The CCR2116 (completely overkill for a home setup) peaked no higher than 1.8Gbps up/down when connecting to the WAN via SFP+. The speeds were all negotiated correctly and the firewall was very basic in terms of rules. The only bottleneck was down to single-threaded PPPoE performance which was evident based on the hardware performance when watching a single core spike.
I've purchased a Ubiquiti UCG-Fiber as I'm now at the point of leaving the MikroTik ecosystem. That has peaked at 2.7Gbits up/down with PPPoE hardware offloading enabled (hardware acceleration as it's called on their SOC)
Not much point really in using MikroTik if they're focusing on 1Gbit products as they have been with their past year of product launches.
Not even IPv6 works anymore on PPP...
Just move on, my 2c...
Unfortunately FTTH companies decided to using PPPoE with all of its disadvantages. PPPoE needs a lot more processing power on both side plus MTU is not standard ethernet so plus processing power needs to adjust TCP MSS.
A little out of scope, but does anybody knows why not dot1X they using instead?
It's not like there's a choice. The majority of ISPs in the UK, especially the multigig ones, use PPPoE with DHCPv6 for IPv6.
Living in a world with DHCP over PPPoE would be great - probably not going to happen in my lifetime with the stagnant ISPs
ISP is Hungarian Telekom over here, FTTH "modem" (which is a Sagemcom CPE router) in router mode is terminating the PPPoE and NATs. Its also terminating the DHCPv6PD, and on LAN side only serving IPv6 addresses with SLAAC. If I disable PPPoE in "modem" and enable PPPoE passthrough, then I can terminate PPPoE on my router but DHCPv6PD sometimes works, sometimes not. So I decide to let the modem fiddle with PPPoE, and using IPv6 SNAT to masquerade all of LAN addresses like in IPv4, went towards the path of least resistance.
No comment.
I googled this (PPPoE vs FTTH), and on reddit, the most answers is simly bullshits or outdated, but there are reasonable answers too like redundancy and fixed IP. Its easier to implement with PPPoE, but not impossible over wirespeed ethernet in current hardwares.
If you need more then 1-2Gbps over PPPoE, then you need much higher CPU frequency in modems or need PPPoE offload engine OR need some trick in SW. In my last tests, PPPoE and L2TP only fastpathed RX traffic only. I didn't see TX fastpath.
It is not like it cannot be made to work. Probably more a case of "incapable folks at ISP".
Over here we have PPPoE (over a VLAN), with RFC4638 to bring MTU back to 1500, IPv6 is working, and DHCPv6 is used to request prefixes to be routed to the customer.
It all works flawlessly on current RouterOS versions. No complaints.
Of course the extra load on the CPU is unfortunate, but other manufacturers use the SoC and/or switch chip capabilities to offload the handling of data packets to hardware. Hopefully at some time MikroTik will start doing that too.
W.r.t. the usage of PPPoE: as far as I understand this finds it origin in the capabilties of the network equipment, the scaling, and the local situation and regulations.
To comply with regulations here and in many EU countries, ISPs need to bring all customer traffic to central locations where it can be monitored and filtered. That precludes the easy network design where you put routers in every street cabinet and just route the traffic. PPPoE provides the tunnel to the central router (BRAS).
You could argue that this could be done with VLANs, but there can be only 4000 VLANs on a link unless you start using nested VLANs. And the equipment available at the time probably did not support it.
Remember that ISPs often provide at least 3 different services: internet, telephony and TV, and they often are separated on different logical circuits for reasons of rate limiting (e.g. your TV viewing does not cut into your subscribed internet bandwidth or data bundle) and QoS (your phone traffic always gets highest priority, it will remain real-time no matter how much your internet or TV loads the connection).
To facilitate that, different VLANs are used again towards the customer, and bringing them all the way into the central router would further worsen the scaling issues.
Furthermode, the company implementing the connection network may be different from the ISP. E.g. I get internet here from a provider that in turn leases VDSL connections from a network provider. The PPPoE from my side is handed over to the internet provider at some point. My neighbor may have VDSL at the same network provider, but internet from a differnt ISP.
So PPPoE it is. I don't thing that will suddenly change, if only because of the nightmare a migration would be.
I don't know why everyone is waving the vlan flag. TV and telephone streams already runs on wire without PPPoE header, only Internet is on PPPoE. Carrier ethernet has already been invented, there is no need to allocate vlans for every customer. In my opinion, this is laziness and/or thrift. Its cheap, and already works, however after one point it wont be enough, because of the bandwidth. Without offloading, it stops around 2Gbps, even if the HW could forwarding 10Gbps linerate on ethernet.
When you are an ISP with millions of customers every "just change this to that" in the network is a major operation that won't just be done because some routers are overloaded at high speeds.
And to be clear: those ISPs that provide multi-gigabit connections provide the routers that go with it and that do the task. E.g. our local provider has a 4Gbps offering on their XSG-PON network and they provide a consumer router with it, mentioning that it is suitable up to 10 Gbps. It is ISP branded but they usually source these things from manufacturers like ZTE and AVM.
This is what I saying. Forcing vs thinking. It is very rare when someone looks back and thinks about whether they are on the right path or if they should look for a new one. This characterizes most of the ISP sector, with respect to exceptions.
You should face it that ISPs have other reasons for their decisions than a customer may think are relevant.
It could well be different for a small ISP that covers a regional area (like a city) in a country that has just started to do those things and is not living under e.g. EU rules, true.
"being on the right path" is different depending on where the path is, where it came from, and what it will be leading to.
Anyway, I am all for PPPoE hardware offloading. Not so much for multithreading, that leads to packet re-ordering and we know the trouble that got us into with IPsec multithreading.
In my country I resell fiber connection 2.5Gbps up/1Gbps down on GPON with ZTE ZXHN F6005 & RB5009 and work at full speed up/down without problem...
(RB5009UPr+S+ ROS 7.16.2, VLAN on WAN, PPPoE on VLAN)
Just my 2c too - but in terms of the ISP/Carrier side, there are numerious ways to overcome the VLAN per customer thing... MPLS/VXLAN is just two. I dont quite understand why VLANs per say is even braught up. How the traffic gets to the BNG, or to the customer, is irrelavent - the fact remains the client and the BNG does not perform as far as Mikrotik is concerned. Point, Period, Done.
Be careful because this kind of PPPoE hardware offloading only works if QoS or traffic control is disabled.
If you enable QoS, UCG-Fiber can reach a maximum of 1.2- 1.5 Gigabit/s with CPU at 99%.
Personally tested with FTTH PPPoE with VLAN ID.
MikroTik with FastTrack performs much better and offers many QoS possibilities, for example with Queue Tree without disabling FastTrack.
I don't like talking about other manufacturers in this forum so I'll leave it at that.
Yes, it would be great to have PPPoE Offloading/Multithreading on MIkroTik devices.
BTW... For those preaching DHCPv6.... Even that, is not working... At least, not for me:
BNG:
[x@x] /system/logging> /ipv6/dhcp-server/print
Flags: D - DYNAMIC
Columns: NAME, INTERFACE, ADDRESS-POOL, PREFIX-POOL, PREFERENCE, LEASE-TIME
# NAME INTERFACE ADDRESS-POOL PREFIX-POOL PREFERENCE LEASE-TIME
0 D <pppoe-cpe02> <pppoe-cpe02> static-only static-only 255 1d
1 D <pppoe-cpe03> <pppoe-cpe03> static-only static-only 255 1d
2 D <pppoe-cpe01> <pppoe-cpe01> static-only static-only 255 1d
^^ Created with Framed-IPv6-Pool and Framed-Delegate-Pool
2025-08-20 16:31:58 dhcp,debug,packet send <pppoe-cpe01> -> fe80::72d8:2a80:ef24:ca52%55
2025-08-20 16:31:58 dhcp,debug,packet type: reply
2025-08-20 16:31:58 dhcp,debug,packet transaction-id: 8387b1
2025-08-20 16:31:58 dhcp,debug,packet -> clientid: 00030001 00000000 0000
2025-08-20 16:31:58 dhcp,debug,packet -> serverid: 00030001 000c29fd ab67
2025-08-20 16:31:58 dhcp,debug,packet -> ia_na:
2025-08-20 16:31:58 dhcp,debug,packet t1: 43200
2025-08-20 16:31:58 dhcp,debug,packet t2: 69120
2025-08-20 16:31:58 dhcp,debug,packet id: 0x8
2025-08-20 16:31:58 dhcp,debug,packet -> status: 2 - no address
2025-08-20 16:31:58 dhcp,debug,packet -> rapid_commit: [empty]
2025-08-20 16:31:58 dhcp,debug,packet -> ia_pd:
2025-08-20 16:31:58 dhcp,debug,packet t1: 43200
2025-08-20 16:31:58 dhcp,debug,packet t2: 69120
2025-08-20 16:31:58 dhcp,debug,packet id: 0x8
2025-08-20 16:31:58 dhcp,debug,packet -> status: 6 - no prefix
The PPP server itself, is not even finding it's own created DHCPv6 server address/pool that is configured by itself, via radius....
Client, is obviously not happy either:
2025-08-20 16:31:29 dhcp,debug,packet transaction-id: 8387b1
2025-08-20 16:31:29 dhcp,debug,packet -> clientid: 00030001 00000000 0000
2025-08-20 16:31:29 dhcp,debug,packet -> ia_na:
2025-08-20 16:31:29 dhcp,debug,packet t1: 0
2025-08-20 16:31:29 dhcp,debug,packet t2: 0
2025-08-20 16:31:29 dhcp,debug,packet id: 0x8
2025-08-20 16:31:29 dhcp,debug,packet -> elapsed_time: 139
2025-08-20 16:31:29 dhcp,debug,packet -> rapid_commit: [empty]
2025-08-20 16:31:29 dhcp,debug,packet -> reconf_accept: [empty]
2025-08-20 16:31:29 dhcp,debug,packet -> ia_pd:
2025-08-20 16:31:29 dhcp,debug,packet t1: 0
2025-08-20 16:31:29 dhcp,debug,packet t2: 0
2025-08-20 16:31:29 dhcp,debug,packet id: 0x8
2025-08-20 16:31:29 dhcp,debug,packet recv client: pppoe-out1 fe80::2126:6152:f0:37 -> fe80::72d8:2a80:ef24:ca52
2025-08-20 16:31:29 dhcp,debug,packet type: reply
2025-08-20 16:31:29 dhcp,debug,packet transaction-id: 8387b1
2025-08-20 16:31:29 dhcp,debug,packet -> clientid: 00030001 00000000 0000
2025-08-20 16:31:29 dhcp,debug,packet -> serverid: 00030001 000c29fd ab67
2025-08-20 16:31:29 dhcp,debug,packet -> ia_na:
2025-08-20 16:31:29 dhcp,debug,packet t1: 43200
2025-08-20 16:31:29 dhcp,debug,packet t2: 69120
2025-08-20 16:31:29 dhcp,debug,packet id: 0x8
2025-08-20 16:31:29 dhcp,debug,packet -> status: 2 - no address
2025-08-20 16:31:29 dhcp,debug,packet -> rapid_commit: [empty]
2025-08-20 16:31:29 dhcp,debug,packet -> ia_pd:
2025-08-20 16:31:29 dhcp,debug,packet t1: 43200
2025-08-20 16:31:29 dhcp,debug,packet t2: 69120
2025-08-20 16:31:29 dhcp,debug,packet id: 0x8
2025-08-20 16:31:29 dhcp,debug,packet -> status: 6 - no prefix
2025-08-20 16:31:29 dhcp,debug ia_pd: bad status in advertise: no prefix (6)
I seriously don't understand how MT can claim there is nothing wrong with PPP. From what I am seeing, and where I am sitting, it is horribly broken in v7