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 San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- From: Jeff Mcadams <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Tuesday, January 25, 2000 2:35 PM Subject: Re: (usr-tc) Missing Radius records... was Billing Software

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley |Sent: Wednesday, January 26, 2000 9:15 AM |To: USR-TC@lists.xmission.com |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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.