|-----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.