[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: dual-streaming interim accounting for high volume
From:       "Alan DeKok" <aland () nitros9 ! org>
Date:       2006-04-28 15:12:32
Message-ID: 20060428151232.9C46816E1E () mail ! nitros9 ! org
[Download RAW message or body]

"Tariq Rashid" <tariq.rashid@uk.easynet.net> 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
[prev in list] [next in list] [prev in thread] [next in thread]