Rate Limiting Recommendation

We are beginning to use sonar for provisioning. We are using radius with Mikrotik

We are using pppoe to authenticate customer routers to our network.

The question I have is regarding Ratelimiting.

It is very simple to setup rate limiting through radius so it adds a simple queue to the pppoe connection.

The difficulty that we have is that we have the desire to make changes to customer ratelimiting automatically. Meaning we will have certain things trigger service changes which will change customers speed service based on some schedule or timeline.

Main use of this is speed trails. Second use is schedule speed changes. For example a customer says they want to increase speed at the end of the month. So we schedule it to happen automatically at that time.

Changing the service is the easy part. The hard part is that when you use pppoe+mikrotik+radius it requires a reset of the pppoe connection in the mikrotik to change the simple queue rate limiting. This function (sadly) is not automated in sonar. So if we have a scheduled service change in sonar, it would require a manual restart of the pppoe connection to establish new ratelimit properties.

The address lists function seams to correct this issue by being an active list that doesn’t require a reset of the pppoe connection to make changes to the speed.

My main question is whether this is less or more efficient in regards to hardware resources on the mikrotik and whether it is the recommended means of ratelimiting.

You’ll want to investigate CoA with radius (under Radius Server,) which Sonar supports. Any changes in customer’s status will automatically change their PPPoE session so you don’t have to bump it manually.

So a change is status will send a CoA command? What about a change in a service?

There are three checkboxes in Sonar:

  • Send disconnect on delinquency change
  • Send disconnect if active attribute on service changes
  • Send disconnect on data service change

If the third one is checked then a change in a service will result in a CoA.

I prefer to rate limit PPPoE with simple queues controlled by RADIUS instead of an address list. The downside of the address list is that you have to use PCQ which is like a large number of individual FIFO queues. This leads to taildrop and bufferbloat. The customer will experience better latency and performance overall using individual simple queues because you can use RED as the queue type, which helps to avoid bufferbloat.