RADIUS at 100K concurrent sessions: a scaling study for FTTH ISPs

RADIUS (RFC 2865, RFC 2866) is one of the most durable protocols in operational networking. It also has surprisingly little written about running it at real scale on an FTTH network. This is a scaling study — what breaks, at what volume, and what to do about it.

The primary references are still the RFCs: [RFC 2865](https://www.rfc-editor.org/rfc/rfc2865.html) (RADIUS authentication), [RFC 2866](https://www.rfc-editor.org/rfc/rfc2866.html) (accounting), [RFC 3576](https://www.rfc-editor.org/rfc/rfc3576.html) (Change-of-Authorization) and [RFC 5176](https://www.rfc-editor.org/rfc/rfc5176.html) (the modern CoA update). For PPPoE alongside RADIUS, [RFC 2516](https://www.rfc-editor.org/rfc/rfc2516.html) is the base.

What "100K sessions" actually looks like

An FTTH ISP with 100K subscribers running PPPoE typically sees: 100K concurrent sessions steady-state, ~15K auth requests per hour at the daily peak (churn + rejoin from CPE reboots), ~30K accounting-interim updates per hour (with default 15-minute intervals), and up to 20K CoA operations per hour during a plan-change campaign.

Where FreeRADIUS holds up

FreeRADIUS is a beautifully engineered piece of software. On modern hardware it will handle 15K auth/hr without breathing hard. The limiting factor is almost never the RADIUS process itself; it is the backing store. FreeRADIUS with MySQL/PostgreSQL as the check/reply store scales well until the DB row-lock contention on the accounting-interim table catches up around 60K–80K concurrent sessions.

The workaround is well-known: partition the accounting table by month, aggressively expire old rows, and place accounting on a separate DB from auth. Operators running FreeRADIUS at 100K+ know this pattern. See our comparison of [Netxol RADIUS vs FreeRADIUS + daloRADIUS](/blog/netxol-radius-vs-freeradius) for the operational trade-offs.

Where the Netxol approach differs

Netxol RADIUS runs on the same graph as CRM, Billing and NMM. That means a plan change in CRM triggers a CoA to the correct BNG/OLT automatically; a non-payment in Billing triggers a session termination; a session accounting stop links to a subscriber's usage history. The DB partitioning story still applies — but the accounting store is a first-class part of the graph, not a foreign key across two products.

The five specific things to plan for at 100K sessions

1. 1Certificate rotation for EAP-TLS. Plan the rotation cadence and the migration procedure before you turn it on, not after.
2. 2CoA reliability. RADIUS CoA is UDP; not every OLT/BNG implements it robustly. Test failure recovery in a lab against the specific hardware.
3. 3Accounting interim intervals. Shorter intervals give better usage data and higher DB load. 15 minutes is the industry default; go shorter with intent, not by accident.
4. 4CoA + suspend/restore. If you use RADIUS to enforce billing suspension, benchmark the end-to-end suspend and restore latency. Subscribers notice > 30 second delays.
5. 5DHCP Option 82 vs. PPPoE identity. If you run mixed IPoE + PPPoE, make sure the identity plane is consistent — the subscriber master should not depend on the access mode.

The unglamorous winning move

The single most valuable operational improvement at 100K sessions is not a new protocol — it is instrumentation. Track auth rate, auth latency percentiles, accounting-interim throughput and CoA success rate. Alarm on the derivatives, not the absolutes. When one metric starts drifting, you have hours or days to react before subscribers notice; without instrumentation you have minutes.