Subject: Using radsniff to generate stats

[Arran Cudbard-Bell]

Hi Rui,

> I have read the page you refer, and you say FreeRadius has no idea about the dropped packets. Would it be possible, or interesting to modify FreeRadius to give directly stats also like for instance named provides an interface for retrieving statistics?

It already has interface(s) for retrieving stats (radmin and status-server). There is already a munin plugin to query radmin, and an snmp proxy script to expose status-server.

Regarding UDP:
http://stackoverflow.com/questions/2289830/how-to-monitor-linux-udp-buffer-available-space

Suggests there is no programatic way of retrieving UDP recv buffer statistics, so they couldn't be exported from FreeRADIUS. If you wanted to do it with another plugin, AFAIK there are no per-socket counters, only global ones, so sure you can graph differences in drops, that'd be fairly trivial, but how do you know which protocol the drops relate to, or even which interface the packets came in on?

It also doesn't tell you whether a request eventually succeeded, so you don't know how many requests failed due to packet loss. During large traffic spikes you're likely to see some udp recv buffer overflow, that's fine, you don't really care if you drop packets in those situations, you just care whether the request was processed by the RADIUS server before the NAS gave up.

radsniff can also link retransmitted Accounting-Requests based on a subset of attributes. This is important when your NAS updates an attribute such as Acct-Delay-Time on every retransmit. There's no reason for FreeRADIUS to link requests in this way, it's something better off being done by another process.

> How about performance of this particular solution of sniffing traffic?  I wonder how much load?

That of course depends on your system. But to give a ballpark figure, in stats mode, at 4000t/s (that is 4000 requests/s and 4000 responses/s) it uses 20% of one core. At the 15,000t/s rate it uses about 70% of one core. On a Core i7 (I7-3820QM) @ 2.7GHZ.

For the vast majority of systems, even 4000t/s will be way over what the RADIUS server is capable of (due to dependencies on backend databases/directories).

> Granted, RADIUS traffic volume is particularly low, however, in linux, the packets have to be copied to userland to libpcap to use them, contrary to for example, FreeBSD. (Note: There is the PF_RING patch. I havent tested it out)

That's not quite true, since libpcap 1.0.0 it has memory mapped the capture buffer into user land.
The userland dissector just gets a pointer (returned by pcap_next/pcap_next_ex) into the shared memory, there's no copying involved.

> Note: Dont take the comments personally, it is just in the past I have always favoured solutions that were an alternative to sniffing traffic.

There's not a viable alternative in this case. As the page also stated, this is also intended to be used with black box appliances, such as ACS, IAS, NPS and various hardware appliances (most of which are actually running FreeRADIUS, but often very old versions with truly 'special' configurations).

-Arran

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/20140103/22c58696/attachment.pgp>