How many NAS kann radius take?

[Arran Cudbard-Bell]

On 13 Feb 2014, at 10:03, Anja Ruckdaeschel <Anja.Ruckdaeschel at rz.uni-regensburg.de> wrote:

> Hi there!
> 
> Having some performance trouble at our campus site with lots of "Discarding Duplicate request" errors.
> 
> Our setup is freeradius 2.2.0 with ldap and sql.  ; Intel Xeon CPU E5630 2.53GHz 2CPUs with 8 Core (hyperthreading enabled), 24 GB RAM
> 
> sql is only used to determine the replied VLAN-ID from a very small read only table by a local  mysql instance, so
> no performance or connection issues here (we do not do accounting into the db or anything like that).
> ldap works fast.
> And there are no messages from rlm_ldap or rlm_sql which indicate trouble with
> sql or ldap connections
> 
> So we kind of sorted out the "classic causes" for slowing down radius ....
> 
> 
> If our people move over the campus with ~3.000 smartphones with actvated wifi, request numbers increase when they enter
> new wi-fi cells and trouble begins: 
> There is barely an auth ok or incorrect in the log but lots of discarding duplicates messages 
> and cpu load is going up to 120 and a higher number of messages like 
> 
> Tue Feb 11 18:22:37 2014 : Error: rlm_eap: No EAP session matching the State variable.

It's probably been expired... Or you have a load balancer which is failing over between
your backend servers?

> at the time when the problem appears. Can this point to the preprocess module where it gets "slow", with eap getting blocked as a consequence of a blocked preprocess module?

No. Not sure why EAP is being slow.

> We have a lot of NAS in our environment: there are over 2200 NAS in total in clients.conf, which are  350 heavily used WLAN access points (auth only, no acct)
> and switches which do a administrative login only every 5 min, and ~ 10 VPN controllers.
> 
> As having so many NAS, preprocess has to do a max of 2200 expansion like 

So you have one entry per NAS in the huntgroups?

> Fri Feb  7 15:41:16 2014 : Debug: [preprocess]  expand: %{Client-IP-Address} -> x.x.x.x

Hmm, hints and huntgroups should probably be removed in 3.1 or 4.0, there's no real advantage
to using them, and they're quite poorly implemented. I doubt the code has changed much since
v1.x.x.

The "%{client:}" expansion allows you to retrieve arbitrary config items from client definitions,
at virtually no cost.

A pointer to the client is written to the request structure. Lookups just involve following 
a couple of pointers, and iterating over a small number of config items.

client foo {
	my_bar = baz
}

%{client:my_bar} -> baz

Put your custom attributes at the beginning of the section for best efficiency :P

> in order to determine the allowed client. That are ~26.400 checks for preprocess in one peap/mschap 
> request for example (~12 request-packtes x NAS).
> Is there some kind of "recommened maximum number of NAS" for one instance of freeradius?

No, the client lookup uses an rbtree so should be O(log n), it will be significantly faster
than preprocess (O(n)) for large numbers of clients.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140213/4c88b278/attachment.pgp>