On 15 Jan 2015, at 22:47, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 15/01/15 15:27, A.L.M.Buxey@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2