Using libkqueue, how stable it is with freeradius 3.x?

[work vlpl]

>
> On 15 Jun 2023 at 14:58:14, Alan DeKok <aland at deployingradius.com> wrote:
>
 If you're using UDP, then the client source port doesn't matter.
> FreeRADIUS doesn't open a new socket for every UDP packet.
>

I apologize for raising this topic, as it may be unrelated to my original
question. However, if you see alternative methods of achieving load
balancing or recommend a different load balancer, I would greatly
appreciate it.


So these IoT clients create a huge load and if I am using another load
balancer that cares only about ip and port I have a next issue. Clients are
UDP and traffic is from one ip address.

If I will use a hash or IP address as a balancing key, then balancing will
not work - all traffic will be sent to 1 server because the hash from 1 ip
address will be the same.

Hash from ip + port - I can get a good spread between servers. But the
clients or AP sends each new radius packet from a new random port this lead
to a situation when packets from 1 radius session are routed to different
servers, and the radius server can't authorize users with missing packets
from the sequence. And I can't fix clients or AP.

So because of that, I can't use the udp source port in the hash key for
balancing distribution, then I need to use something else. I think radius
attributes like Calling and Called Station ID are good enough.

And for load balancing, I am using freeradius and only the proxy module.
Freeradius working great and fast. But with many home servers and virtual
server configurations that fit my need to fully consume server resources
and updated value of FR_EV_MAX_FDS constant, I hit select() limitation. I
know it is a weird configuration. And the general suggestion probably will
be to add another server for a horizontal scale. But still, I want to try
kqueue.






>  Did I say use the packaged release, or the most recent one version from
> git?
>
>
Got it, thank you!