On Thu, 18 Feb 1999, Mike McCauley wrote:
> Was it auth or accounting requests, or both?
These are just auth requests. Accounting requests go to a different
server, and we see virtually no duplicates there.
> 1. A short lived blockage in your network (router reboot?) that causes
> some of the Radius replies to get lost, NAS then retransmits and
> radius server ignores the duplicate. This could only affect auth
> requests.
Always a possibility, but I'd like to think our network is reasonably
healthy. :) I'll be sure to look at some throughput stats next time I
see a burst.
> 2. If DupInterval is set too long, you might see the identifiers
> wrapping at times of peak usage. Try setting DupInterval to say, 30 or
> less.
That may very well be the case. I've noticed that the majority of the
duplicates come from our Portmaster 4, which has something like 24 PRIs
plugged into it. It's definitely sending *lots* of RADIUS requests during
peak hours.
I'll decrease that interval and see what happens.
> You wont see those attributes in an accounting Start, or possibly with
> a shell or exec session (depending on your NAS)
These are only the stop packets generating the errors, and we've got only
about three accounts that are shell or exec sessions, and they're almost
never used.
> ON the other hand, if its jyst randomly omitting some of those
> variables, I would look to the NAS software.
That was my initial thought as well, but we're seeing these errors from
both our Ascend Maxen and our PM4. Both platforms certainly have more
than their fair share of bugs, but I'd be kinda surprised to see the exact
same problem pop up from both of them.
> Perhaps if you run Radiator at trace level 4 for a while, you might be
> able to get a packet dump of one of these offending packets, then we
> can see if there are any clues in the other attributes?
I'll do that.
> You dont say what database you are using, but mysql for example allows
> you to have if() clauses in your select so that the select statment
> could detect the empty string and replace it with NULL, or 0 or
> something.
That's a good idea, at least as a band-aid of sorts. The SQL DB is
Oracle 7, which I strongly suspect can do what you're describing (at the
price, it better!). I don't claim to be an SQL guru, so I really don't
know, but I'll do some digging.
> Hope that helps.
Definitely got me on the right track. :)
-Andrew
--
Andrew O. Smith - <[EMAIL PROTECTED]>
Sysadmin, Insync Internet Services
Houston, Texas, USA
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
