[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: multiple freeradius instances with sqlippool, is it safe?
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2022-03-22 12:12:14
Message-ID: C9472AC2-CD03-438C-BE9D-68D4A0BBBB83 () deployingradius ! com
[Download RAW message or body]

On Mar 22, 2022, at 6:24 AM, Matteo Sgalaberni <sgala@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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]