RADIUS-Based MikroTik Stations in NOVA WiFi: Centralized Control, Scale, and Tradeoffs

RADIUS-based MikroTik stations are designed for centralized control. Instead of each router handling full user logic locally, a remote RADIUS server manages most authentication and accounting decisions. This is a strong model for operators who want policy consistency across many routers.

At the same time, it is important to be clear: API basis and RADIUS basis are not equal in control flow. In API basis, NOVA talks directly to MikroTik and the router enforces nearly everything locally. In RADIUS basis, the router becomes an access device while the remote server becomes the policy authority.

What “RADIUS basis” means in practical terms

In RADIUS basis, the router forwards user authentication/accounting to a RADIUS server. The server decides whether a user is valid, what limits apply, and when access should stop.

This shifts core user control away from local router secrets and into centralized records.

Operationally, that means:

• Credentials and policy are managed centrally
• Usage/accounting data is aggregated in one place
• Enforcement decisions are driven by server-side records
• Routers require correct AAA/RADIUS setup to function properly

How RADIUS stations work in NOVA WiFi

1. You add the station with system basis = RADIUS.
2. NOVA configures required router-side PPPoE infrastructure (pool, PPP server, profiles) and RADIUS AAA linkage.
3. User records and lifecycle control are handled in RADIUS tables/server logic, not local PPP secrets.
4. When users expire (time/data), NOVA updates central records and enforces state through RADIUS-driven flow.
5. Routers continue forwarding auth/accounting requests to the server for real-time decisions.

API basis vs RADIUS basis: the real technical difference

API basis: users and service actions are controlled directly on MikroTik via API. Router-side objects (users/secrets/session actions) are managed locally by NOVA commands.

RADIUS basis: a remote server manages most user logic. Router acts mainly as enforcement edge and forwards auth/accounting to RADIUS.

Simple comparison

• Control location: API = router-local, RADIUS = centralized server
• Dependency model: API = router/API path critical, RADIUS = RADIUS server path critical
• Scale consistency: API = per-router consistency work, RADIUS = global consistency by design
• Failure blast radius: API issues often isolated per router, RADIUS server issues can affect many routers
• Policy rollouts: API needs distributed updates, RADIUS can apply policy centrally

When API is often better

• You need immediate direct control per router with minimal external dependency
• You want simpler troubleshooting at single-station level
• Your operation is smaller or mid-scale and prefers router-local enforcement
• You prioritize fast local actions like direct user/session operations from dashboard

When RADIUS is often better

• You operate multiple stations and want one policy authority
• You need centralized accounting and access logic across sites
• You want standardized behavior regardless of router differences
• You have strong server reliability and clear RADIUS operational discipline

Important truth: RADIUS is powerful, but not “set and forget”

RADIUS deployments need disciplined infrastructure. If central server connectivity, secrets, AAA settings, or accounting paths are wrong, access can fail widely. Centralization improves consistency, but also concentrates risk if not managed correctly.

Minimum requirements for stable RADIUS operations

• Correct router-to-RADIUS secret alignment
• Reliable network path between stations and RADIUS server
• Proper PPP AAA and RADIUS service settings on router
• Clear expiry/usage enforcement logic in central records
• Monitoring and alerting for RADIUS availability and latency

Final guidance for ISP operators

If your goal is direct per-router control with low central dependency, API basis is usually the stronger operational fit.

If your goal is centralized policy and accounting at multi-station scale, RADIUS basis is usually the better architecture.

The best choice is not hype-based. It depends on your network scale, reliability maturity, and how your team handles operational risk.