Antwort: RE: (RADIATOR) Duplicate Accounting Entries
Cisco AS5200 [EMAIL PROTECTED] (Arturo Pina) am 03/30/99 07:09:10 PM Bitte antworten an [EMAIL PROTECTED] (Arturo Pina) An: [EMAIL PROTECTED] (Christian Brem) Kopie:[EMAIL PROTECTED] (Blindkopie: Christian Brem/DEBIS/EDVG/AT) Thema:RE: (RADIATOR) Duplicate Accounting Entries -BEGIN PGP SIGNED MESSAGE- Just out of curiosity, what make of NAS are you using? On 30-Mar-99 Christian Brem wrote: Hi! Consider the following scenario: Client sends accounting request, radius processes it (inserts record into database), then ACKs it. This ACK is lost in time and space. Client times out, and sends its accounting request again. Radius tries to insert it into database -- and fails miserably because of uniqueness constraints, since this record has already been stored. Client now either gets a NAK or a timeout, and retries again... I have seen clients trying as much as five times to get rid of their accounting record... Is there a possibility of saying "when this SQL-error occurs, treat it as success"? thanx for help, Christian Brem - debis Systemhaus EDVg Internet Services Hofmühlgasse 3 - 5, 1060 Wien Tel.: +43 1 599 07 / 1749 Fax: +43 1 599 07 / 1199 Email: [EMAIL PROTECTED] WWW: http://www.debis.at To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. - --- Arturo Pina - [EMAIL PROTECTED] CTV Internet [http://www.ctv.es/] +34 902 444557 -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBNwEFNd+A5jTOp/8tAQGh1gQAhxF7wGAfwJgHs9VPjLi9lnmOVz1ccUyt UN4u6BwQ/pNXYqAADxVAIcYzTFjWqFKfcVn3quNgX1qIpsWBc4+ZSwAtfmI5TyGl 2vTaP6pS21k34SffaCssnw9EKqvCDUKvlfSYS28Qj76ryItnYRc0qOMeQVaE97ZW xkKlqlI/TCQ= =61VB -END PGP SIGNATURE- === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Antwort: Re: (RADIATOR) Duplicate Accounting Entries
-- Weitergeleitet von Christian Brem/DEBIS/EDVG/AT on 04/01/99 06:54 PM --- Martin Laubach 04/01/99 01:37 PM An: Christian Brem/DEBIS/EDVG/AT@EDVG Kopie: Thema:Antwort: Re: (RADIATOR) Duplicate Accounting Entries (Document link not converted) | Hmmm, I cant see that Radiator will NAK or ignore just because an accounting | insertion failed. Are you sure thats whats happening? No, not really. I have another theory though... At times this happens, the database machine was rather busy. So busy as queries taking 10 secs or more. Can it happen, that the NAS sends an Accounting-Request, Radiator tries to insert it into the database and hangs there for some time -- in the meantime, the NAS times out and retransmits the request, and again, and again. Finally, the query returns, and now Radiator will diligently insert those queued accounting records too... This is what I see in the database: : SQL select acctstatustype, time_stamp, acctsessionid, acctdelaytime :from radacct where acctsessionid = '00026205' order by time_stamp; : : ACCTSTATUS TIME_STAMP ACCTSESSIO ACCTDELAYTIME : -- -- -- - : Start 922376419 00026205 0 : Stop922376435 00026205 20 : Stop922376440 00026205 0 : Stop922376447 00026205 5 : Stop922376450 00026205 10 (Notice the rather peculiar ordering) Might that theory explain the phenomenum? If so -- perhaps something like AcctDupInterval may be a possibility? Throw away all accounting requests that have the same NAS-Session-Id from the same NAS within a configurable period (say 60 seconds or so?). mjl === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: Antwort: Re: (RADIATOR) Duplicate Accounting Entries
Hi Christian, On Apr 1, 6:51pm, Christian Brem wrote: Subject: Antwort: Re: (RADIATOR) Duplicate Accounting Entries -- Weitergeleitet von Christian Brem/DEBIS/EDVG/AT on 04/01/99 06:54 PM --- Martin Laubach 04/01/99 01:37 PM An: Christian Brem/DEBIS/EDVG/AT@EDVG Kopie: Thema:Antwort: Re: (RADIATOR) Duplicate Accounting Entries (Document link not converted) | Hmmm, I cant see that Radiator will NAK or ignore just because an accounting | insertion failed. Are you sure thats whats happening? No, not really. I have another theory though... At times this happens, the database machine was rather busy. So busy as queries taking 10 secs or more. Can it happen, that the NAS sends an Accounting-Request, Radiator tries to insert it into the database and hangs there for some time -- in the meantime, the NAS times out and retransmits the request, and again, and again. Finally, the query returns, and now Radiator will diligently insert those queued accounting records too... Yes, that seems more likely. If so, it might be worth looking at your accounting table. You might need to tune the indexes so that the inserts happen more quickly? This is what I see in the database: : SQL select acctstatustype, time_stamp, acctsessionid, acctdelaytime :from radacct where acctsessionid = '00026205' order by time_stamp; : : ACCTSTATUS TIME_STAMP ACCTSESSIO ACCTDELAYTIME : -- -- -- - : Start 922376419 00026205 0 : Stop922376435 00026205 20 : Stop922376440 00026205 0 : Stop922376447 00026205 5 : Stop922376450 00026205 10 (Notice the rather peculiar ordering) Might that theory explain the phenomenum? Yes, I think so. If so -- perhaps something like AcctDupInterval may be a possibility? Throw away all accounting requests that have the same NAS-Session-Id from the same NAS within a configurable period (say 60 seconds or so?). yes, this has been suggested before, but its difficult. I think we will have to escalate this in the priority. Cheers. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, external, etc etc on Unix, Win95/8, NT, Rhapsody === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
