On Wed, Aug 21, 2013 at 2:04 AM, Alan DeKok <aland@deployingradius.com> wrote:
Peter Lambrechtsen wrote:
I'm currently playing around with the Status Server for stats gathering and was hoping to have a minor change in the interface to support extracting the Client information under different VSAs rather than reusing the current "FreeRADIUS-Total-*" VSAs. It's not particularly logical in my view to have the same VSA returned twice in a Access-Accept, and then needing to determine if it's the client related one or the global server related one by it's sequence in the payload. It would make more sense in my mind to have the Client stats as separate VSAs.
They should be separate VSAs. I'm not sure what crack I was smoking when I cam up with the current VSAs, but oh well.
My inclination now is to leverage RFC 6929 and the extended attributes, and TLVs. We could create VSAs which mirror the SNMP information in RFC 4668..4671.
Or, we could create our own TLVs in a sane format. e.g. have a "parent" TLV for home server, client, and "this" server. Inside of that parent, have the *same* list of child TLVs, in the same order, with the same meaning.
I'm inclined to leave 2.x the way it is. It's imperfect, but it's workable. The new 3.0 code is preferred for new functionality.
When looking through the master branch the suggestions I were making were to master, so the way that 3.0 is planning do things. I think the TLV approach is a valid one. One nice part of that is the ability to list all servers/proxies/clients could be listed in a tree structure way.
The nice thing about the 3.0 code is that if you're using the 3.0 radclient, you don't really care that the counters are buried inside of TLVs. They come out in "attr = value" form, just like anything else.
Nice, right now I have modified TinyRadius java client as that suits my needs quite nicely after adding the Status Message and support for Message-Authenticator as we have an exiting java monitoring tool that monitors all our other services across ldap/sql/http and a whole myriad of other systems for service and server availability and I have easily extended it to use the Status call via TinyRadius and that's working a treat. Currently wiring a bit more logic into it to handle peaks & dips so when one of the BNG(s)/NAS goes AWOL or decides to swap between primary/secondary FreeRadius instance which it doesn't alert from in the BNG Syslog which is a bit of a bother or for some reason gets a rapid increase in requests from a interface failure or other random things that can occur in the network we can send an alert to the relevant team to investigate. As that sort of stat analysis is what we are looking to achieve without building a massively complex solution that will be hard to maintain. If it's ok I will look to extend the current dictionary to include FreeRadius-Client-* using sequential numbers and those few minor changes in stats.c. And at least push that as a possible patch for 3.x and perhaps 2.x as it's pretty much the same code. Then when further thoughts have been done about the best way to do it long term has been decided then that can be supported too in 3. Cheers Peter