I’m currently using a CCR1072 and a CCR1036 for the PPPoE session for around 2000 users, each with 1000 active users. Now I would like to improve the performance when processing the PPPoE sessions. I buy two CCR2116. or should I better use two 1072 and install the V7.x on it?
i think 1072/2216 is not optimal for BRAS/BNG/PPPOE concentrator
1072/2216 are best used as border/core routers in fast-track mode or fast-path (in 2216 hardware accelerated routing)
using 1072/2216 as a BRAS/BNG/PPPOE concentrator is a waste of money
2 x 1036 work better, more performance as a BRAS/BNG/PPPOE concentrator than a single 1072 and are cheaper
2 x 2116 work better, more performance as a BRAS/BNG/PPPOE concentrator than a single 2216 and are cheaper
in your scenario the 1072 you already have will be better as core router only (without pppoe or queues) for your fleet of 1036 and 2116 working as pppoe concentrators for end users
That is not true.
We got HUGE performance improvements in cpu usage of both 1036 and 1072.
We got higher cpu usage in lower end routers because of the missing route cache, but everything is working as expected.
we upgraded the whole network from latest 6 LTS to 7.4, now to 7.6 without any issues, other than adapting the route filters to the new syntax.
I have 2400 pppoe users in a single CCR1036.
All those pppoe users coming from the same sfp+ interface, but divided in 7 vlans. In each vlan interface there is a pppoe server.
Other than that it has same number of ques, albeit 100 mbps and 200 mbps queues which hardly get filled. Also doing NAT with about 60+ source NAT filters. Other than that, simple firewall and default route to my upstream provider. (no BGP). It handles 3500Mbps upstream traffic, in the peak hours.
RouterOS ver. 6.48.1 and surprisingly it works without any problem.
I’m I overloading it?
I bought a CCR2116 two weeks ago, but there is not rush, I will either replace the old one, or put them in work together.
Anyone advising PPPoE in 2022 is the same as advising IPv4 instead of IPv6. I wouldn’t count them as competent experts.
There’s no magic that will remove CPU+MTU Overhead of PPPoE. The closest is RFC4638, but that only solves the issue on ISP side as most CPE on their side do not support it other than MikroTik CPEs or similar.
at the end a secure access layer is the better way and a must have
the problem arise when using non managed access layer like dumb ethernet switches (non capable of binding or any other security function) , trying to compensate the lack of security on access layer enforcing some mechanism on the gateway is the limiting factor
with every day higher and higher speeds like GPON, including s encapsulating mechanism like PPPoE is a unneeded overhead not only beacuse of MTU issues, but the encapsulating process consumme resources
so if you provide slow speeds you can live with PPPoE without problem
for high speed trowing out PPPoE provides performance and scalling gains, but you need a Access layer capable of securing some access like GPON