multiple freeradius instances with sqlippool, is it safe?

[Alan DeKok]

On Mar 22, 2022, at 6:24 AM, Matteo Sgalaberni <sgala at sgala.com> wrote:
> This timeline happened:
> - radius1 received the auth packet and sqlippool assigned the ip (correct information on radippool)
> - radius2 received the accounting stop and sqlippool freed the ip (destroying the information on radippool of that ip address previously assigned)
> - radius2 received the accounting start and do nothing on 

  That's how RADIUS works.

  The packets are processed in the order that they are received.  And network delays / dropped packets can cause packets to appear "out of order".

  The packets also contain time stamps and/or delays.  So the server can tell (roughly) when an event occurred.  The queries use that information to ignore "old" stop/start packets.

  So what's happening here is that the NAS is sending the "stop" packet *after* it sends the auth request.  Which is fine, and the server *should* delete the IP address assignments.

  Find out why the NAS is sending the stop/start packets with the wrong timestamps.

> Seems to be a concurrency issue occurred because the BRAS (Cisco ASR1001X) sent the auth packet and the acct packets to different radius servers and executed the queries in a logical wrong order. 

  Please try to figure out how to make sure that the queries are run in the "right" logical order.  Use only information which is in the RADIUS packets.

  It's impossible.

> Can this scenario happen also in a single server setup? Eg: the accounting stop packet is processed after the authentication packet.

  Yes.  UDP packets are not ordered, especially to different destinations.

> My impression is that the BRAS should send the auth and acct to the same server.

  No.  Or, only if you configure it to do that.

> Also the radius should process the packets in the right order to prevent this issue.

  No.  This is *impossible* to do.

  Alan DeKok.