Hello Julio -
On Wednesday 31 January 2001 20:15, [EMAIL PROTECTED] wrote:
> hi all,
>
> tunning and benchmarking Radiator.
>
> we've this scenario:
>
> 3 Radius clients (with radpwtst)in a VLAN
> 2 Radiators in another VLAN
> 1 Cisco Arrowpoint loadbalancing between clients & servers
>
> 1 LDAP host for auth
> 1 MySQL host for DYNADDRESS and acct
>
> A high number of requests are simulated from the client side with 'radpwtst
> .... -nostop'
> Every client sends 333 requests with a total of 999 requests.
>
> When the load finish, there are in RADONLINE 999 users but some of them
> share the same ip in framedipaddress.
>
> In RADPOOL only 600 (more or less) has been asigned.
>
> Taking an eye to the logs, it seems like when 2 o more auth requests arrive
> simultaneously and ask to MySQL for obtain the next free ip in RADPOOL, the
> answer is the same ip for both requests, and both requests will update the
> same ip in RADPOOL.
>
> Could be an explanation of 600 ip 'catched' in RADPOOL and not 999.
>
> So in RADONLINE (when acct arrives) they will have the same ip.
>
Yes, there was a bug in the AddressAllocatorSQL code.
Here is the patch entry:
28/1/01 New version of AddressAllocatorSQL.pm that removes a potential race
condition when multiple Radiators try to allocate from the same address
pool.
Please upgrade to Radiator 2.17.1 and apply this patch from the 2.17.1
patches area.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
