Hi! For load balancing it would be nice to have a “delay” parameter in settings of PPPoE servers.
It would delay PADO packet for specified number of milliseconds or microseconds.
In fact, without this setting I cannot really test CCR in PPPoE BRAS configuration, because it cannot compete with i5 PC in terms of delay. Users plainly don’t donnect to CCR because i5 PC replies faster. And I don’t want to disable PPPoE server on PC box, because it is a production system and in case of problems with CCR there should be a fallback.
What I’ve done in a similar circumstance is just set a limit on the x86 PPPoE servers connections, ie:
/interface pppoe-server server set 0 max-sessions=100This means your i5 will end up taking X connections maximum then the reset will fall over to the CCR.
That said I’ve had excellent performance on v6.0rc8 just using it for PPPoE.
Where 192.168.1.1 is the address of the CCR you’re monitoring.
/tool netwatch
add down-script=“/interface pppoe-server server set 0 max-sessions=\r
\n:log info "Uncapped limit of PPPoE sessions"” host=192.168.1.1 timeout=5s up-script=“/inte
rface pppoe-server server set 0 max-sessions=100\r
\n:log info "Capped limit of PPPoE sessions"”
BTW, it looks like CCR-1036 cannot properly handle more than 300 pppoe users and 300 Mb/s of traffic in my configuration. I use pcq for user rate limit. Here are ether1 and cpu graphs from the last day, people complained about too low speed.
Have you modified your queue tree to work with the new global queue system?
Also, it looks like double QoS will still be possible; I read a post from Normis the other day stating they will be moving simple queues to be actioned after the queue tree in the packet flow diagrams so that there is 2 clear points where rate limiting can be performed.
If you haven’t already I would recommend you report back any oddities you’ve noticed so they can get them fixed asap!
