Hi Leigh,
The problems with accounting for volumes you describe are (I think) fairly
common. Here is the little light I can shed on some of them:
1. Getting volume stats by SNMP can be very unreliable. I have seen a number of
ISPs stumble on this.
2. The figures you get from SNMP can differ considerably from measurements from
other methods, due to link saturation, compression and encapsulation being
counted differently etc.
3. Counters rolling over is not uncommon. Ciscos roll over at 32 bits, other, I
dont know.
4. Some NASs send Acct-Status-Type=Alive accounting packets during the session.
5. I have forwarded your message to a chap who I know has some _excellent_ SNMP
monitoring->mysql software with a web interface. Its about 3000 times better
than MRTG, highly configurable, with beautiful graphs, but I dont know if its
on offer to anyone. You may hear from him.
Cheers.
On Jul 6, 10:18am, Leigh Spiegel wrote:
> Subject: (RADIATOR) SNMP Counter logging
> Hello,
>
> I currently use Radiator for our radius solution and MRTG to collect SNMP
> data from our routers.
>
> I wondering if there are any products or plugins for Radiator that will
> collect SNMP interface counters
> for accounting to an SQL database. I currently use MRTG and the perl script
> that comes with it for calculating
> traffic. I run the script every day and it calculates throughput based on
> the 5 minute SNMP polls it has completed
> during the day and I've then written a few things to get that into a
> database for each interface I'm monitoring.
>
> I have concerns that this information may not be really accurate and I'd
> prefer something designed for this purpose. Currently all the information I
> log in this way is not used for billing.
>
> I've also had problems with some customers connecting for over 1 month
> without a disconnection. Then I don't have a stop record I can use for
> billing in that month. Therefore I have to disconnect the customer before I
> can bill them. Maybe the solution is to disconnect people who connect for
> long periods of time. The other concern I have is how large the counters
> can get before they roll over? Is this NAS dependant?
>
> It would be nice if there was a radius record other than a stop or start, eg
> an update record for those clients who hardly ever disconnect. I guess this
> is not in the radius spec and may be considered something that radius may
> not address.
>
> If anyone knows of any good software for pulling SNMP interface stats into a
> database with a fair amount of logic for handling equipment resets I'd love
> the URL.
>
> Regards,
>
>
> Leigh Spiegel
> Senior Systems Administrator
> [EMAIL PROTECTED]
>
> WinShop Services
> PH: (07) 5532 0355 FAX: (07) 5531 4846
> http://www.winshop.com.au/
>
>
> ===
> Archive at http://www.thesite.com.au/~radiator/
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from Leigh Spiegel
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
