Philip Molter wrote:
I did try that. It did not do what I was attempting to do.
Hmm... "it didn't work".
I am trying to patch with the algorithm I describe further on down. Freeradius can offer a robust transparent internal failover OR the existing failure handling. It is not an either/or scenario.
As I said, I'm open to suggestions.
I am not sure how you ever got the impression that the home server pool type has been set to anything but "load-balance". It has been set to "load-balance" since the very beginning.
I've been reading your messages. It has *not* been clear that the pool type was set to "load-balance".
One way of accomplishing this (an algorithm as you have requested) is to realize that when the NAS does not get back a response, it will (if configured) retransmit the original request. When the proxy does not get back a response from the home server it chose (after whatever length of time), it can fail out the home server, not send any response back to the NAS, forget that it ever saw the original request from the NAS, and when the NAS retransmits its request, the proxy will see it as a new original request, choose a new home server (the previous one has been failed out), and then hopefully the proxy will get a response from this new home server that it will pass back to the NAS.
That's a good idea, but not really possible as-is.
This requires relatively quick fail out of home servers, something which can already be configured. It requires that the tracking hash of the original request packet and proxy be cleared.
I'm not so sure. For one, deleting the original tracking has is not an option. It's also not necessary. See the existing code for how requests can fail-over from one home server to another *without* a problem. The code already supports this.
Both of these can be enabled via an option, probably at the pool level, so that it does not change the behavior for existing configs, but adds this capability for people who want this kind of transparent failover. However, I think the cleanest way to implement is to add a new Response-Packet-Type of (suggestion) 'Proxy-Clear-Response' that is treated like the above for proxied requests and is treated as 'Do-Not-Respond' if not used within the a post-proxy failure handler.
I'm not sure that's necessary.
Does that seem like a method that can work. Again, not to replace anything but to supplement it?
It's an *additional* method, rather than a *better* method. It requires additional code, additional state machine checks, and as such... I'm biased against it. It's just too much like a site-specific hack for it to be integrated into the main distribution. Adding a *better* method is the preferred approach. It's OK to change existing behavior, so long as it's for the better.
Many NASes can use an internal user cache as a backup to a non-responding or slowly-responding RADIUS server. If the proxy returns a an actual Access-Reject, the NAS accepts that and says the request is invalid. If the proxy returns nothing, the NAS can say, "Well, my RADIUS server is down, but I have this record for the same user/pass in my cache and previously, it received an Access-Accept. Let me accept this request." That does not break any RADIUS specifications I know of,
Nonsense. NASes that cache authentication credentials are *completely* outside of the RADIUS specification. It's like adding a jet engine to a car. There's no law *preventing* it, so it must be legal, right?
I hope my description above of the proxy forgetting the original request when it fails out a home server is an example of a different algorithm.
It's simple, and it can't work. Re-processing duplicate packets from scratch is simply not an option. Please explain *why* the suggested patch I had doesn't work. What does it do? How does it behave differently than what you expect?
Please tell me if the example I gave above is a good HOW. I am trying to come up with a code-based solution today, but I am not nearly as familiar with the code as you probably are.
The code can be safely ignored. The algorithm depends on only a few pieces of information: proxy home server various timeouts NAS retransmits If you can describe an algorithm based on that information, it can be implemented. Alan DeKok.