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.