Hi Everyone!

We have a PPPOE server with 500-600 users. Sometimes the users queue won't work, users have a 512k/128k but they can download 2-5 MB, if we close all the session after one-two days queue problem renews. - we use MT 3.7 , 3.9 and now I hope 3.10 will solve this problem...Any other suggestion? MT 3.3 works great? Or what is the last version that good for PPPOE server?

Thanks in advice!

Josh

Yesterday we upgrade to 3.10 but we have this the problem today, SO???? Any suggestion???

Hi,

Do you use 'change TCP MSS' feature?
What kind of queues do you use?

Regards
Lutz

i saw the same on 3.7

whe mangle the tcp mss and use default queu configured as pfifo with 100 paclet queue.

Regards
Ros

whe mangle the tcp mss

What do you mean here? Static Rule for all, or automaticly Rules per PPPoE-Login?

Regards
Lutz

static rule for all the subnets inside the ippool used by pppoe server

Regards
Rosario

I have the same problem. I see the queue simple without counting upload or download. If this happend i do an script to disable and enable this queue, after that the queue work fine.


Max
http://mikrotikexpert.com
http://maxid.com.ar

Any news about this problem?

I know a lot of people having it (including me) but no news about a fix.

Hi,

first off all make shure that you don't use the automatic change MSS feature. You can use 2 static rules for all instead of 2 dynamic rules per PPPoE-User for that feature. Save 1.198 rules by 600 connected PPPoE-User.

Second, don't use the rate limit per PPPoE-User or Profile, this also generate 2 simple queues per loged in PPPoE-User. Use PCQ-Queues instead against adress-lists or IP-Pools. This also save hundreds of simple-queues.

You maybe also use a little bit higher queue sizes (default = 10 if I remember correctly) try 100 here.

If you done this all, you should be able to run some more PPPoE-Clients without having that problem. But still remember also that the PPP-Stack in linux is not optimal for use as access concentrator. We have a system which is able to terminate > 50.000 concurrent sessions, but this is not linux based.


Regards
Lutz

Hi, I already made some tests on it disabling automatic MSS and use only two static rules. No performance change (maybe I don´t have too much users for that).

Use PCQ instead of dynamic rules is out of question. I lost too much control doing that and I have clients with too many different plans and speeds (a lot of clients have specific bandwidth). This is not a solution.

I don´t have too much online clients per MK router.

I my point of view it´s a primary MK feature (shape bandwidth for online clients) and it must work.

Hi,

first off all make shure that you don't use the automatic change MSS feature. You can use 2 static rules for all instead of 2 dynamic rules per PPPoE-User for that feature. Save 1.198 rules by 600 connected PPPoE-User.

Second, don't use the rate limit per PPPoE-User or Profile, this also generate 2 simple queues per loged in PPPoE-User. Use PCQ-Queues instead against adress-lists or IP-Pools. This also save hundreds of simple-queues.

You maybe also use a little bit higher queue sizes (default = 10 if I remember correctly) try 100 here.

If you done this all, you should be able to run some more PPPoE-Clients without having that problem. But still remember also that the PPP-Stack in linux is not optimal for use as access concentrator. We have a system which is able to terminate > 50.000 concurrent sessions, but this is not linux based.


Regards
Lutz

No news? MK support say it´s a bug but no more information if it will be fixed or when.

Continue using MK to control my users bandwidth is becoming useless, so I need to look for a professional solution. Anybody here hows a good and professional PPPoE Server ?

Hi,

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.


Regards
Lutz

Hi,

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.


Regards
Lutz

I think the problem is not related with PPPoE code, but with dynamic queue and PPPoE interface. It happens with much less than 500 online users (500 users is the max I have per MK router).

What solution you have? I need a better solution than Mikrotik (I need something that works).

We have our own system, complete developed by our technologie partner in Germany and tested and in production by very huge ISPs here since the last years. The system is based on a 16 core Cavium CPU with complete own routing software for OSPF/BGP4 (fully featured routing policies and IPv6), PPPoE & L2TP in and out, L2TP Tunnel-Switch, loadbalancing across several DSL-Uplinks. Tested with a load from > 50.000 L2TP- or PPPoE-Sessions. And lots more.

For more information please contact me per email directly.


Regards
Lutz

Hi everybody...

I am having this same problem. It used to happen with 2.9.x, and is happening with 3.x (we actually run 3.9 on 10 different Mikrotiks).

I have read the previous messages and to my surprise the only useful messages are talking about "moving to other solutions". What Mikrotik support team thing about this ???

I really need a solution. My core Mikrotik usage is as PPPoE concentrator, so this problem is SERIOUS...

Thanks in advance.

Denio A. Lindo
Desktop Internet Services

I am here too.

I started to experience this issue something later then 2.9.3x.

The early 3.x seems not affected but now the problem is there too.

Support wrote me to pass to new feature present on 3.10 to use pcq.........

Strange that all the major MT issues were about queue.
I think they should improve the area of the code.

Regards
Ros

I am here too.

I started to experience this issue something later then 2.9.3x.

The early 3.x seems not affected but now the problem is there too.

Support wrote me to pass to new feature present on 3.10 to use pcq.........

Strange that all the major MT issues were about queue.
I think they should improve the area of the code.

Regards
Ros

They should be kidding that use PCQ is the solution. As I can see MK is not a serious solution.

Hello,

I think MT is a serious solution, but sometimes restricted to the Linux. If you need more in some special situations, e. g. a PPPoE-Server for more than roundabout 500 concurrent user, you may take a specialized solution for this topic, and not a full featured RouterOS System.

Regards
Lutz

Have been seeing this issue since 2.9.x as well. Would really like a solution. Do not really want to use PCQ for same reasons someone else already mentioned. Do not want to have to change a users IP range when they change rate plans.

We really need this issue fixed.

Matt

I have the same problem. I see the queue simple without counting upload or download. If this happend i do an script to disable and enable this queue, after that the queue work fine.

Can you share this script?

Matt

Do not want to have to change a users IP range when they change rate plans.

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

Hello,

I think MT is a serious solution, but sometimes restricted to the Linux. If you need more in some special situations, e. g. a PPPoE-Server for more than roundabout 500 concurrent user, you may take a specialized solution for this topic, and not a full featured RouterOS System.

Regards
Lutz

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

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

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

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

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

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

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-

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.

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

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

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?

I agree with you. But as everybody is saying it´s because Linux kernel problems it´s better to hire Linus.

I agree with you. But as everybody is saying it´s because Linux kernel problems it´s better to hire Linus.

If so how did Imagestream get around the linux kernel problems? I really doubt its a kernel issue.

Matt

i think the discovery path is the following:
1. MT says: there isn't any problem;
2. MT says: we tested your configuration and didn't find anything;
after dozen mails and supout....
3. MT says it is a kernel issue
after months of posting..............
4. MT says we will fix it.

I hope MT will fix it ASAP.

regards
ros

3. MT says it is a kernel issue
after months of posting..............

I have never heard Mikrotik say that. Only place I heard that was in this thread and it did not come from Mikrotik. Perhaps they told someone that somewhere else?

4. MT says we will fix it.

If they said that I am happy. Did you get that in an email? As long as its fixed soon, within month or two?

Matt

i was referring to a generic way they approc an issue.

I wasn ot speaking about this issue in particular.

Regards
ros

i was referring to a generic way they approc an issue.

I wasn ot speaking about this issue in particular.

Regards
ros

I have completely different experience:

1) report the issue in details
2) Mikrotik - unable to repeat
3) me - here you go full access to my router
4) Mikrotik - yes, we see the issue, can we reboot, put debug etc...
5) me - yes
6) Mikrotik - ok, it looks like we have done it, could you test our bugfix we applied it on your router.

the most problematic part is 1) - you really need to put research into it, what kkind of traffic, what kind of situation etc. - If you just yell that "I have a problem, fix it." then ofcourse you will get something like that.

BTW: there are actual problem with Linux Kernel - i major cases related to Intel products (those guys always make something differently)

i was referring to a generic way they approc an issue.

I wasn ot speaking about this issue in particular.

Regards
ros

I have completely different experience:

1) report the issue in details
2) Mikrotik - unable to repeat
3) me - here you go full access to my router
4) Mikrotik - yes, we see the issue, can we reboot, put debug etc...
5) me - yes
6) Mikrotik - ok, it looks like we have done it, could you test our bugfix we applied it on your router.

the most problematic part is 1) - you really need to put research into it, what kkind of traffic, what kind of situation etc. - If you just yell that "I have a problem, fix it." then ofcourse you will get something like that.

BTW: there are actual problem with Linux Kernel - i major cases related to Intel products (those guys always make something differently)

Hi, have you done it for this particular issue? Because we already sent all we could collect about it. They replied it will be fixed on the next release but it was a long time ago and we continue to have the same problem.

didn't "next release" fix the issue?

didn't "next release" fix the issue?

is it a joke?

No, I'm serious. If support promised that bug is fixed in next release - Did you try the fixed release?

How do you expect MikroTik to fix bugs, magically apply fixes to your system without upgrade???

No, I'm serious. If support promised that bug is fixed in next release - Did you try the fixed release?

How do you expect MikroTik to fix bugs, magically apply fixes to your system without upgrade???

What's new in 3.11:

*) fixed bug - in some cases web proxy https with parent-proxy did not work;
*) added default-route-distance setting for DHCP client;
*) mesh protocol
*) multicast
*) user manager
*) added ability to dst. nat only address or port, not both at the same time;
*) ospf
*) ipsec
*) port remote-access
*) ethernet half duplex modes on rb400 series work now;
*) console
*) console
*) console
*) console
*) console
*) console
*) console

Where?

Changelog doesn't include all minor fixes. Too bad, but that's the way it is. That is why support specifically said that it will be fixed, You should test and see. If it still doesn't work, report to support and they will check why

As i wrote above no one told me it will be fixed in next release about the particular issue about this thread!!!!

As i wrote above i reported my feeling about the generic way MT responds. No feedback from MT about this issue.

I am running the latest release on my 2 pppoe servers but the issue is still there.

Regards
Ros

I don't know about this issue. I just commented the person who said "support told me it will be fixed in next release"

I also have noticed this problem.. All my PPPoE concentrators are running 2.9.46. I've been holding off on upgrading them until this particular problem has been addressed.

Basically what happens is a user connects, but for some reason the simple queue does not get created for their interface, thus giving them an unlimited connection. I've had users getting 10+mbps because of this. I usually catch it, and the fix is to remove their PPPoE session and it will then reconnect and recreate the queue properly. It happens inconsistently but I'd say I see it happen a few times a week.

I have 3 PPPoE concentrators with 300+ users on each of them, and it happens on all of them. I have a whole Customer Information System (CIS) that is designed around RADIUS, Mikrotik, and PPPoE.. So changing to PCQ wouldn't be my ideal solution. I do have the ability to specify an IP address pool through my CIS but that would require going through the 1000+ accounts and changing each one to match their specific connection speed. Using a dynamic address list may be possible, but can you add an account to an address list through RADIUS? If not whats the point? I'm looking to reduce administrative overhead as much as possible.

Here's the topic I started on this exact problem almost a year ago...

http://forum.mikrotik.com/viewtopic.php ... ple+queues

No, I'm serious. If support promised that bug is fixed in next release - Did you try the fixed release?

How do you expect MikroTik to fix bugs, magically apply fixes to your system without upgrade???

Sure I tested not only the "next release" but all releases after that.

In my case the queue is created but the traffic doesn´t flow thru it. I now a person who have this same problem that told me if you disable que queue and re-enable it the traffic starts to flow thru it.

I also have noticed this problem.. All my PPPoE concentrators are running 2.9.46. I've been holding off on upgrading them until this particular problem has been addressed.

Basically what happens is a user connects, but for some reason the simple queue does not get created for their interface, thus giving them an unlimited connection. I've had users getting 10+mbps because of this. I usually catch it, and the fix is to remove their PPPoE session and it will then reconnect and recreate the queue properly. It happens inconsistently but I'd say I see it happen a few times a week.

I have 3 PPPoE concentrators with 300+ users on each of them, and it happens on all of them. I have a whole Customer Information System (CIS) that is designed around RADIUS, Mikrotik, and PPPoE.. So changing to PCQ wouldn't be my ideal solution. I do have the ability to specify an IP address pool through my CIS but that would require going through the 1000+ accounts and changing each one to match their specific connection speed. Using a dynamic address list may be possible, but can you add an account to an address list through RADIUS? If not whats the point? I'm looking to reduce administrative overhead as much as possible.

in my case the queue is created too but after a while (around 4/5 days) the traffic stops to flow into it.

regards
Ros

In my case the queue is created but the traffic doesn´t flow thru it. I now a person who have this same problem that told me if you disable que queue and re-enable it the traffic starts to flow thru it.

In that case. Is it possible to write a script that at 3am or so evry night it disables then reenables all the queues on the box? Might be a temp fix?

Matt

http://forum.mikrotik.com/viewtopic.php?f=2&t=24224

Dynamic PPP Address list looks like it might be a viable solution... at least for me.. I can change the attribute in my management system so instead of passing mikrotik-rate-limit for the rate plans i can create dynamic address lists based on the same value and just change the RADIUS attribute.

Then create the PCQ's and get rid of all the simple queues.

This might be a solution... at least for my setup.

Dynamic PPP Address list looks like it might be a viable solution... at least for me.. I can change the attribute in my management system so instead of passing mikrotik-rate-limit for the rate plans i can create dynamic address lists based on the same value and just change the RADIUS attribute.

Then create the PCQ's and get rid of all the simple queues.

This might be a solution... at least for my setup.

Someone else in this thread stated they switched to PCQ like that and still had the same issues.

Matt

In my case the queue is created but the traffic doesn´t flow thru it. I now a person who have this same problem that told me if you disable que queue and re-enable it the traffic starts to flow thru it.

In that case. Is it possible to write a script that at 3am or so evry night it disables then reenables all the queues on the box? Might be a temp fix?

Matt

But at 3am just a few users are connected and this is a random problem. If the user connect in the middle of the day? Most of my users connect, use Internet and then disconnect.

Dynamic PPP Address list looks like it might be a viable solution... at least for me.. I can change the attribute in my management system so instead of passing mikrotik-rate-limit for the rate plans i can create dynamic address lists based on the same value and just change the RADIUS attribute.

Then create the PCQ's and get rid of all the simple queues.

This might be a solution... at least for my setup.

Someone else in this thread stated they switched to PCQ like that and still had the same issues.

Matt

Exactly. He said it was even worst then dynamic queues.

But at 3am just a few users are connected and this is a random problem. If the user connect in the middle of the day? Most of my users connect, use Internet and then disconnect.

In my experience this affects more users that stay connected 24/7 then those that disconnect and reconnect. Problem is on a user connected 24/7 that is a bandwidth hog they will be online with no rate-limit for weeks. Reseting the queues every 24 hours insures they will only get away with it 24 hours at most.

Matt

But at 3am just a few users are connected and this is a random problem. If the user connect in the middle of the day? Most of my users connect, use Internet and then disconnect.

In my experience this affects more users that stay connected 24/7 then those that disconnect and reconnect. Problem is on a user connected 24/7 that is a bandwidth hog they will be online with no rate-limit for weeks. Reseting the queues every 24 hours insures they will only get away with it 24 hours at most.

Matt

This is a important information. I will pay attention for how long time the user was online when this happen. But how do you disable and enable a dynamic queue? This option is not available at WinBox for this kind of queue. This can be done via script?

But how do you disable and enable a dynamic queue? This option is not available at WinBox for this kind of queue. This can be done via script?

It can be done on terminal. Not sure if disabling and enabling the queue actually causes the PPPoE user to be ratelimited again. Someone else in this thread heard it did.

Matt

i think the discovery path is the following:
1. MT says: there isn't any problem;
2. MT says: we tested your configuration and didn't find anything;
after dozen mails and supout....
3. MT says it is a kernel issue
after months of posting..............
4. MT says we will fix it.

I hope MT will fix it ASAP.

Our experience is like this one:

1. MT says: there isn't any problem;
2. MT says: we tested your configuration and didn't find anything;
after dozen mails...
3. MT says: give us password of your router and we will investigate directly
4. MT says: you see there is not a problem.. (after print screen proofs)
after posting again on mikrotik forum
5. MT says: you are banned now on forum as forum is not a place for you (to post bugs of RouterOS)

And situation on forums:

1. We post about packet loss problem
2. Mikrotik "forum specialists" says: You do not know how to use mikrotik routeros
3. Mikrotik Support warns that we should not post about bugs on forum
4. We are banned from forum
5. Other mikrotik users report pppoe packet loss issue

You can read some in: http://forum.mikrotik.com/viewtopic.php ... &sk=t&sd=a

This particular problem was about packet loss in PPPoE in 3.xx versions. We are still on 2.9.51, but the big problem is random queue missing problem. We must restart it every 10-13 days. And we will not dare to upgrade to 3.11 as possible packet loss can appear.

we have done some fixes and improvements in simple queues and pcq, and made a special "test" package. if anyone is interested to test this package, and help mikrotik solve this problem, write to support

we have done some fixes and improvements in simple queues and pcq, and made a special "test" package. if anyone is interested to test this package, and help mikrotik solve this problem, write to support

Thanks Normis.. this is what everybody here wants.. MK team trying to solve the problem.

Take a look at these screen shots and let me know what you guys think. How could pppoe account for apt79 be getting 128k/8M when he is limited to 128k/256k. Is it the same issue that you are having ? I have attached some screen shots for apartment 79 who I caught one night. He is was getting 8M at the time !
Is the Queue working correctly for the PPPoe Connection ? I am using ROS 3.11, I know that Screenshots are 3.9 but the problem is still happening.

I noticed this before because the whole building is sometimes using upto 40Mb of bandwidth and this should not be happening as most if not all users are limited to 128k/256k. There are some 1M/3M connections but even if all logged in at the same time they would not sum to a demand of 40Mb-1.

What do you think ? Can someone fool the Mikrotik to give it unlimited bandwidth when connected by pppoe ? I though that someone had hacked the pppoe queue control !! Scary thought..

It is like the PPP Interface and the Queue Control has seperated or is not counting traffic correctly.
I monitor the overall link with Dude and do not have a daily traffic chart to show you but it is dramatic when the pppoe queue control is removed. You can see some examples on the weekly chart and remember that they are averaged down so you don't see the full speed that the user got at the time.

Forget about RX - take a look at TX on the opposite interface.

RX is received speed - it is before the actual limitation takes place.

you need to check both TXs:
1) for upload - TX on public interface
2) for download - TX on local interface

The TX on ETH0 is the upload as ETH0 is the public interface.
I am just monitoring ETH0 in Dude for RX and TX as it shows me what the overall site is doing. It helps me spot inconsistancies in the sites bandwidth usage (thats all)

I do not have any IP address on ETH1 as I am using pppoe only on the local side.

The point is that pppoe user account apt79 in the screenshots is getting 9.5Mb Download as per the pppoe account dynamic interface, eventhough apt79 has a dynamic queue limitation of 256k Download/128k Upload as per the profile for his pppoe account. The queue limit appears correct eventhough the dynamic pppoe interface is not being controlled.

I used torch to check the amount of bandwidth that this user was getting by the public IP address that he is using (this is blanked out in the pictures above for privacy issues)

If I log apt79 out of the system "manually" when he reconnects he seems to be limited correctly again.

This happens with other users too randomly.

The TX on ETH0 is the upload as ETH0 is the public interface.
I am just monitoring ETH0 in Dude for RX and TX as it shows me what the overall site is doing. It helps me spot inconsistancies in the sites bandwidth usage (thats all)

I do not have any IP address on ETH1 as I am using pppoe only on the local side.

The point is that pppoe user account apt79 in the screenshots is getting 9.5Mb Download as per the pppoe account dynamic interface, eventhough apt79 has a dynamic queue limitation of 256k Download/128k Upload as per the profile for his pppoe account. The queue limit appears correct eventhough the dynamic pppoe interface is not being controlled.

I used torch to check the amount of bandwidth that this user was getting by the public IP address that he is using (this is blanked out in the pictures above for privacy issues)

If I log apt79 out of the system "manually" when he reconnects he seems to be limited correctly again.

This happens with other users too randomly.

This is exactly the same problem whe have. We will test this beta version that Normis is talking about to see what happens.

It happened again last night. I have been running ROS 3.12 (Beta) that Mikrotik gave me to test and this is the first time that I have seen it all week. It usually happened at weekends in the past. Most users are at home then in this apartment block.

See DUDE graph. The upload speed of >12.5Mb is impossible with the customer base in the building.

Does anyone have a script that I could use to detect the excess usage and disconnect the pppoe account until this issue is solved ?

It happened again last night. I have been running ROS 3.12 (Beta) that Mikrotik gave me to test and this is the first time that I have seen it all week. It usually happened at weekends in the past. Most users are at home then in this apartment block.

See DUDE graph. The upload speed of >12.5Mb is impossible with the customer base in the building.

Does anyone have a script that I could use to detect the excess usage and disconnect the pppoe account until this issue is solved ?

Bad news. I had some hope with this beta version.

ROS 3.12 is now released; change log tells that problem was fixed. Any one tested this version yet??

ROS 3.12 is now released; change log tells that problem was fixed. Any one tested this version yet??

I hope this fix is not the same as 3.12 beta because as told above the problem was not fixed with this beta version.

Crossing my fingers..

Any luck with 3.12 or 3.13?

I've been watching this with keen eyes too. Almost our whole customer base is authenticated with PPPoE and have dynamic queues to limit each connection (Usermanager rocks!).

Does release 3.12 solve the dynamic queue issue in the field?

Does release 3.12 solve the dynamic queue issue in the field?

We have been running 3.12 for over 2 days now but it typically takes at least a week to act up so am not sure yet. So far so good though. Will likely update to 3.13 here shortly though.

Matt

any update from who is testing 3.13?

then please report also the platform, RB or x86.

Regards
Ros

Anyone? I had a user getting 10+mbps for a week.. Wasn't really effecting overall performance for the network but annoys me that this user was getting something for nothing !

I'm about to bite the bullet and just try it myself...

[quote]Anyone? I had a user getting 10+mbps for a week.. Wasn't really effecting overall performance for the network but annoys me that this user was getting something for nothing ![quote]

Was running 3.12 shortly after it came out. Now running 3.13. Have not seen the issue YET. Its too soon to be sure though. Why not try it?

Matt

*** BUMP ***

Also waiting more feedback to see if this is finally done.

Anyone? I had a user getting 10+mbps for a week.. Wasn't really effecting overall performance for the network but annoys me that this user was getting something for nothing !

Was running 3.12 shortly after it came out. Now running 3.13. Have not seen the issue YET. Its too soon to be sure though. Why not try it?

Matt

For us is pretty difficult to upgrade a pppoe server because we use some voip pppoe client that some time lockup when the pppoe server reboots.
So think about 1800..........calls during early morning...,,,,,,,

I will do it when i will be sure to fix this issse and not broke everything else.

regards
ros

any update from who is testing 3.13?

then please report also the platform, RB or x86.

Regards
Ros

We updated some MK routers (x86) to 3.13 where we have more problems with this bug. But we have to wait some days to see.

BAD NEWS!!!

We had the same problem today with version 3.13. User was using more than 4Mbits while he was limit to 1Mbit. As always queue was only displaying 1Mbit in use while at interface we can see more than 4Mbits in use.

SO THIS PROBLEM WAS NOT SOLVED!!!!!!!

Can anyone confirm this?

Can anyone confirm this?

Yes,
RouterOS 3.13v + x86 not solved , the problem still lives .... unfortunately

Can anyone confirm this?

Yes,
RouterOS 3.13v + x86 not solved , the problem still lives .... unfortunately

very disappointed!!!!

we fight each day with invalid queue. They are the oldest but very annoing to catch.

it is still a great bug MT MUST FIX ASAP.

Regards
Ros

Hi all, just to add - 3.13 also x86 (WRAP) does seem to still have the queue issue, We are seeing something strange, Winbox will report some PPPoE clients moving 20Mbit/s, but that sort of speed is impossible at some of our towers, as some are only fed 5Mbit.

We are rolling back to an earlier version

Ops, maybe we are being misled to believe the clients are using the extra bandwidth without actually using it?

Hi all, just to add - 3.13 also x86 (WRAP) does seem to still have the queue issue, We are seeing something strange, Winbox will report some PPPoE clients moving 20Mbit/s, but that sort of speed is impossible at some of our towers, as some are only fed 5Mbit.

We are rolling back to an earlier version

This is not what is happening to us. The traffic we saw on PPPoE interface was the real one in use (we could see it at radio interface used for MK backhaul). When it was displaying 4Mbits on interface he was really using it (but this traffic was not displayed in queue).

Ops, maybe we are being misled to believe the clients are using the extra bandwidth without actually using it?

No, they are really using it. We can see the over traffic at all equipments (switchs, routers, radios, etc).

We usually see the traffic on the PPPoE interface but there queue displays zero for traffic. And the client is really getting that bandwidth. Kind of pain when user paying for 256k lite account pulls movies off bittorrent at 6mbps all weekend.

Matt

we too see zero bandwidth on queue and realspeed on the pppoe interface.
pushing to reauthenticating the customer fix the issue.

So during the day we are going to be the queue cop!!!! very annoing.

Ros

A very quick script to schedule every hour Where n (0, 1, 2 etc) is the column number of your PPPoE server list by issuing at the terminal : This will cycle all PPPoE clients on n interface. When they reconnect a new queue is created that works for a while MT CPE will usually reconnect seamlessly meaning an outage of around 12 seconds

anyone who can give full remote access to your router (with missing queue problem - where queue is shown, but not working for the specific customer), please contact support and we will look !

A very quick script to schedule every hour

Code: Select all

{ /interface pppoe-server
 server disable "0"
 :delay 8s
 server enable "0"
 :delay 8s
 server disable "1"
 :delay 8s
 server enable "1"
 :log info "Cycle PPPoE Servers"
}

Where n (0, 1, 2 etc) is the column number of your PPPoE server list by issuing at the terminal :

Code: Select all

/interface pppoe-server server print

This will cycle all PPPoE clients on n interface. When they reconnect a new queue is created that works for a while MT CPE will usually reconnect seamlessly meaning an outage of around 12 seconds

But this script will stop the user connection? If it break a download or a TCP session is useless for us (our users already claim a lot when we need to reboot MK for maintenance).

the best way is to contact MT to give them the access to the pppoe server to install the debug package.

I at the moment could not give this possibility so any help from the community is welcomen.

regards
Ros

anyone who can give full remote access to your router (with missing queue problem - where queue is shown, but not working for the specific customer), please contact support and we will look !

Please, if someone could do this it would be of great help!

A very quick script to schedule every hour

Code: Select all

{ /interface pppoe-server
 server disable "0"
 :delay 8s
 server enable "0"
 :delay 8s
 server disable "1"
 :delay 8s
 server enable "1"
 :log info "Cycle PPPoE Servers"
}

Where n (0, 1, 2 etc) is the column number of your PPPoE server list by issuing at the terminal :

Code: Select all

/interface pppoe-server server print

This will cycle all PPPoE clients on n interface. When they reconnect a new queue is created that works for a while MT CPE will usually reconnect seamlessly meaning an outage of around 12 seconds

This is not a very viable solution... Think of the overhead with the amount of calls to the RADIUS and MySQL servers for authentication.. Although it will fix the queue problem, it will also piss off a lot of customers.

anyone who can give full remote access to your router (with missing queue problem - where queue is shown, but not working for the specific customer), please contact support and we will look !

Normis,

Does it have to be the latest ROS release 3.13? I have three they can look at all which are running 2.9.51.


-Bill

But this script will stop the user connection? If it break a download or a TCP session is useless for us (our users already claim a lot when we need to reboot MK for maintenance).

You could try setting the delay to 3 seconds in the hope that the MT CPE's will reconnect etc before 7 seconds (after 7 seconds packets are dropped at the CPE) if that is possible they wont notice it.

Today I saw a new error behavior for pppoe and queue (at least was the first time I saw it).

A user was using a lot more bandwidth than was limit with queue. He was using more than 4Mbits and it was congesting others users. So we forced him to disconnect and reconnect. But it didn´t solve the problem. After reconnect he starts to use overlimits. We disconnect him sereval times but didn´t work this time. So I opened torch to a look at his traffic and we found a UDP connection for port 80 (weird) using more than 4Mbits. I create a firewall rule (as the first rule) on MK firewall table to block all UDP traffic over port 80. Then this rule started to capture and drop it, but when I checked the rule statistic is was only maching part of this traffic, coincidentally the same amount displayed at queue statistics (but at pppoe interface statistic we could see a lot more, and this was the really one being used).

of course it has to be v3.13 - the one that has this problem!

Hi Normis,

every mt version since 2.9.x has this bug.

Regards
Ros

Hi Normis,

every mt version since 2.9.x has this bug.

Regards
Ros

we will not modify old versions. we can ONLY fix the latest one. there are already lots of changes in the pppoe and queue programs

So, you will not attempt to correct pppoe missing queues in 2.9.51 ? If you know what is the problem, it will be very easy to make 2.9.52 with correction?

I think that here is a lot of mikrotik users, who uses 2.9.51 for pppoe and are stuck with queue missing problem like us. We use 2.9.51 and must restart pppoe server every 10 days when queue missing problem appears.

was someone able to give MT guys the access to the pppoe server?

regards
Ros

was someone able to give MT guys the access to the pppoe server?

regards
Ros

We are trying to do that.

many thanks josefranco.

Hope MT will reward you about this great help.

regards
Ros

many thanks josefranco.

Hope MT will reward you about this great help.

regards
Ros

I just hope they find the problem and fix it.

Hi josefranco,

may you update on the status of progress?
Still qaiting about the queue issue come up?

regards
Ros

Hi josefranco,

may you update on the status of progress?
Still qaiting about the queue issue come up?

regards
Ros

Nothing yet. They are unable to enter my Mk router (I created a port forward rule and it works for me outside my network but doesn´t work for them)

Were are seeing the issue on 3.13 yet as well. What makes it a real pain is a user gets like several meg upload for a few days but then later after connection goes up and down they are locked back at 512k upload. Then they call complaining the connection is not working right. Argh. Hopefully Mikrotik gets this fixed soon.

Matt

Were are seeing the issue on 3.13 yet as well. What makes it a real pain is a user gets like several meg upload for a few days but then later after connection goes up and down they are locked back at 512k upload. Then they call complaining the connection is not working right. Argh. Hopefully Mikrotik gets this fixed soon.

Matt

Can you please contact MikroTik support team and grant them access to your router so they can investigate what is going on? They prompted to help but we need someone with the problem.

Were are seeing the issue on 3.13 yet as well. What makes it a real pain is a user gets like several meg upload for a few days but then later after connection goes up and down they are locked back at 512k upload. Then they call complaining the connection is not working right. Argh. Hopefully Mikrotik gets this fixed soon.

Matt

Hi Matt, you only saw it happening for upload or already happened with download? Did you take a look at user traffic with torch for example to see what it was?

I´m asking this based on some observations I have done. There is at least one situation where the queue will not solve and there is nothing that can be done. This is when a huge upload traffic is generated using UDP protocol. If such kind of traffic is generated the queue will drop the traffic for outside (to internet) interface but the traffic can reach the internal interface of the router using entire nic or radio bandwidth, since UDP has no flow control. When this happens your internet link will not be flooded but your internal network (wired or wireless) will be, compromising other users.

I already saw this problem happening and if I can´t hardlimit user bandwidth before reaching MK router nothing can be done to solve it.

Of course this doesn´t explain when download is not limited, if upload traffic is TCP or if you can see the high traffic after queue in outside interface (I already had problems in both cases).

This is first time in a while I noticed it on upload. It was TCP traffic and not UDP so thats not the issue. We see it all the time on download traffic.

Matt

Hi josefranco,

may you update on the status of progress?
Still qaiting about the queue issue come up?

regards
Ros

Nothing yet. They are unable to enter my Mk router (I created a port forward rule and it works for me outside my network but doesn´t work for them)

I think happen because you have a multihome router behind a nat.
So their connection enter one side and exit other side.
So I think when you tri to enter, you are lucky becasue you connection enter and exit on the same internet connection.

So take a look into it.
So will be close to an end of this issue.

Or could HCI so kind to contact MT to give them access to the router?

regards
Ros

Or could HCI so kind to contact MT to give them access to the router?

I have not gotten a response from Mikrotik on the ticket I opened with them on this last week. Hopefully they got everything figured and 3.14 will solve this even so.

Matt

Hi Normis,
please may you check the HCI ticket?!?!!?!??!?!?!

it is strange asking support ro access a router with the issue and then not reply to such ticket!

Regards
Ros

Hi Normis,
please may you check the HCI ticket?!?!!?!??!?!?!

it is strange asking support ro access a router with the issue and then not reply to such ticket!

Regards
Ros

It will be great if they can give you MSN address, it will be easier.

HCI did not send us access. Support asked for access, and we didn't receive any response.

Sorry to hear that, seems that people are more into complaining than into helping...

Sorry to hear that, seems that people are more into complaining than into helping...

I don´t know about HCI but we are trying everything here to allow MK team to access our machine. We are even planning to change our MK to valid IP address just to allow it.

We have this problem every week, sometimes more than once per week. This monday he saw 3 users connected in the same MKT router consuming much more than queue download limit (as always queues shows zero usage for download when each one was using more than 2Mbits).

we got access to hci router too now

we got access to hci router too now

Good news Normis..

Gotta wait tell off peak to reboot and install test package. Then I imagine it will be a while before it acts up. Will let Mikrotik know when its in.

Matt

any update on this issue?

regards
ros

The diagnostic package Mikrotik gave me had been installed in the router this weekend. Problem is our DS3 circuit that ties us to Internet at this location went down this morning. The new DS3 was supposed to be SO much more reliable then the old T1's. The LEC has been here working on it for hours. We had a massive amount of lightning here as well.

I will email Mikrotik when they can get in.

Matt

Hi hci,

did the lec repair the damaged circuit?
Is everything back to normal?

hope so.

Regards
Ros

20 hours after it went down they got it fixed. Was not a happy camper. Argh.

Shortly after it came back up Tuesday I emailed Mikrotik. They have access. Will email them the moment I see it act up as well.

Matt

when I see the problem we have also another problem:
- little packet loss or increased jitter (for all the pppoe client) at the moment a new pppoe itnerface is added.

This bug seems fixed in an earlier version but it seems to be present again when an user is able to go over the wueue limit.

regards
Ros

* BUMP *

Hi, any news here?

Mikrotik has access to my router and has special option package installed. Its acting up as I type this and I notified them by email yesterday that it was acting up. So, its wait and see what they say. Have not heard back yet, but its monday too.

Matt

Hi HCI,

did you see some packet loss (on the others) during an addition of a pppoe client interface apart of the missing queue?
It is araisng when i have more then 900 pppoe clients with some of them are missing the queue.

regards
Ros

did you see some packet loss (on the others) during an addition of a pppoe client interface apart of the missing queue? It is araisng when i have more then 900 pppoe clients with some of them are missing the queue.

We have our PPPoE users split between two geographically seperate PPPoE access servers and neither at this time sees over 650 active connections at a given moment. Many users have single PC and/or connect on demand. I have not noticed any packet loss issues but thats not saying there are none. Perhaps you should have given Mikrotik access to your router?

Matt

any comment from Normis????

thanks
Ros

thanks to hci, we have solved this issue. we will continue working with volunteers to make sure it fixes it for good.

Wow! This is a huge accomplishment!

Congratulations MT guys, hci for the teamwork!

Normis, do you have any idea of when this fix will be rolled out?

depends on the results from people who test it

Is there anyway to help?

maybe. contact support if you have a large pppoe server with this issue

The router that Mikrotik worked on this morning has been rebooted to affect there changes. Typically after a reboot it takes a week or more for the issue to show back up or at least be noticeable. Perhaps Normis knows more on why it works that way. They seem pretty confident they found the issue though. Its really a wait and see to be sure.

Thanks Normis.

Matt

is it a test package about 3.13 or based on 3.14 rc1?

regards
Ros

is it a test package about 3.13 or based on 3.14 rc1?

regards
Ros

latest unreleased build I think

Hi Normis,

may you confirm that the fix is into the final 3.14?
In fact into the change log I don't see anything about pppoe.

regards
Ros

Hi Normis,

may you confirm that the fix is into the final 3.14?
In fact into the change log I don't see anything about pppoe.

regards
Ros

we are still testing if the fix works

Hi normis,

I am waiting a fix for a long time. I have 5 pppoe servers and all with this issue. I found a way to work around this problem without restarting the machine. If you have a static simple/tree like p2p control only you need is disable and enable this queues and the pppoe queues will work good.

Friends, try this and post if it works!

Posted accidently. Deleted.

Matt

Well - another bug found, thanks to HCI.

We were pretty lucky actually by finding and fixing this bug:

every 32768th simple queue or 65536th queue tree have no effective limitations.


In HCI's situation it took ~2days until 32768th queue was created, but if clients don't use traffic it is impossible to capture. But luckuly we managed it.

Well - another bug found, thanks to HCI.

We were pretty lucky actually by finding and fixing this bug:

every 32768th simple queue or 65536th queue tree have no effective limitations.


In HCI's situation it took ~2days until 32768th queue was created, but if clients don't use traffic it is impossible to capture. But luckuly we managed it.

Excellent news!!! signed and unsigned int variable sizes.. Do you know in which version this fix will be included?

it will be included into 3.15

regards
Ros

wow, good find!

I found a way to work around this problem without restarting the machine. If you have a static simple/tree like p2p control only you need is disable and enable this queues and the pppoe queues will work good.

Friends, try this and post if it works!

Yes this works!!!

Can you tell me if this works all the time after you disable/enable static queues or it works for period like when you restart machine?

it will be included into 3.15

What about 2.9.52 ?

What about 2.9.52 ?

I dont think there will be any backports to 2.x series anymore because the versions are too different.

I dont think there will be any backports to 2.x series anymore because the versions are too different.

But, bug is the same.

But, bug is the same.

But it will be fixed in later version, in 3.15 =)

I dont think there will be any backports to 2.x series anymore because the versions are too different.

But, bug is the same.

The problem is that, fixing bugs in two releases, duplicates the work and defeats the purpose of releasing a new version. It's true that the release system of MikroTik could be a little more sophisticated and I think they should estabilish official end of life dates to each release overlapping with new major releases and be clear about what fixes would be supported and for how long but, for now, that's the way it is...

so where's 3.15?

impatiently waiting...

I am using 2.9.50, in 2.9.50 i didnt see that problem at all.
may be i didnt see

I am using 2.9.50, in 2.9.50 i didnt see that problem at all.
may be i didnt see

You do not have enough traffic to reach 32768th simple queue.

I imagine HCI is running a fixed beta version for this problem.

Maybe he could give us a feedback if this problem was solved (or if he is still waiting for 3.15 like us).

Got to 8 days of uptime on it without it acting up. Unfortunately do to some power outages lately thats all the uptime I have on it. Twice now when we cut from UPS to generator we have had reboot issue. Time to revamp our backup system.

Anyway, usually it acted up at 5-7 days of uptime for me. I think they have it fixed. But until I have like 30 days of uptime with no issues I am not sure. Perhaps if they tested on some more heavy loaded PPPoE access servers we would know more.

Matt

I'd love to test on ours.. I have 3 PPPoE servers with 300+ users on each all with reliable power..

Had a user using 10+mbps the other day.. really was killing one of our high priority links.. luckily it happened while I was monitoring the network..

I'd love to test on ours.. I have 3 PPPoE servers with 300+ users on each all with reliable power..

Email Mikrotik and offer them access to your router to do this.

Matt

Just did.

may MT confirm the HCI fix is inside the 3.15?

I don't see it into the change log.

regards
Ros

may MT confirm the HCI fix is inside the 3.15?

I don't see it into the change log.

regards
Ros

Here we go again...

...and out of the window goes the idea of a release candidate in a feature changing release...

...good luck to us all!

may MT confirm the HCI fix is inside the 3.15?

I don't see it into the change log.

regards
Ros

I really don´t understand why they do that.

We really need this information MK guys!

hi Normis,
why you are not responding to latest question?

is it the fix inside the 3.15?????
please i need a confirmation ASAP.

regrads
Ros

I now have over 10 days of uptime on my 3.13 release patched by Mikrotik and its still not acting up. Looks like they may have gotten it fixed. No idea if the fix is in 3.15 though.

Matt

I have upgraded to 3.15 and I am running it for about a week, and I don't see this problem, I have about 50 Users. I monitor interfaces and users get the speed that they have in PPPoE profiles.

I have upgraded to 3.15 and I am running it for about a week, and I don't see this problem, I have about 50 Users. I monitor interfaces and users get the speed that they have in PPPoE profiles.

what hardware are you running?

regards
Ros

I have PC Router with this hardware configuration:
Fujitsu Siemens with Intel P4 2.0GHz procesor
512 MB RAM

And now Winbox does not freeze like before, now most of the time it does not freeze to me, sometimes yes.

Have 17+ days of uptime on 3.13 with fixes from Mikrotik and no PPPoE queues are acting up. Did anyone find out if 3.15 has these fixes in it?

Matt

Have 17+ days of uptime on 3.13 with fixes from Mikrotik and no PPPoE queues are acting up. Did anyone find out if 3.15 has these fixes in it?

Matt

No response from MK team.