(RADIATOR) Port limit accuracy

[Steve Roderick]

Marius,

I recommend doing your configuration as David described below. I would add a
couple of thoughts though. If you have a NAS that sets up SNMP table entries
for sessions before they are fully logged in, tears them down before the
radius stop has been sent, or generally does a bad job synchronizing SNMP
and radius accounting, you should consider an intermediate step. This extra
step will also allow recovery from failed SNMP queries. In this step your
cron script would flag all of the missing user records (missing on the NAS
SNMP query, but still in your session database) as invalid. This will allow
the user associated with the entry to get online (alter your countquery
appropriately). During your next cron run if you find entries that are
marked invalid and are still not showing via SNMP then you would delete
them. If they are marked invalid but they are now showing via SNMP then you
would revalidate them. This would under extremely rare circumstances and
very unlikely timing scenarios allow a user to get online with more than one
session, but would eliminate any false denials (highly desirable). In
addition you can now run your synchronization script continuously (perhaps
with a 1 minute delay between runs).

Whether or not you add the step above you have offloaded all simultaneous
use verification from Radiator itself. All Radiator has to do is a simple
database query. In addition, if you add the invalidating step above you will
decrease the probability of an inappropriate denial and be able to decrease
the interval at which you synchronize your session database with the
actually NAS.

Steve

----- Original Message -----
From: "David Miller" <dmiller at newportnet.com>
To: <radiator at open.com.au>
Sent: Thursday, January 02, 2003 11:32 AM
Subject: Re: (RADIATOR) Port limit accuracy


> Marius:
>          We run a similar setup with primary/secondary radius servers. We
> use a pair of MySQL database servers to maintain the session database for
> enforcement of Simultaneous-use restrictions. The session databases are
> configured to replicate in a circular master/slave, slave/master
> relationship. This has functioned flawlessly for a year or so now. Too
help
> insure the databases are up-to-date with the NAS's (portmasters) we run a
> small perl script via cron every 5 minutes that uses snmp to query the
> appropriate NAS for each entry currently in the session database and
verify
> the session is still active. If the session has gone away, the entry is
> deleted from the session database. This way invalid entries will get
> removed even if a stop packet is lost between the NASs and the radius
> servers. Because we use database replication, the corrections need only be
> applied to one session database and they will propagate very quickly with
> no need for intervention or multiple queries.
>          This system has recovered flawlessly through several power
outages
> that brought our network down in a less graceful manner (yes, we do have
> UPSs in the system). When the servers come back up, the entries in the
> session databases are corrected within a few minutes.
>
> Regards,
> David Miller
>
>
> At 07:22 PM 1/2/03 +0100, you wrote:
>
> >Having the standard set-up with Prim/Sec Radiator server with a backend
with
> >Prim/Sec database let's suppose we would like to implement the port limit
> >check(per DNIS) by means of dedicated AuthByPortlimit or Simultaneous-use
> >check+Sessiondatabase
> >
> >My question is about performance and accuracy of the counters in case of
> >failure( I suppose only for the backend)
> >
> >
> >I can think of two scenarios
> >
> >1. When a database from the backend goes down then the other one takes
over.
> >The second one I suppose has "quite an old update" due to of any possible
> >replication mechanism. If this is the case then the port limit check is
not
> >quite accurate from now on. Question here is how we can synchronise the
> >database with the NAS(if the NAS type is not mentioned). Can we run a
> >command(from Radiator) in the middle of the night to interrogate all
NAS's
> >in order to have this synchronisation back?
> >
> >2. Setting two sessiondatabases one for the primary database and one for
the
> >secondary database but the drawback here could be the performance due to
two
> >extra queries(insert/delete) to the backend(maybe I am wrong)
> >
> >
> >Does anybody have an experience about this?What would be the best set-up
> >versus performance?
> >
> >Thanks in advance
> >
> >Kind Regards
> >
> >Marius Stefan
> >
> >
> >
>
>#**************************************************************************
*
> >#
> ># Dit e-mailbericht met eventuele attachments is uitsluitend bestemd voor
de
> ># geadresseerde(n) en bevat mogelijk vertrouwelijke gegevens en/of is
> ># beschermd door intellectuele eigendomsrechten. Bent u niet de
> ># geadresseerde, neemt u dan zo spoedig mogelijk contact op met de
afzender
> ># en verzoeken wij u het e-mailbericht en eventuele attachments van uw
> ># computer te verwijderen. Elk gebruik van de inhoud van dit
e-mailbericht
> ># en eventuele attachments (waaronder verveelvoudiging, verspreiding of
het
> ># anderzins openbaar maken in welke vorm dan ook) door andere personen
dan
> ># de bedoelde geadresseerden is verboden. De weergegeven mening is puur
> ># persoonlijk en hoeft niet noodzakelijk over een te komen met die van
> ># Enertel. Enertel is niet aansprakelijk voor de inhoud van dit
> ># e-mailbericht en eventuele attachments.
> >
> >
> >===
> >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.
>
> David Miller               |
> System Engineer            |    Linux User #37518
> Newport Internet           |
> dmiller at newportnet.com     |
> 541-265-3596               |
>
> ===
> 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.
>

===
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.