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

Alan DeKok aland at deployingradius.com
Thu Jun 15 14:43:29 UTC 2023


On Jun 15, 2023, at 10:18 AM, work vlpl <thework.vlpl at gmail.com> wrote:
> 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.

  All packets from one IP should be fine.

> 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.

  *What* is doing is doing the hash?  Is it the load balancer?  If so, use another one.

  If the load balancing is done in FreeRADIUS (and it should be), see proxy.conf.  There is a "client-port-balance" configuration which hashes on client IP+port, which works for sane clients.

  But FreeRADIUS also supports keyed-load-balance.  In which case you can control which attributes are used to do load balancing.

> 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.

  That sounds like the AP is broken, to be honest.  Using a different source port for each packet in an ongoing EAP session is completely stupid.

> 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.

  So use "keyed-load-balance", and copy Calling-Station-Id to the Load-Balance-Key attribute.

  FreeRADIUS will ignore the client IP+port, and key on the Calling-Station-Id (i.e. MAC address).  That shouldn't change from packet to packet.  So the load balancing will send all packets for one session to the same back-end RADIUS server.

  Even if the AP is completely broken.

> And for load balancing, I am using freeradius and only the proxy module.

  That's good.

> 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

  You still haven't explained why it's opening 1024 listeners.  So you're keeping some part of your configuration secret, I don't know why.

  Hint: I can't read your mind.  I can't magically log into your serves remotely and see what they do.  I can only read the messages you post to the list.  And if you don't explain something, then I don't know anything about it.

> 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.

  If you try libkueue on Linux, then you're on your own.  It might work.  If so, great.  If not, we won't spend time fixing it.  It is not officially supported for v3.

  I would suggest using keyed-load-balance as I said before.  It should solve the load-balancing issues.

  And I still have absolutely no idea what you think the server needs 1024 listeners.  It makes zero sense, and you're refusing to explain.

  The underlying problem here is that you're doing massive amounts of work for no reason.  You're wasting your time by trying libkqueue, instead of using a documented solution.  You're wasting our time by asking for help, and then refusing to describe what you're actually doing.

  Please get better at explaining things.  I'm not a mind reader, and I don't want to be.  If you don't explain what you're doing, then I can't help you.

  Alan DeKok.



More information about the Freeradius-Users mailing list