[RADIATOR] Limiting the number of Radsec connections

[Heikki Vatiainen]

On 4.3.2026 8.43, Stefan Paetow wrote:

> In our case it's sheer volume. We're one of the larger deployments of this type in the world, so we're looking at around 148 million authentications (that could be resolved/routed) last month. We've reduced our farm sizes already, but that's mostly RADIUS, not Radsec.

That's a nicely sized number. If each authentication takes about 10-15 
request/response pair (EAP with certificates), that would in average get 
close to 1000 requests/s. And then there are peak times with much more 
traffic.

>> The latter, separate workers for outgoing RadSec, is likely the way to
>> go unless there's something that can be done to speedup the current
>> configuration which would allow reducing the farm size.
> 
> Ok, so effectively for those organisations using Radsec (i.e. us initiating Radsec connections to them), use a 'bogus' host (localhost on a specific port to refer to the Radsec-only Radiator instance) that does a localhost-to-localhost translation to Radsec?

That would be the case. Radius over loopback to the chosen host that 
talks RadSec to the remote organisations.

>> An option could also be Radiator 10 which is built differently and does
>> parallel processing completely differently. It's made with Rust and has
>> different architecture. It's faster and still catching up with features.
>> We could arrange a demo to discuss if it could be a possibility.
> 
> This could be an option... how different are the configuration files between Radiator 10 (Rust) and Radiator 4 (Perl) given that we have a host of Perl-defined hooks to do some special/specific processing?

It took a while, but now I can show what the full configurations would 
be. Please see https://github.com/radiator-software/radiator-radconfs
for full configurations.

These were in preparation and were just made available. As you can see 
it's different, although there are some similarities. One of the 
differences is that there's one more layer, named policy, which is 
chosen before a handler. In Radiator 4.x and earlier, handlers were the 
top level construct.

With policy, you could, for example, have a separate policy for TACACS+, 
Radius WLAN, Radius VPN, etc. and within each policy, as many hanldlers 
as the processing logic requires.

Thanks,
Heikki

-- 
Heikki Vatiainen
Radiator Software, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software