Hello Daniel -
My personal point of view is that this is unacceptable perfromance on the part of vendor A. Dropping radius accounting requests is bad enough, but the question to ask yourself is "what else are they dropping, and what sort of perfromance are your customers seeing?". I would be asking some hard questions and looking for some form of SLA (service level agreement).
Vendor B's suggestion is not a bad one, and some of our customers use this approach.
Note however that Radiator automatically removes all sessions for a NAS that is rebooted or restarted when it sees the initial accounting on request, assuming of course that you actually receive it.
regards
Hugh
On Saturday, Aug 9, 2003, at 04:52 Australia/Melbourne, Daniel Erat wrote:
Hello, we have two servers running Radiator 3.6-1. Since outsourcing our NASes in some locations to two vendors, we've been having problems with unterminated calls.
After examining packet dumps of the traffic from Vendor A, I've noticed
that they are often sending duplicate accounting-start packets to us,
with the second one coming 15 or 30 seconds after the first. They claim
that this is normal behavior, as their network drops "low-priority"
(their words) traffic (i.e. responses from our Radius servers) between
their Radius proxies and their NASes during periods of peak utilization.
The problem is, when one of our customers disconnects immediately after
the session starts, our Radius servers have already terminated the
session by the time that the retransmitted start packet comes in, so we
see it as beginning a new session (interestingly, the stop packets do
not seem to be retransmitted). Vendor A recommends that we work around
this by starting sessions based on the access-request packet, rather
than the accounting-start.
I haven't been able to examine any packet dumps from Vendor B, as our
customers use their phone numbers much less frequently, but they claim
that the problem is occurring because their sub-vendors' NAS servers are
sometimes rebooted or restarted, which causes all current sessions to be
abandoned. Vendor B recommends that we start examining the
Calling-Station-Id attributes that they are passing us and terminate any
ongoing sessions that match the phone numbers being used for
newly-started sessions.
So, my questions are
a) Based on others' experiences, are these explanations plausible/acceptable, or should we start looking for other vendors?
b) Has anyone tried either of the "solutions" recommended above? In particular, the one recommended by Vendor B sounds like a good workaround -- has anyone done this in Radiator?
Thanks in advance,
Dan === 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.
NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening?
-- 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.
