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.
