(RADIATOR) how to handle double accounting
Tony
tony at baytechnologies.tv
Thu Mar 13 07:29:21 CST 2003
Dear Mike,
Check firewall issues... at our company when we receive multiple times AAA
packets it's due to the fact that some firewall (near your radius server or
near your NAS if both are not local) is blocking the ACK packets.
Hope it helps...
Tony
-----Original Message-----
From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
Behalf Of Mike McCauley
Sent: 13 March 2003 11:56
To: radiator at open.com.au
Subject: (RADIATOR) how to handle double accounting
---------- Forwarded Message ----------
Subject: BOUNCE radiator at open.com.au: Non-member submission from ["Utku
Er"
<erutku at netone.net.tr>]
Date: Thu, 13 Mar 2003 03:06:45 -0600
From: owner-radiator at open.com.au
To: radiator-approval at open.com.au
>From mikem at server1.open.com.au Thu Mar 13 03:06:45 2003
Received: from gtdc01.netone.net.tr (n193-192-98-161.netone.com.tr
[193.192.98.161] (may be forged)) by server1.open.com.au (8.11.6/8.11.0)
with ESMTP id h2D96g817925
for <radiator at open.com.au>; Thu, 13 Mar 2003 03:06:44 -0600
Received: from erutku ([10.2.1.14]) by gtdc01.netone.net.tr with Microsoft
SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 11:05:47 +0200
Message-ID: <097701c2e941$82245380$0e01020a at erutku>
From: "Utku Er" <erutku at netone.net.tr>
To: <radiator at open.com.au>
Subject: how to handle double accounting
Date: Thu, 13 Mar 2003 11:18:28 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0974_01C2E952.45A27520"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 13 Mar 2003 09:05:47.0367 (UTC)
FILETIME=[BC732770:01C2E93F]
This is a multi-part message in MIME format.
------=_NextPart_000_0974_01C2E952.45A27520
Content-Type: text/plain;
charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable
Hello,=20
We have lots of double accounting coming from our NASes to Radiator. I =
know this is the normal procedure: NAS sends ACCT packet to radius. If =
NAS cannot get an ACK from radius it tries to resend the Accounting =
packet only altering the "Acct-Delay-Time". I do not know the reason why =
this is happening to me a lot.
When these ACCT packets gets to radius its written to acct database two =
or three times or even more. I have two questions:
1- can you image what may be the cause? I check: there is no packet loss =
or loss of connectivity between the radius and the nas.
2- how can you handle this when processing your accouting data. These =
account data have only timestamp and acct-delay-time different... The =
acctsessionid and the other fields are the same. When processing =
accounting, you cannot simply eliminate all the stop records from the =
acct database because different NASses (even a NAS) can send the same =
accounting session id in time...=20
any ideas?
Utku.
------=_NextPart_000_0974_01C2E952.45A27520
Content-Type: text/html;
charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-9">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We have lots of double accounting =
coming from our=20
NASes to Radiator. I know this is the normal procedure: NAS sends ACCT =
packet to=20
radius. If NAS cannot get an ACK from radius it tries to resend the =
Accounting packet only altering the "Acct-Delay-Time". I do not =
know the=20
reason why this is happening to me a lot.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>When these ACCT packets gets to =
radius its=20
written to acct database two or three times or even more. I have two=20
questions:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1- can you image what may be the cause? =
I check:=20
there is no packet loss or loss of connectivity between the radius and =
the=20
nas.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>2- how can you handle this when =
processing your=20
accouting data. These account data have only timestamp and=20
acct-delay-time different... The acctsessionid and the other =
fields=20
are the same. When processing accounting, you cannot simply =
eliminate all=20
the stop records from the acct database because different NASses (even a =
NAS)=20
can send the same accounting session id in time... </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>any ideas?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Utku.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0974_01C2E952.45A27520--
-------------------------------------------------------
--
Mike McCauley mikem at open.com.au
Open System Consultants Pty. Ltd Unix, 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, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS etc.
===
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.
More information about the radiator
mailing list