First of all thanks for your feedback David Some questions: -how often you do the backend replication? How often can the sessiondatabase be replicated? The point is -Let's suppose on the x replication time there are 100 ports in use(from 200) and close to the x+1 replication there are 200 ports in use but a failure is happening before the replication so the radius will check the secondary database and will still allow 100 extra connections! -the script identifies which database is prim or sec(basically the one that is leading)? By the way on which machine is running? -if I got it correctly the bellow mentioned cron basically is doing what the Simultaneous -use is doing when the port limit is almost reached(checking if the items that are shown in the session database are really set-up or not into the NAS).The only difference is that this task is performed every 5 minutes in your case. If this is the case does this regular check have any impact in a network with 100.000 ports(SNMPs all over) and above?
Regards -----Original Message----- From: David Miller [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 8:33 PM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] >To unsubscribe, email '[EMAIL PROTECTED]' with >'unsubscribe radiator' in the body of the message. David Miller | System Engineer | Linux User #37518 Newport Internet | [EMAIL PROTECTED] | 541-265-3596 | === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. #*************************************************************************** # # 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
