Virtual server specific SQL schema.

[Stefan A.]

Stephen,

I had have the same problem a few years ago.
In our case, the Firewall was broken and dropped Auth Accept packets on
their way to 2 of the 10 NASs.

We got flooded with requests from this NAS at a rate of about 600/s
At these days, the RADIUS Server was capable of handling only 200/s and
literally stopped working after a few minutes...

As the radius server won't be able to deal with this situations, we
configures QoS on the Cisco router in front of the RADIUS Server.
We calculated the size of a single Access Request Packet, multiplied it with
200 and set this as the maximum bytes to pass per second on :1812 .
We did not QoS Accounting packets, as they are needed to keep sessions and
IP Pools clean.

It's working since these days... Using Telnet, we are checking the counters
on regular basis, which proves, that it is needed from time to time...
We have shared the QoS bandwidth over the actual 22 NASs. If some of them go
creasy, the others will be served as usual. 

So If you problem comes from outside and is known as an error at the NAS,
you might think about such solution.


Regards
Stefan


> -----Original Message-----
> From: freeradius-users-
> bounces+a.freeradius=premit.de at lists.freeradius.org [mailto:freeradius-
> users-bounces+a.freeradius=premit.de at lists.freeradius.org] On Behalf Of
> Stephen Fulton
> Sent: Tuesday, June 15, 2010 10:46 PM
> To: FreeRadius users mailing list
> Subject: Re: Virtual server specific SQL schema.
> 
> Tim,
> 
> You're correct, though there are a few factors causing me to cautious.
> The
> first is I'm working on new, untested hardware, and given the
> complexity of the
> requirements, I'd rather defer to the knowledge of the list re:
> performance,
> before fully implementing it.  The second is that the NAS'es which will
> communicate with this RADIUS cluster are known to drop auth requests
> and issue a
> denial if the response is not "quick" enough.  Unfortunately this is a
> 3rd party
> managed set of NAS'es, and therefore limited in what I can do.
> 
> All that said, I have no concerns about FR, its mainly the DB and the
> 3rd party
> NAS'es.
> 
> -- Stephen
> 
> On 6/15/2010 16:00, Tim Sylvester wrote:
> >> Thanks for the suggestion, that's actually my back-up plan.  The key
> >> issue is that a single MySQL server will be used, and peak-load on
> that
> > server
> >> can be quite high.  By creating multiple instances, I cannot scale
> the
> > maximum
> >> number of sockets high enough meet the requirements.  Perhaps on
> missing
> >> something with regard to MySQL optimization, but during testing I
> found
> > increasing the
> >> maximum number of sockets was necessary to meet the performance
> > requirements.
> >
> > What level of performance do you need - authentication/sec&
> accounting
> > packets/sec? FreeRADIUS with MySQL is able to 1,000s of
> authentications/sec
> > and reasonably large number of accounting packets/second. You should
> be able
> > to tune MySQL to improve the performance.
> >
> > Tim
> >
> >
> > -
> > List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html