On 15 Jun 2023 at 14:58:14, Alan DeKok <aland@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!