Local AAA Backends

Guide on when and how to create standalone Radiator instances without external dependencies

Local AAA Backends

Radiator can work completely standalone for AAA processing. This approach is high-performing, reliable, and simple to set up, though it does have some limitations.

A local Radiator deployment consists of clients (network devices, VPN servers, Wi-Fi controllers) connecting to a Radiator server, which authenticates users against local storage and stores audit logs locally:

Local HA and LB

The local solution allows for a fairly simple HA and LB setup by running multiple Radiator instances:

To avoid databases getting out of sync, hourly or daily full database synchronization is recommended.

Benefits

By relying only on networking and storage, the environment has minimal external dependencies, improving reliability.

This allows for centralized access control, but with local 'cache' of users. So the AAA processes will continue to work on last available data. This will keep your users authenticated even if outside connectivity has been disrupted.

Due to no centralized database for users this has no performance impact on the main database. Nor is it impacted by database maintenance activities.

Drawbacks

The user database needs to be synchronized externally into the system. This usually ends up being periodic (like once an hour).

The user database is read-only. Radiator has nowhere to store session state or user login history. With multiple Radiator servers this makes Change of Authorization (CoA) type of activities more difficult to implement.

So the feasibility of this solution depends on the use case.

Memory-Only Operations

For extreme use cases, Radiator can continue working without functioning storage. A typical example is a 'disk full' scenario.

  1. The user database is copied to memory from disk using the JSONFile backend. This works well for up to 100k users.
  2. Logging survives disk write failures. See the Logging article on how in-memory logs work (they are always on).
  3. Certificates for encryption are also read into memory and only updated when they change on disk.

This is the most performant AAA solution. User lookup times are measured in microseconds. Logging is asynchronous and does not impact single request speed. Encryption will consume CPU time regardless of whether storage is memory-based or disk-based. See Password Hashing and Radiator Sizing for more details on encryption performance.