[RADIATOR] Limiting the number of Radsec connections

[Heikki Vatiainen]

On 17.2.2026 16.09, Stefan Paetow via radiator wrote:

> I have a situation where I run a server with a large farm size, but I am 
> trying to keep the number of outgoing Radsec connections low. To my 
> knowledge, if I have a farm size of 64, all 64 of those farm threads 
> will eventually create a connection to the other server.

Yes, that's correct.

> FreeRADIUS sets a limit of 16 threads and connections per client (per 
> IP), and outgoing traffic seems to be handled by a single thread there. 
> Radsecproxy is similar in behaviour to FreeRADIUS. We’d prefer not to 
> have to ask the site in question to up their pool size in FreeRADIUS but 
> rather limit our number of threads dealing with outgoing Radsec.

That's reasonable. Tens of connections from the same IP is quite high.

> I suppose this would mean either:
> 
> - A hidden feature (is there one)

I don't think so. The worker processes are quite independent from each 
other and can't automatically, for example, pass packets to designated 
forwarders.

> - Running a separate farm (of let’s say 8) that deals only with outgoing 
> Radsec, and having to fiddle our config to tell our 64-size farm to 
> connect internally to the farm of 8 to deal with the traffic.

I'd consider this one of two options: the other is to check if there's 
soemthing in the current configuration that allows dropping the farm 
size to a smaller number. I guess you have already looked at the 
possible changes. Is it logging, DB lookups or something else that makes 
the througput per packet slow?

> Is there any way around that? If not, is the latter what I would need to 
> do? And is this something I should be able to do without complicated 
> port assignments?

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.

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.

Thanks,
Heikki

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