It is complete
Every authentication method, every dictionary, every vendor attribute you will meet on a MikroTik, a Cisco or a Huawei. Nothing we wrote comes close to that surface.
FreeRADIUS and the RADIUS we wrote
We ran FreeRADIUS, then replaced it
Not because it is bad. Because we outgrew one part of it. FreeRADIUS answers our routers today on the box we kept it installed on, as the rollback. This page is what we measured before we moved off it, what we wrote instead, and the part most operators are actually missing, which is not the RADIUS server.
What FreeRADIUS gets right
It is the most widely deployed RADIUS server in the world, it is free, and for most networks it is the correct answer. Three reasons we ran it for years.
It is proven
Two decades of carriers, universities and ISPs finding the edge cases first. An unfamiliar RADIUS problem almost always has an answer already written down.
It is free
No licence, no subscriber count, no vendor. If you have someone who can read a virtual server config, it costs you server time and nothing else.
Where we hit a wall
At roughly 700 requests a second across one hub, profiling found cost that grew with our own tuning rather than with traffic. Two paths are upstream code; one was our environment.
Releasing a database connection
Every release walks the whole connection list under the pool’s single mutex. The source carries a FIXME saying so. It cost 6 to 7 per cent of process CPU, and the cost grows with pool size, so the larger the pool we set to survive bursts, the more each request paid.
Reaping children that do not exist
Before every request the server takes a global lock and calls waitpid, and the kernel walks every thread in the process. Another 5 to 6 per cent, growing with thread count. Nothing forks any more, so the work is not needed. Both paths are still in 3.2.10, so upgrading does not help.
The certificate bundle: our fault, not theirs
Each new database connection parsed a 121-certificate CA bundle under an OpenSSL global lock, and at one point 57 per cent of CPU was threads queueing on it. Pointing at a two-root file cut CPU per request from 1.94 ms to 0.44 ms. Worth checking on any FreeRADIUS talking TLS to a managed database.
What we wrote instead
About 1,100 lines of Go that port our two virtual servers one for one: the same SQL, the same replies, a goroutine per packet. It is not a general-purpose RADIUS server and it is not trying to be.
One job, done narrowly
PPPoE and hotspot authentication and accounting against our own schema. No EAP, no proxying, no dictionaries we do not use. That narrowness is the whole reason it is small enough to reason about.
New routers without a restart
The NAS table is re-read every minute, so a router added in the panel is answered a minute later. FreeRADIUS reads its client list at startup, which meant a restart, and a restart at a busy hour brings a retransmit storm.
Rollback kept
FreeRADIUS is still installed and one command away. We did not delete the thing that worked, and neither should you.
What changed, measured
Figures from our own hub on cutover day and from load tests against side copies on the same box. Your network is not ours; these are what we saw, not a promise.
Database connections held
65
Against roughly 400 before, for the same traffic.
Memory resident
28 MiB
One process, serving both authentication and accounting.
Mean authentication time
3 ms
Steady state. First ten minutes after cutover: 279,000 authentications, zero failed writes.
The part that is not RADIUS
Here is the honest answer for most people who arrive on this page: your RADIUS server is probably fine. The gap is everything that happens around it.
- 01
RADIUS says yes or no
It answers the router with a subscriber’s state. That is the whole job, and FreeRADIUS does it well.
- 02
Something has to set that state
A package, a price, a billing date and an expiry. FreeRADIUS reads a database; it does not decide what should be in it.
- 03
Someone has to collect the money
M-PESA, MTN MoMo, Airtel Money, a card, a bank transfer. This is the part operators tell us eats a day a week.
- 04
And match it to a subscriber
Reconciliation is the work free hides. A payment that arrives but is never matched leaves a paying customer disconnected.
- 05
Then the state changes back
The reconnection has to happen on its own, every time, without anyone opening Winbox at eleven at night.
Where to go next
The pages that carry this further, from the billing model to what it costs.
Common questions
Probably not. If it authenticates your subscribers and you are not fighting it, leave it alone. We replaced ours because profiling showed per-request cost growing with our thread count and pool size rather than with traffic, at a scale most single-ISP deployments never reach. Replacing a working RADIUS server is rarely where the return is.
No. It is a narrow internal server that speaks to our own schema, not a general-purpose RADIUS you could drop into another network. FreeRADIUS is the right choice if you want a server of your own.
No. Centipid answers your MikroTik routers directly, so there is no RADIUS server for you to install, tune or keep patched. If you already run FreeRADIUS you can keep it and use Centipid for billing alone.
Yes. The two jobs are separable: FreeRADIUS answers the router, Centipid holds subscribers, invoices, payments and reconciliation. Most operators who arrive from a FreeRADIUS setup are missing the billing half, not the authentication half.
3% of hotspot revenue or $0.25 per active PPPoE subscriber each month, after fourteen days free with no card required. Run both and the two fees add up on one invoice.
Keep your RADIUS. Fix the billing.. Free for fourteen days.
Fourteen days, no card, and a reconnection loop you can watch run on your own routers.