post-proxy and detecting dead upstream realms

Arran Cudbard-Bell a.cudbardb at freeradius.org
Fri Jan 16 00:41:49 CET 2015


> On 15 Jan 2015, at 22:47, Phil Mayers <p.mayers at IMPERIAL.AC.UK> wrote:
> 
> On 15/01/15 15:27, A.L.M.Buxey at lboro.ac.uk wrote:
>> Hi,
>> 
>>> "Real" cause of this message are something to worry about. In
>>> particular, on some current equipment (cough Cisco cough) those
>>> messages might indicate you're very close to the "offered load of
>> 
>> thats the main issue. at least on the new releases they have a seperate
>> 255 for the accounting datagrams.... I dont see why they dont use a different
>> NAS-Port for each access point on the controller...that would be a nice simple
>> solution
> 
> NAS-Port? How would changing the RADIUS attribute help, surely the packet IDs would still be limited to 255?
> 
> Really they just need to open new UDP sockets when they've exhausted IDs. It's not rocket science... ;o)
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Configure rlm_cache with a key matching realm:

Set cache TTL to be the length of time you want a realm to be blacklisted (+ timeout).

In Pre-Proxy:
	If there's no existing entry, create one with a date attribute set to the current time.
	If there's an existing entry, merge it, check date attribute, if now() - date > proxy timeout
	respond locally, assume realm is blacklisted.

In Post-Proxy:
	Assuming proxy was successful - expire cache entry.

When request goes out, an entry is created, it's removed on expiry or when a valid response is received.
If it hasn't been removed within the timeout then we know the proxy server didn't respond.

You can do more complex versions, where you maintain a counter using another rlm_cache instance, but
the above mechanism at least gives you a simple (and fairly clean) way of detecting when timeouts have 
occurred.

If you want to share state between a cluster of server you could use the memcached cache backend.

If you want persistence, feel free to write another backend for rlm_cache. I was thinking an 
rlm_cache_file backend might be nice, which would do something very similar to the session resumption
code in rlm_eap.

There's an internal API in rlm_cache now, and there's the 'exfile' (we need more punny names in the
server) API Alan wrote to manage exclusive access to files.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2



More information about the Freeradius-Users mailing list