Thank you very much for the quick response.
I understand what you said. Another question is does Radiator, once doing
an SNMP check, update the session (SQL) database if it discovers that
indeed the user is not really currently logged in and should be allowed to?
In other words, does ut go ahead and delete the entry out of the session
database and replace it with the correct one?
Again, my thanks!
I will be having several more questions involving Radiator and wonder if it
is more proper to purchase email support? I don't know what your reasonable
limit is for lots of questions. I plan to ask more about Reply-Items.
Thanks in advance!
-- Tim
At 09:56 AM 12/27/2000 +1100, you wrote:
>Hello Tim -
>
>On Wednesday 27 December 2000 02:06, Timothy G. Wells wrote:
> > Greetings,
> >
>
>All the best of the season to you too.
>
> > I currently use a mySQL session for using with multiple NAS's but I only
> > use a single Radiator server. Every now and then users are kept from
> > logging in because the sql is out of sync and a user has actually logged
> > off but is still in the database. So I'm thinking of using either SNMP
> > and/or internal tables.
> >
>
>OK
>
> > The questions are:
> >
> > 1. Does the SNMP query all NAS' or just the one the new requested
> > connection is coming from? If just the single NAS, is there a way to have
> > them all be queried (4 PM3's)?
> >
>
>Any of the NAS-Type checks (including SNMP) only ever does a direct check
>when Radiator determines that a simultaneous use limit has been exceeded. In
>other words, the NAS's are never queried except when a user exceeds his limit
>(or at least seems to according to Radiator). When this occurs, Radiator goes
>through the list of connections for this specific user (from whichever
>session database, internal or external) and checks only those NAS's shown to
>have a connection for the user, to verify that the connection is still there.
>If the connection has indeed gone away, then the entry is removed from the
>session database.
>
>Given the above scenario, there is no need to query all of your PM3's.
>
> > 2. I thought about using Radiator's internal session database but I would
> > like to query it for users since I wrote a web interface to the current
> > database session and be able to disconnect folks, etc. So, can the
> > SNMPAgent show all logged in users according to Radiator's internal session
> > database?
> >
>
>You will get the same picture from either an external or an internal session
>database.
>
> > 3. How bad are the hits of constant SNMP queries to my PortMasters?
> >
>
>As described above, the queries are not constant, however the question is a
>good one although for a different reason. You won't slow your NAS down with
>SNMP queries, however you can cause a real performance hit on Radiator if the
>SNMP queries take a long time to execute, as Radiator waits for the reply.
>
>Note that the usual reason for this type of problem is almost always lost
>radius accounting stop records, either due to congested links (easily fixed
>with more bandwidth) or NAS bugs (easily dealt with by upgrading your NAS
>software).
>
>My recommendation in this situation is always to do some thorough debugging
>using the trace 4 debug in Radiator together with tcpdump/snoop/sniffer
>packet tracing on the wire(s) to ascertain exactly what is happening.
>
>Also note that there is no silver bullet available either, the problem you
>describe is simply due to the design of the radius protocol which is based on
>UDP, in which packets can and do go missing from time to time.
>
>hth
>
>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.starport.net/~radiator/
>Announcements on [EMAIL PROTECTED]
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
