Hello Scott -
On Wednesday 13 June 2001 02:13, Scott Robinson wrote:
> Hi:
>
> We're currently experiencing a 30% to 50% loss of stop records. We have
> 45 NAS's (Cisco 5300's and Cisco 5800's) with three different telco's.
> We've determined that stop records are being lost on all 45 NAS's. We
> end up with a lot of orphaned records in our RADONLINE table as a result
> of the lost stop records.
>
> Our radius accounting server is on a separate machine with lots of
> horsepower (running > 80% idle). I've checked our logs (Trace level 4)
> and there are no errors in processing the stop records it does receive.
> Anybody know of anything I can check before I try bugging the telcos
> (Dealing with Canadian telco's makes the Middle East peace process look
> like a walk in the park). I know I can place a snooper to see if the
> packets are being received but we process +500,000 logins per day. If I
> am forced to go to the telcos, is there something I can specifically ask
> them to look for?
>
Well, there are at least three possibilities:
First, the stop packets are getting to the Radiator machine, but are not
being processed (unlikely, but this can sometimes happen with incorrect
configuration files). Easiest to check with a sniffer and compare it with a
trace from Radiator.
Second, the stop packets are being lost somewhere in transit. Again unlikely,
unless you are also losing similar numbers of logins and starts. The easiest
way to check is by doing test logins to your own phone numbers and verifying
that you get on first try and that the accounting is correct. Of course you
need to do this during busy periods when you can expect to have problems. And
note that saturated links are a very common cause of dropped packets,
especially as Radius is a UDP protocol.
Third, the stop packets are not being generated by the NAS equipement in the
first place. Sadly, NAS bugs are not uncommon, but it would be surprising if
all 3 of your providers had the same NAS bugs (but stranger things have
happened).
My suggestion would be to set up a test dialin programme to run every 15
minutes to a selected number of your telcos' POP's and produce sniffer output
and Radiator trace data that you can then check to see where the problems are.
Once you have some solid data, you can go to your providers with your
grievances supported by good documentation.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
