Subject: (usr-tc) Missing Radius records... was Billing Software

From: Mark Thornton <[email-masked]>
Date: Tue, 25 Jan 2000 22:28:50 +0000

There has been a fair amount of discussion about missing radius records,
specifically stop records as regards to concurrency control. I posted a
question about this a week or so back and didn't get a response. In my case
I have a single chassis that is prone to this problem, but the others are
not. Any ideas why?

Also, if getting the stop record is so unreliable how do those of you who do
hourly billing keep the system working? In our case the session is lost and
not billed for. I can live with that but it bothers me that it isn't
reliable.

Mark Thornton
San Marcos Internet, Inc.
512-393-5300

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 25 Jan 2000 22:37:34 +0000

Thus spake Mark Thornton
>There has been a fair amount of discussion about missing radius
>records, specifically stop records as regards to concurrency control. I
>posted a question about this a week or so back and didn't get a
>response. In my case I have a single chassis that is prone to this
>problem, but the others are not. Any ideas why?

>Also, if getting the stop record is so unreliable how do those of you
>who do hourly billing keep the system working? In our case the session
>is lost and not billed for. I can live with that but it bothers me that
>it isn't reliable.

Its not so much that the stop records are unreliable...the RADIUS
standard indicates that RADIUS accounting is resent, to ensure that it
gets through (unlike syslog which sends it once...if it doesn't get
through...so sorry).  The problem is really that if you have multiple
RADIUS servers for redundancy, the start may get sent to one and the
stop to the other, and its difficult to coordinate this between your
RADIUS servers.

Also its just the whole idea of forcing state on what's designed to be a
stateless protocol (RADIUS).
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mark Thornton <[email-masked]>
Date: Tue, 25 Jan 2000 22:47:05 +0000

I certainly agree with the point that accounting records shouldn't be used
alone for concurrency control. In my case I have a single radius server
(that may be the problem;) and am trying to figure out why only one chassis
has this problem. There have been so many great tips come out of this list
as I lurk in the shadows that I have taken advantage of, I was hoping
someone may have come across this problem.

Mark Thornton

----- Original Message -----
From: Jeff Mcadams <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 25, 2000 2:35 PM
Subject: Re: (usr-tc) Missing Radius records... was Billing Software

-

---

From: [email-masked]
Date: Wed, 26 Jan 2000 17:21:28 +0000

U>There has been a fair amount of discussion about missing radius
U>records, specifically stop records as regards to concurrency control.
U>I posted a question about this a week or so back and didn't get a
U>response. In my case I have a single chassis that is prone to this
U>problem, but the others are not. Any ideas why?

U>Also, if getting the stop record is so unreliable how do those of you
U>who do hourly billing keep the system working? In our case the session
U>is lost and not billed for. I can live with that but it bothers me
U>that it isn't reliable.

U>Mark Thornton
U>San Marcos Internet, Inc.
U>512-393-5300

Unfortunately it is a HiPerArc problem that crept in at a certain 
release of code.  3Com claims it has been fixed in the newer code but 
with the problems many folks have had, including myself, with the newer 
code, some folks are afraid to try it.  I plan to try another HiPerArc 
upgrade soon.

Jeff Binkley
ASA Network Computing

CMPQwk 1.42 9999

-

---

From: Mike Wronski <[email-masked]>
Date: Wed, 26 Jan 2000 17:40:45 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Jeff Binkley
|Sent: Wednesday, January 26, 2000 9:15 AM
|To: [email-masked]
|Subject: (usr-tc) (USR-TC) MISSING RADIUS R
|
|
|U>There has been a fair amount of discussion about missing radius
|U>records, specifically stop records as regards to concurrency control.
|U>I posted a question about this a week or so back and didn't get a
|U>response. In my case I have a single chassis that is prone to this
|U>problem, but the others are not. Any ideas why?
|
|U>Also, if getting the stop record is so unreliable how do those of you
|U>who do hourly billing keep the system working? In our case the session
|U>is lost and not billed for. I can live with that but it bothers me
|U>that it isn't reliable.
|
|U>Mark Thornton
|U>San Marcos Internet, Inc.
|U>512-393-5300
|
|
|Unfortunately it is a HiPerArc problem that crept in at a certain
|release of code.  3Com claims it has been fixed in the newer code but
|with the problems many folks have had, including myself, with the newer
|code, some folks are afraid to try it.  I plan to try another HiPerArc
|upgrade soon.
|

I am not aware of any missing stop records in current code. But in some
scenarios the card my discard accounting information. This scenario is a
heavily loaded chassis (90%+ capacity) that has lost connectivity to its
Accounting server.
The HARC will retransmit accounting packets forever. But there is only so
much memory available for buffering packets (based on available free memory
in your specific configuration it is dynamic). If the packet buffer fills
up, the HARC starts to discard the oldest packets to make room.  In this
scenario, there would be NO accounting packets sent for those sessions when
the server comes back up. Having backup servers should prevent this from
ever happening.

There is also another solution that provides very good results. The HARC
supports a feature called "interim accounting". This causes the HARC to send
accounting data throughout the session at a configured interval. This data
is updated with all current call stats, Bytes, timers, retrains etc. In a
scenario where the actual stop record is lost, you never are off by more
than your configured interval. Your concurrent session scheme needs to
realize that if it starts logging accounting for a different user on the
same port, the old user has disconnected and his counter should be
decremented. This gives the max time a user would be blocked by his
concurrent session counter at 2X configured accounting interval.

Before the flames start, this does require a Radius server support and
possibly relational DB backend. 3Com S&A does not support this but if your
looking to customize or have Radius customized, the Harc does provide enough
information from RADIUS accounting to get the job done.

-