RADIUS Rate-Limit Builder
Build the Mikrotik-Rate-Limit attribute string correctly - rates, burst, threshold, burst time, priority and limit-at - and see exactly how RouterOS will interpret each field.
Result
subscriber01 Cleartext-Password := "change-me"
Mikrotik-Rate-Limit = "20000k/100000k 30000k/150000k 15000k/75000k 8/8 8",
Service-Type = Framed-User,
Framed-Protocol = PPP,
Acct-Interim-Interval = 300INSERT INTO radreply (username, attribute, op, value)
VALUES ('subscriber01', 'Mikrotik-Rate-Limit', ':=', '20000k/100000k 30000k/150000k 15000k/75000k 8/8 8');/queue simple
add name="subscriber01" target=0.0.0.0/0 max-limit=20000k/100000k burst-limit=30000k/150000k burst-threshold=15000k/75000k burst-time=8s/8s priority=8/8How RouterOS parses this
- Field order
- rx-rate/tx-rate [burst-rate] [burst-threshold] [burst-time] [priority] [limit-at]
- rx (first value)
- traffic the router receives = subscriber upload
- tx (second value)
- traffic the router transmits = subscriber download
- Priority
- 8 (1 is served first, 8 is default)
- Burst threshold
- 75% of committed rate - burst re-arms below this average
About RADIUS Rate-Limit Builder
MikroTik NAS equipment takes subscriber speed from the Mikrotik-Rate-Limit vendor-specific attribute (vendor 14988, attribute 8). It is a single positional string, and every field after the first is optional - which is exactly why it is so easy to get subtly wrong.
The field order
rx-rate/tx-rate rx-burst/tx-burst rx-threshold/tx-threshold rx-burst-time/tx-burst-time priority rx-limit-at/tx-limit-at. Fields are positional, so to set priority you must supply placeholder 0/0 values for burst fields you do not use. Rates accept k and M suffixes; bare numbers are bits per second, which is a fast way to accidentally provision a 100 bit/s service.
How burst actually behaves
RouterOS tracks the average rate over the burst-time window. While that average stays below the burst threshold, the subscriber is allowed up to the burst rate; once the average exceeds the threshold, they drop back to the committed rate. Setting the threshold equal to the committed rate means burst never re-arms after the first use - a common misconfiguration that generates "it was fast on day one" tickets.
Common use cases
- Provisioning PPPoE or hotspot subscriber speeds from FreeRADIUS instead of per-queue configuration.
- Adding a marketing burst tier without touching the NAS.
- Changing a customer plan with a CoA rather than a disconnect.
- Migrating static simple queues into RADIUS-driven policy.
Edge cases and gotchas
- rx is the subscriber upload and tx is the download - from the router's perspective, not the customer's.
- Priority only affects traffic competing inside the same parent queue; it does nothing on an uncongested link.
- RouterOS applies the attribute at session start. Changing it in the database has no effect until reconnect or a CoA.