(RADIATOR) Port limit accuracy

[Hugh Irvine]

Hello Marius -

Both failure modes that you describe are possible, however there is a  
more serious failure mode that you also have to consider and that is  
missing radius accounting requests. Because radius is based on UDP with  
a very simple timeout/retry mechanism, radius packets can and do go  
missing from time to time. This also causes inaccurate session  
database(s) of course, and unfortunately there is no easy solution.

In general I recommend a single session database running on a suitable  
high-availablility platform, possibly together with some form of cron  
job to go around and synchronise the session database with the real  
active sessions on the NAS equipment (this is not supported by Radiator  
directly due to performance considerations).

You should also be aware that Radiator does try to be self-healing as  
much as possible, by doing a preventative delete for any new session  
that comes up (using the NAS/NAS-Port combination), and also doing a  
complete delete for all sessions for a particular NAS if a reboot for  
that NAS is detected.

Also note that if you specify the NasType parameter for your Client  
clause(s), then Radiator will enforce strict session limit checking by  
verifying active sessions for a particular user if an exception for  
that user is detected.

Hope that helps.

regards

Hugh


On Friday, Jan 3, 2003, at 05:22 Australia/Melbourne,  
MStefan at enertel.nl 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.
>
>

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