"Tariq Rashid" <[EMAIL PROTECTED]> wrote: > under high load, we are familiar with the usual problem of dropped > accounting packets. this leads to retires and timeouts and possible > "marked dead", either by the NAS or intermediate radius proxies. > > this problem is particularly pronounced when a proxy used to sent > traffic to multiple home servers, one of which is > slow/unresponsive. this can lead to that proxy as being seen as > "dead" by many NASes.
Yes, it's a problem. > a solution would be to split the accounting radius flow, such that > the proxy or other freeradius server replies immediately with an > acknowledgement to the NAS, and then forwards the packet onto the > target home server, not necessariy waiting for a response. a more > intelligent approach may fast reply with cached replies such that > rejects can be effective. That's probably the best approach. > is this possible, or likely to be possible with freeradius? Yes. > i know about a mechanism which uses a second process to tail the > radius accounting log files, but this is fragile and prone to > inconsistencies. The problem is that if the packets are cached in memory, they're lost if the server goes down. They *have* to be written to disk. At that point, radrelay becomes the best bet. What is "fragile" or "inconsistent" about radrelay? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
