How RADIUS works for ISPs

What RADIUS is and why ISPs use it

RADIUS (Remote Authentication Dial In User Service) is a network protocol that lets ISPs verify subscriber identities, assign connection policies, and record usage data — all from a central server instead of configuring each router individually. DataRadius is ISP billing and management software that acts as a RADIUS server, translating plan rules into the authentication and authorization attributes routers enforce.

The protocol was originally designed in 1991 for dial-up internet access, and RFC 2865 formalized it in 2000. Despite its age, the core design — a client-server model where network equipment asks a central server what to do with each connection attempt — maps directly to how modern ISPs operate. Every major router vendor supports the protocol, making it the standard interface between "who is allowed to connect" and "the box that enforces the rules."

Without RADIUS, an ISP managing 500 subscribers across 10 routers would need to maintain 500 user records on each router, update speed limits on each router when a plan changes, and manually disable accounts on each router when a subscriber stops paying. With RADIUS, subscriber records live in one database. Every router asks that database what to do. Change a subscriber's plan once, and every router enforces the new rules on the next connection.

RADIUS operates on a simple request-response model over UDP. The router (called a NAS, or Network Access Server) sends a request to the RADIUS server. The server processes it and sends back a response. Three types of exchanges cover the full subscriber lifecycle: authentication, authorization, and accounting — collectively known as the AAA model.

The AAA model: three jobs, one protocol

The AAA model divides subscriber access control into three distinct responsibilities: Authentication asks "who are you?", Authorization asks "what are you allowed to do?", and Accounting asks "what did you do?"

These three functions are logically separate but often happen in the same exchange. When a subscriber connects and their router sends an Access-Request to RADIUS, the server performs authentication (checking credentials) and authorization (deciding what attributes to assign) in a single round trip. Accounting happens separately, in its own set of packets throughout the session.

Authentication — verifying identity

Authentication determines whether a subscriber is who they claim to be. The subscriber provides credentials — typically a username and password — and the RADIUS server checks them against its database.

For PPPoE connections, the subscriber's router or CPE sends credentials during the PPP negotiation phase. The ISP's router receives these credentials and forwards them to the RADIUS server in an Access-Request packet. For hotspot connections, the subscriber enters credentials on a captive portal page, and the router forwards them the same way.

RADIUS supports several authentication methods:

• PAP (Password Authentication Protocol) sends the password encrypted with the shared secret. Simple but adequate when the link between router and RADIUS server is secured.
• CHAP (Challenge Handshake Authentication Protocol) uses a challenge-response mechanism so the password never crosses the network, even encrypted. More common in PPPoE deployments.
• MS-CHAPv2 is Microsoft's extension of CHAP, used in some enterprise and hotspot configurations.
• EAP (Extensible Authentication Protocol) wraps various authentication methods inside RADIUS, used in 802.1X deployments.

The RADIUS server receives the Access-Request, looks up the subscriber, verifies the credentials, and checks whether the account is active. If everything passes, it sends an Access-Accept. If any check fails — wrong password, expired account, suspended for non-payment — it sends an Access-Reject.

Authorization — assigning policies

Authorization defines what a subscriber is allowed to do once authenticated, and it happens inside the same Access-Accept response that grants access.

The RADIUS server includes attributes in the Access-Accept packet that tell the router how to configure the subscriber's session. These attributes are key-value pairs defined by RFCs and vendor extensions. The router reads them and applies the corresponding policies.

Common authorization attributes for ISPs include:

• Speed limits — upload and download rates, typically sent as MikroTik-Rate-Limit or through standard bandwidth attributes. A subscriber on a 10 Mbps plan gets 10M/10M as their rate limit.
• IP address assignment — a static IP for the subscriber or the name of an address pool to assign from. Sent as Framed-IP-Address or Framed-Pool.
• Session timeout — maximum duration of the session in seconds. When it expires, the router disconnects the subscriber. Used for prepaid plans with time limits.
• Idle timeout — how long the session can be idle before the router drops it. Prevents abandoned sessions from consuming resources.
• Data limits — maximum bytes the subscriber can transfer. Vendor-specific attributes carry upload and download byte counters.
• DNS servers — which DNS resolvers the subscriber's connection should use.

The router treats these attributes as instructions. It does not question them or apply its own logic — it enforces exactly what the RADIUS server sends. This is what makes RADIUS powerful for ISPs: the billing platform decides the policy, and the router enforces it.

Accounting — recording usage

Accounting tracks what subscribers actually do during their sessions, and it is essential for billing, capacity planning, and troubleshooting.

Accounting uses its own packet types, defined in RFC 2866, sent from the router to the RADIUS server on UDP port 1813 (separate from the authentication port 1812). There are three types of accounting packets:

• Accounting-Start — sent when a session begins. Contains the subscriber's username, NAS identifier, session ID, IP address, and timestamp. This tells the billing platform that the subscriber is now online.
• Interim-Update — sent at regular intervals during the session (typically every 5 to 10 minutes). Contains cumulative counters: total bytes in, total bytes out, total session time. These updates let the billing platform track consumption in near-real-time rather than waiting for the session to end.
• Accounting-Stop — sent when a session ends, whether the subscriber disconnected, the session timed out, or the router terminated it. Contains final counters for the entire session: total bytes transferred, total time online, and the reason for disconnection (Acct-Terminate-Cause).

For an ISP, accounting data serves multiple purposes:

1. Billing accuracy. If a subscriber is on a plan with a 50 GB data cap, interim-update packets let the billing platform track consumption and trigger a disconnect or speed reduction when the cap is reached.
2. Usage reports. Subscribers can see how much data they have used this billing cycle. Operators can see consumption trends across their network.
3. Capacity planning. Aggregate accounting data shows peak usage times, heavy users, and which access points or routers carry the most traffic.
4. Dispute resolution. When a subscriber questions a charge or claims they were not online, accounting records provide timestamped evidence of every session.

How a RADIUS exchange works step by step

A complete RADIUS exchange follows a predictable sequence: the subscriber's device initiates a connection, the router asks the RADIUS server for a decision, and the server responds with instructions.

Using a PPPoE connection as an example:

1. Connection setup. The subscriber's CPE establishes a PPPoE session with the router and negotiates PPP authentication (typically CHAP).
2. Access-Request. The router constructs a RADIUS packet containing the subscriber's username, hashed password, NAS IP address, port type, and the subscriber's MAC address (Calling-Station-Id). It sends this to the RADIUS server over UDP port 1812.
3. Server processing. The RADIUS server looks up the username, verifies the password hash, and checks account status (active, suspended, expired). This typically completes in under 10 milliseconds.
4. Access-Accept or Access-Reject. If all checks pass, the server returns an Access-Accept with authorization attributes (speed limit, IP address, session timeout). If any check fails, it returns an Access-Reject with an optional Reply-Message.
5. Session begins. The router completes PPP negotiation, assigns the IP address, and applies the rate limit. It sends an Accounting-Start packet to port 1813.
6. Interim-Updates. Every 5 minutes (or whatever interval the server specified), the router sends Interim-Update packets with cumulative byte and time counters.
7. Session end. When the subscriber disconnects, the router sends an Accounting-Stop with final counters and the termination cause.

The entire authentication exchange — steps 2 through 5 — happens in under one second. The subscriber does not notice the RADIUS round trip.

RADIUS attributes that matter for ISPs

RADIUS attributes are the building blocks of subscriber policy — numbered type-length-value (TLV) fields defined by RFCs, extended by vendors through Vendor-Specific Attributes (VSAs).

ISPs use a core set for day-to-day operations:

Mikrotik-Rate-Limit — the primary way to set bandwidth on MikroTik routers. The format is rx-rate/tx-rate, supporting values in kilobits (k), megabits (M), or gigabits (G). For example, 10M/10M assigns 10 Mbps upload and 10 Mbps download.

Framed-IP-Address / Framed-Pool — assigns a specific static IP or names an address pool on the router. Used to segregate subscriber ranges or give business subscribers a fixed address.

Session-Timeout — maximum session duration in seconds. When it expires, the router terminates the session. A 24-hour prepaid plan sets this to 86400. A monthly plan might omit it entirely and rely on billing-triggered disconnects instead.

Acct-Interim-Interval — how often (in seconds) the router sends interim accounting updates. Setting this to 300 (5 minutes) gives the billing platform data consumption updates every 5 minutes — frequent enough for near-real-time dashboards without overwhelming the server with packets.

Idle-Timeout — seconds of inactivity before the router disconnects the session. Prevents subscriber slots and IP addresses from being consumed by devices that are powered off but never formally disconnected.

Reply-Message — a text string sent in Access-Reject or Access-Accept. Some CPE devices display this to the subscriber. Useful for messages like "Plan expired" or "Account suspended."

Mikrotik-Address-List — adds the subscriber's IP to a named address list on the router. ISPs use this for firewall rules, traffic shaping groups, or marking subscribers by plan tier.

Dynamic authorization: CoA and Disconnect Messages

Standard RADIUS authentication is initiated by the router — the subscriber connects, and the router asks the RADIUS server what to do. But what happens when the billing platform needs to take action mid-session? That is where Dynamic Authorization, defined in RFC 5176, comes in.

CoA (Change of Authorization) and Disconnect Messages reverse the direction: the RADIUS server sends a packet to the router, telling it to update or terminate an active session.

Change of Authorization (CoA) pushes updated attributes to the router for an active session. Common uses:

• Speed change. A subscriber upgrades from a 5 Mbps plan to a 20 Mbps plan. The billing platform sends a CoA with the new Mikrotik-Rate-Limit value. The router applies the new speed limit immediately — no disconnection, no service interruption.
• FUP throttle. A subscriber on an "unlimited" plan hits their fair usage threshold. The billing platform sends a CoA reducing their speed from 20 Mbps to 2 Mbps for the remainder of the billing cycle.
• Address list change. Move a subscriber into a different traffic class mid-session for prioritization or deprioritization.

Disconnect Message (DM) terminates an active session immediately. Common uses:

• Plan expiry. A prepaid plan runs out of time or data. The billing platform sends a DM, and the router drops the PPPoE session.
• Non-payment. A postpaid subscriber's invoice is overdue. The billing platform sends a DM after the grace period.
• Administrative action. An operator suspends a subscriber for abuse. A DM terminates the session instantly.

Both CoA and DM packets include session identification attributes (Acct-Session-Id, User-Name, or NAS-Port) so the router knows which session to affect. The router acknowledges with a CoA-ACK/NAK or Disconnect-ACK/NAK.

For ISPs, dynamic authorization eliminates the most common manual tasks: changing speeds and disconnecting subscribers. Without it, the only way to change a subscriber's speed mid-session would be to disconnect them and wait for reconnection with new attributes — disruptive and slow.

Why ISPs need centralized RADIUS

Running subscriber access control without RADIUS means maintaining individual user records on every router. Centralized RADIUS solves problems that grow worse as an ISP scales.

Duplicate records. Without RADIUS, every router needs its own copy of the subscriber database. RADIUS eliminates this — one database, every router queries it.

Manual speed changes. When a subscriber upgrades, someone logs into the router and changes the rate limit. With RADIUS, the billing platform updates the record once, and the next connection (or an immediate CoA) applies the new speed.

Delayed disconnection. When a plan expires at 2 AM, someone needs to be available. RADIUS sends a Disconnect Message automatically at the exact moment of expiry.

No usage visibility. Without accounting records, the ISP cannot tell how much data each subscriber consumes or when peak hours occur. RADIUS accounting provides this data continuously.

Inconsistent policies. Manual configuration across routers leads to mismatches — one router has the old speed limit while another has the new one. RADIUS ensures every router receives the same attributes from the same source.

The value increases with scale. An ISP with 50 subscribers can manage without it. At 500, manual tasks consume hours daily. At 5,000, centralized AAA is a requirement.

Putting it together: RADIUS in a billing workflow

A billing platform that integrates with RADIUS turns subscriber management into a set of automated state transitions — no SSH sessions, no manual configuration, no spreadsheets.

The workflow for a typical postpaid ISP subscriber looks like this:

1. Subscriber signs up. The operator creates a subscriber record in the billing platform, selects a plan (10 Mbps, monthly, 100 GB data cap), and assigns a username and password.
2. First connection. The subscriber's CPE initiates a PPPoE session. The router sends an Access-Request to RADIUS. The billing platform authenticates the subscriber, finds an active plan, and returns Access-Accept with the 10 Mbps rate limit, a session timeout of 30 days, and an interim accounting interval of 300 seconds.
3. Usage tracking. Every 5 minutes, the router sends an Interim-Update with byte counters. The billing platform calculates that the subscriber has used 47 GB of their 100 GB cap.
4. Plan upgrade. The subscriber requests a 20 Mbps plan. The operator changes the plan in the billing platform. The platform sends a CoA to the router with the new rate limit. The subscriber's speed increases immediately.
5. Data cap warning. At 80 GB consumed, the billing platform sends an SMS notification. At 100 GB, it sends a CoA throttling the subscriber to 1 Mbps for the remainder of the cycle, enforcing the FUP.
6. Billing cycle ends. The platform generates an invoice. The subscriber pays. The platform lifts the FUP throttle via another CoA, restoring 20 Mbps.
7. Non-payment. If the subscriber does not pay within the grace period, the platform sends a Disconnect Message. The router terminates the session. Reconnection attempts receive Access-Reject until the invoice is paid.

Every step — from first connection to disconnection for non-payment — is driven by RADIUS packets exchanged between the billing platform and the router. The operator's job is to manage subscribers and plans in the billing dashboard. The protocol handles the rest.