(RADIATOR) Online SQL database

[Hugh Irvine]

Hello Leon -

You will need a packet sniffer, the Radiator log file and considerable 
patience to track down this sort of problem.

Possible causes include (non-exhaustive list):

	saturated links

	NAS bugs or upstream network problems (or underpowered NAS)

	slow SQL database response

	UDP buffer overflow on Radiator host (unlikely)

	phase of the moon / sunspots (even more unlikely  :-))

regards

Hugh
	

On Friday 11 May 2001 00:33, Leon Oosterwijk wrote:
> Griff,
>
> We have run into this problem as well. We use our session database for
> downstream customers to view their port usage. it is imperative that the
> session database is accurate and does not contain stale entries. in
> response I wrote a check program that polls the NAS units and find it's
> stale entries using perl-SNMP. The script ususally finds about one stale
> entry per 5 minute period. Why would our network be dropping it's
> accounting packets like this?
>
> Leon
>
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Thursday, May 10, 2001 1:29 AM
> To: Griff Hamlin; radiator at open.com.au
> Subject: Re: (RADIATOR) Online SQL database
>
>
>
> Hello Griff -
>
> On Thursday 10 May 2001 10:51, Griff Hamlin wrote:
> > Hello all,
> >
> > In using an SQL session database, and then a DefaultSimultaneousLogin
> > with 3 servers (2 for authentication and 1 for accounting) I find that
> > sometimes a stop record does not make it to the accounting server and
> > there fore the user remains in the Session database and is denied
> > further access. With as many routers and modems as we have that we do
> > not own, it is not practical to have to querry them each time to see if
> > the user is still on, we have to be able to trust the database. My
> > question is, does Radiator provide facility to purge the database of
> > records that are over 2 hours old, or some specified time. That way,
> > customers whose stop records don't make it to us will still be
> > authenticated when they try back later. Any help is appreciated. Thanks.
>
> As you will have seen from the debug logs, Radiator tries to be
> self-healing
>
> in the face of lost accounting packets by doing a preventative delete on
> the
>
> session database for every new request (using the NAS/NAS-Port
> combination).
>
> For further processing of the session database as you describe above, you
> will have to write a cron job or similar to do whatever housekeeping you
> wish
> to undertake.
>
> Otherwise if you get a support call from the customer, you could easily
> provide a web page for your help desk staff so they could delete the stale
> entry manually.
>
> If I were you though, I would try to find out why you are losing stop
> records.
>
> regards
>
> Hugh

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.