use dynamic Address-Lists, not static IP ranges
I don’t belive that is really a bug. Linux is not suitable for terminating hundreds of PPP-Users. Regardless if it’s L2TP or PPPoE. Maybe they have some small problems, so you run a little bit earlier in that problem. But over all, if you need to terminate 500+ Users, I prefer non Linux based solutions. As I figured out, we have a system which terminate 50.000+ PPP-Sessions without any trouble. No it’s not CISCO or Juniper and their is no Linux PPP-Stack used.
I heard on part-15 list that a number of users with a large number of PPPoE sessions jump to Imagestream as a PPPoE server. They state after that everything works fine. Imagestream is also based on linux AFAIK.
Matt
I have this problem even with much less than 500 online users.
I have this problem even with much less than 500 online users.
If Mikrotik could simply integrate a house keeping script that would detect PPPoE sessions with the queue problem and bump them off line or something that would be great. I just had a ‘user’ thats paying for a cheap 256k account run 5m all last night and max out a backhaul. Most likely everyone else feed by that backhaul had slow laggy service all night due to this. Come on Mikrotik we need a fix!
Matt
Hi Matt, it´s really annoying, whe have the same problem here. It already happened to us with just 40 connected users (nobody can say it´s due too much users online or too much traffic). It´s a huge bug that will make us abandon MK.
Hi,
we are supporting roundabout 250 WISPs in Europe using our concept with one central PPPoE-Server. Nobody have this problems with less than ~ 350 concurrent users.
WISPs with more than ~ 300 concurrent users are migrating away from the automaticly generated queues, they use adress-list or IP-Pools and PCQ.
WISPs with more than ~ 500 concurrent users we use our own special device for terminating tunnels with carrier class quality.
Maybe you have some other problems?
Regards
Lutz
This case we have to read:
Attention! Don’t use it with > 500 sessions.
I have 650 pppoe client on average, 900 on the heavy hour without problem.
My server Xeon 3.4ghz, 2mb cache l2 , 1gb ram. ROS 2.9.49. It have about 4 month without reboot.
Edit: It have 50mbps on wan, very strong quality of service, a lot firewall rules.
Regards
Max
http://mikrotikexpert.com
http://maxid.com.ar
Hi Max, in fact with 2.9 versions we had less problems than 3.x versions. But 2.9 is not compatible with some newer hardware or even with SMP.
We also see this problems with 2.9.x versions of RouterOS.
Regards
Lutz
Well, now you know and I´m not the only one. PCQ is not an option for me. I have some bandwidth fixed plans but I have a lot of users with dynamic bandwidth plans. Can I collect usage statistics of each PCQ queue by user via SNMP to generate reports? I don´t think so. There are a lot of services we have today that cannot be done with PCQ.
Hi,
It already happened to us with just 40 connected users
all I can say that we never see this problems with a RouterOS 3.x PPPoE-Server and less than 300 to 350 concurrend users, and we have access to lot of such systems. This is why I suggest that you maybe have any other problems.
For the reports, we use RADIUS accounting data to generate them. For the queues, what is not possible using PCQ instead of automaticly generated simple queues?
Regards
Lutz
If using PCQ queues and address lists really fixes this ‘BUG’ perhaps Mikrotik can add to the wiki an example of doing this with PPPoE and multiple speed profiles.
And I just realized, if your doing any other mangling or marking packets for any other purpose, well you just cannot at the same time as using PCQ with address lists. AFAIK a packet can not have more then one mark on it.
I would rather they just fixed there simple queues when used with PPPoE though.
Matt
I swapped my two pppoe server from simple queue to pcq, following the indication of this presentation http://mum.mikrotik.com/presentations/US08/janism.pdf
i have very wired results.
Some of my clients are really limited to the max limit of pcq, and some others to a quoter of that.
If i disable the queue into the wueue tree the clients that are overlimited started to fly…
I checked evertyhny…mangle trying different mangling strategies, but anytime there are clients over limited.
I am going back to dynamic simple queue…
Very frustrating-
Is Mikrotik working on a fix for this? Has anyone heard? ETA?
Matt
Man, I think I´m going to kill somenone (it´s really frustrating)… as I imagine MK is not a professional solution. I´m starting to look for other solutions.
Ok, don’t take this as Tik bashing… We still use it exclusively for core routing and firewalling, and are very happy with it.
But… We’ve been using an ImageStream linux router for PPPoE termination for several months now, following a fiasco with Mikrotik. The hardware is a 2.0GHz Celeron, with 1GB RAM. There are currently over 1800 simultaneous sessions with queues. Load average is 0.60, and everyone is getting their speeds consistently. Management UI sucks, and leaves much, much more to be desired, but performance is smooth… I’d take a happy customer over a shiny GUI any day.
Anyhow, it IS possible to terminate lots of PPPoE sessions with queuing on minimal hardware. It’s all in the implementation. I hope Tik gets these issues fixed soon because I miss the user interface 
Ok, at least something have to work on it. But to do only routing and firewall I can do it with a regular Linux. For me the only reason to use MK is for PPPoE server because for core router I only use Cisco (already had problems with other solutions). I was studying to change my entire system and plans to use PCQ but as I can see it has the same problem.
I would like to say that MT rules, but its pppoe server sux. So far I couldnt make at least one device (no matter what) running ros 3.x smoothly with pppoe server. The same setup but running DHCP and PCQ works perfectly on 3.11. Our pppoe servers was running a maximum of 50 simultaneous til ros 3.5 and above. Now we are forced to stuck upgrades in 3.4 for pppoe server and deal with other bugs that are already fixed on 3.11 (rip, ospf, etc). We have already a pppoe server MT running 2.9.45 smoothly since about a year, but you cant even dare to think in upgrade it. I think it is not really a bug on MT pppoe server, but I assure you the system get very unstable when using it on ros 3.11 and seems that its instability is increaseing on every ros version after 3.0rc. Supouts sent and they see nothing about freezing. Even the best hardware ive seen (rb433) from MT this issue happen but very often compared to a RB532 f.e. Ive lost my sleep for about a month to downgrade devices running pppoe server back to 3.4 and now the nightmare is back due to RIP/OSPF stuff bugged. Resuming, my issues with MT are only one: its pppoe server.
Do I need to hire normis to solve this? 
Does Imagestream use the Linux “Roaring Penguin PPPoE” Server implementation?
Matt