Hello,

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

do you think it makes a difference whether I'm running V6 or V7 on the devices?

do you think it makes a difference whether I'm running V6 or V7 on the devices?

in 2116/2216 you will no have another option than running v7

if you are asking about performance improvements, you will not have any performance improvement moving your 1072/1036 to v7

to date the only relevant motivation to move a production router from v6 to v7 is the need to take advantage of some new feature only available on v7

anyone know what happen here internet port first port
idk when did that start happen ver7.3.1 CCR1036

Hi

Which is better to have in functionality to be BRAS/BNG 2116 or 1036?

Thank you

do you think it makes a difference whether I'm running V6 or V7 on the devices?

in 2116/2216 you will no have another option than running v7

if you are asking about performance improvements, you will not have any performance improvement moving your 1072/1036 to v7

to date the only relevant motivation to move a production router from v6 to v7 is the need to take advantage of some new feature only available on v7

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.

4 months and several versions since that post, no doubt things have improved

We tried v7 since 7.4 and got a really nice improvements also on older CCR. Better cpu utilization and distribution of loads.
Really nice!

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.

Or move to DHCP and dump PPPoE. PPPoE has MTU and CPU overhead due to encapsulation, DHCP does not have any such issues.

This
Mikrotik should really look into Option82 / CircuitID matching now that they're overhauling the DHCP service

Or move to DHCP and dump PPPoE. PPPoE has MTU and CPU overhead due to encapsulation, DHCP does not have any such issues.

I would dump PPPoE, but my radius/billing software is limited on other ways to AAA dhe dhcp clients.

Then dump your AAA software and switch vendor to one that keeps up with the times.

Can you suggest what king of authentication would be used along with DHCP?

Can you suggest what king of authentication would be used along with DHCP?

if your access network is open (ethernet switches ) you will need to stick with PPPoE for auth

in other access network like GPON you must authorize CPE so there is no much need for aditional auth

That's what I thought, so lets stick to the PPPoE, and original topic.

Can you suggest what king of authentication would be used along with DHCP?

DHCP options of your choice based on your needs, DHCP client ID, DHCP+RADIUS

https://docs.splynx.com/networking/auth ... hcp_radius

https://mum.mikrotik.com/presentations/ ... rllcom.pdf

https://systemzone.net/mikrotik-dhcp-se ... us-server/

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.

if your access network is open (ethernet switches ) you will need to stick with PPPoE for auth

Why? Perform MAC binding and use various DHCP options that you need or want and client ID.

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

How does DHCP MAC binding, options etc fail to work on BNG level even if the last-mile is a dumb switch? In all cases, the MAC binding should work.

if access layer switches do not enforce any other user can Clone the MAC address

Man, what are you talking about? That's possible on PON too with the right skillset. That doesn't stop anything.

then PPPoE does not solve the situation neither because with the right skillset. That doesn't stop anything.

then PPPoE does not solve the situation neither because with the right skillset. That doesn't stop anything.

Sure. You're arguing against DHCP. But since we agree both PPPoE/DHCP can't be stopped with the right skillset, why use PPPoE and lose MTU overhead/CPU overhead?