We’re happy to announce the release of Radiator 10.34.0.
The main highlight of this release is RadiatorDB, a new database functionality built into Radiator Server. We’re also highlighting ipmap, introduced in Radiator 10.33.2, which provides an efficient way to manage dynamic RADIUS clients and networks.
There are also important improvements to RADIUS performance, backend load balancing, scheduled tasks, configuration management, and RADIUS/1.1 over TLS.
RadiatorDB
New in 10.34.0
RadiatorDB is a built-in multimaster document database for Radiator Server, backed by PostgreSQL. It provides a flexible way to store AAA data, operational records, and other Radiator-managed data without requiring a separate application layer around an external database.
RadiatorDB stores data as JSON documents organised into collections. Multiple PostgreSQL instances can be configured for multimaster replication, allowing writes to any instance while changes are automatically replicated between them.
RadiatorDB features include:
- Multimaster replication between PostgreSQL instances
- Writing to any RadiatorDB instance
- Flexible JSON document storage
- Role-based access control for the Radiator UI and REST API
- Radiator UI support for creating, viewing, editing and deleting documents
- Revision history and audit trails
- Automatically expiring documents
- Automatic PostgreSQL schema management
- Automatic replication management defined in Radiator configuration
Although RadiatorDB is backed by PostgreSQL, it is a document database rather than a conventional SQL database. Data is managed through the RadiatorDB REST API, Radiator configuration, and the Radiator Management UI.
RadiatorDB has been deployed by pilot customers, and with 10.34.0 we are making it an official part of the release and inviting customers to try it.
Read more about RadiatorDB
Dynamic RADIUS clients with ipmap
New in 10.33.2, enhanced in 10.33.3
The ipmap functionality provides an in-memory IP prefix map for IPv4 and IPv6. It can be populated from external data sources and used to dynamically determine which RADIUS client configuration applies to an incoming request.
In practice, this means ipmap can be used as a dynamic RADIUS client list.
Instead of maintaining a large list of RADIUS clients directly in the configuration, client addresses and networks can be kept in a database or other data source. Radiator loads that information into ipmap and performs client lookups against the in-memory data.
For example, a database could contain:
| Network | Client |
| 192.0.2.0/24 | branch-office-1 |
| 198.51.100.0/24 | branch-office-2 |
| 2001:db8:1234::/48 | head-office |
Radiator can use the IP address of an incoming request to find the best matching network and select the appropriate client configuration.
ipmap uses longest-prefix matching, so both individual addresses and larger network ranges can be managed efficiently. It can also be repopulated automatically when the source data changes.
The combination of RadiatorDB and ipmap is particularly useful:
RadiatorDB → JSON data → ipmap → dynamic client matching → RADIUS processing
RadiatorDB can provide JSON data containing client and network information, while ipmap keeps the information in memory for fast lookups.
The @pre-client functionality can also be used together with clients, making it possible to migrate from static to dynamic client matching without having to change everything at once.
Read more about ipmap
Further improved RADIUS performance
New in 10.34.0
Radiator 10.34.0 changes the way RADIUS backend connections are selected.
RADIUS backend pools now use least-outstanding connection selection by default. Requests are sent to the connection with the fewest outstanding requests, making better use of available connections when there is a high level of parallel traffic.
The connection window setting can also be used to control how many requests may be in flight on a connection.
These changes are aimed particularly at high-throughput deployments where making better use of existing RADIUS connections can improve performance without simply adding more connections.
Backend load balancing and high availability
New in 10.33.1, enhanced in 10.34.0
The 10.33.x releases introduced several improvements to backend load balancing for PostgreSQL, MySQL, and LDAP.
In 10.33.1, Radiator added the least-connections server selection strategy. Requests are sent to the server with the fewest connections currently in use. Radiator also gained faster failover when a backend connection pool is saturated.
PostgreSQL and MySQL backends also gained lazy connection pooling. Radiator can now start even when a database server is temporarily unavailable and establish connections when they are needed.
These capabilities make it easier to build backend configurations that distribute traffic across multiple servers while handling backend failures without unnecessary delays.
RADIUS/1.1 over TLS
New in 10.34.0
Radiator 10.34.0 adds support for RADIUS/1.1 over TLS, based on RFC 9765.
RADIUS/1.1 can be negotiated using TLS ALPN. It provides stricter packet validation and uses mutual TLS rather than the RADIUS/1.0 packet authenticator.
Support is opt-in, so existing RADIUS/TLS configurations continue to work as before.
The radiator-client and radperftest tools can also be used to generate and test RADIUS/1.1 traffic.
Scheduled tasks
New in 10.33.4
The new timer configuration block allows Radiator to run pipelines on a schedule.
Timers can use fixed intervals or cron expressions, with support for jitter and IANA time zones.
This is useful for tasks such as periodic maintenance, polling, cache updates, and other work that needs to happen automatically at regular intervals.
Configuration management improvements
Enhanced in 10.33.2 and 10.33.3
The 10.33.x releases introduced several improvements to configuration import, export, and deployment.
Configuration archives now include metadata describing the Radiator version, creator, timestamps, and deployment changes. The Management UI can show this information and warn about version mismatches before an archive is imported. This was added in 10.33.3.
Configuration export and import were introduced in 10.33.0, providing a way to package and deploy Radiator configurations through the Management UI and REST API.
Other changes
There are many other fixes and enhancements in the releases between 10.33.0 and 10.34.0, including:
- TACACS+ over TLS, introduced in 10.33.2 and extended with RFC 9887-compatible settings in 10.33.3.
- PBKDF2-HMAC password hashing, introduced in 10.33.3.
- The must action, introduced in 10.33.3, for making required authentication actions fail explicitly when they return ignore.
- JSONPath support for iterating JSON data, introduced in 10.33.3, including use cases such as populating ipmap from JSON.
- Improved radiator-client testing, including response attribute and message assertions, introduced in 10.33.1.
- Environment variables for all major configuration value types, introduced in 10.33.1. This includes durations, booleans, numbers, IP addresses, and IP prefixes.
For the complete list of changes, see the individual release notes for 10.33.1, 10.33.2, 10.33.3, 10.33.4, and 10.34.0.
Upgrade to Radiator 10.34.0
Radiator 10.34.0 brings together the changes from the 10.33.x releases and introduces RadiatorDB and RADIUS/1.1 support.
We particularly encourage customers to try RadiatorDB and ipmap. Used together, they provide a straightforward way to keep RADIUS client information in a database while using an efficient in-memory map for client matching.
As always, we recommend testing the release in a development or staging environment before upgrading production systems, and backing up your configuration before the upgrade process.
Read the complete Radiator 10.34.0 release notes
If you have any questions about Radiator 10.34.0 or would like to discuss the new RadiatorDB functionality, please contact the Radiator Software team.