RADIUS Is Your ISP Control Plane, Not Just a Password Checker

Begin with the decision RADIUS is making

A broadband session starts with a small but consequential decision: should this identity be allowed onto the network, and under which limits? RADIUS gives that decision one place to live. The access router still terminates PPPoE, Hotspot or another access method, but it asks a policy service for the subscriber-specific answer.

Thinking of RADIUS as a remote password database leads to fragile deployments. A useful design treats it as a control plane with three separate responsibilities: establish identity, return an enforceable service policy, and preserve a trustworthy record of the session.

Follow one access request end to end

Consider a subscriber router initiating PPPoE. The MikroTik acts as the network access server (NAS). It packages the username, a protected representation of the password, its own identity and information about the access port into an Access-Request. The RADIUS server evaluates that request and returns either an Access-Accept, Access-Reject or Access-Challenge.

1. The CPE initiates a session. The NAS learns the submitted identity and the physical or logical access context.
2. The NAS sends an Access-Request. Its NAS-Identifier and NAS-IP-Address should identify exactly one managed router.
3. RADIUS resolves policy. Credential checks, account state, package state and any time-based rules are evaluated in a predictable order.
4. The NAS receives its instructions. Rate limit, pool, address and timeout attributes become part of the live session.
5. Accounting starts. Start and interim records create the operational timeline used for session visibility and usage reconciliation.

Keep policy data small and deterministic

The most reliable policy model has one clear source for each decision. Subscriber state should not be contradicted by a second hidden rule on the router. Package speed should not exist in three slightly different formats. Router identity should not depend on an IP address that changes during a VPN migration.

A minimal service decision can be described with the following data. The exact database schema is less important than the ownership of each value.

Configure RouterOS with an explicit scope

Do not enable RADIUS globally and assume every service is covered. Add the server, select the intended service, set a realistic timeout for the network path, and make the source address predictable when routing permits it.

/radius
add address=10.20.0.10 service=ppp secret="replace-with-a-long-unique-secret" 
    authentication-port=1812 accounting-port=1813 timeout=1500ms

/ppp aaa
set use-radius=yes accounting=yes interim-update=5m

The shared secret belongs to the relationship between one NAS and the RADIUS service; it is not a universal platform password. Use a different secret per router, store it outside tickets and chat, and rotate it with a planned overlap where your RADIUS implementation permits that workflow.

Test accounting as a state machine

A session table is useful only when its state transitions can be trusted. Test a normal login and logout first. Then test the awkward cases: a CPE loses power, the access router reboots, the RADIUS service restarts, the VPN path flaps, and the same username attempts a second session.

• Start: creates one identifiable session with a stable accounting session ID.
• Interim update: advances time and octet counters without creating a duplicate session.
• Stop: closes the matching session and records a useful termination cause.
• Stale-session handling: reconciles sessions that cannot produce a clean Stop because a device or path failed.

Counter rollover and vendor attributes deserve explicit tests. If your platform uses 32-bit octet fields, gigaword attributes are required to represent usage beyond the counter boundary. If you rely on a vendor rate-limit attribute, confirm the exact syntax against the RouterOS version in production rather than copying a value from an unrelated deployment.

Design for a failure you can explain

Redundancy is not simply adding a second IP address. Both RADIUS nodes need consistent subscriber policy, synchronized time, distinct health monitoring and logs that let an operator reconstruct which node answered. The NAS timeout and retry behaviour must also be shorter than the period users will tolerate during login.

A dashboard that reports only “RADIUS service up” misses the failure modes that hurt an ISP. A process may accept UDP while database queries are slow. Authentication may work while accounting writes fail. Interim updates may arrive while the billing platform can no longer associate them with customers.

An operator-ready acceptance checklist

• Every NAS has a unique identity and secret.
• Access requests from unknown NAS addresses are rejected and logged.
• One subscriber test confirms the expected package and address policy.
• Start, interim and Stop records are visible against the same session.
• Router and RADIUS clocks use reliable NTP sources.
• A simulated RADIUS-node failure produces a measured, documented outcome.
• Logs contain enough context to move from username to NAS, session ID and subscriber record.

Primary references: IETF RFC 2865 (Remote Authentication Dial In User Service), IETF RFC 2866 (RADIUS Accounting), and the current MikroTik RouterOS RADIUS manual. Configuration examples should be validated against the RouterOS release and access method used by your network.