proxy.conf: no_response_fail
Hi, there is a scenario that might require "no_response_fail = yes". First, network breaks; power outage, spanking trees, something other but massive. Then clients start comming online, put some heavy load on backend server. Retry, retry, and - clients DoS backend. In that case I might want to send Access-Reject, to get some breathing space. I had one case much like this with a buggy BRAS a few years ago. And I was involved in another, where Access-Reject made things much worse, due to buggy IADs - once rejected, they reset to factory defaults:> So, although I can't really say I need this feature, I know of cases that make it usefull. Regards...
Josip Almasi <joe@vrspace.org> wrote:
there is a scenario that might require "no_response_fail = yes".
First, network breaks; power outage, spanking trees, something other but massive. Then clients start comming online, put some heavy load on backend server. Retry, retry, and - clients DoS backend. In that case I might want to send Access-Reject, to get some breathing space.
Easier and probably much more apprioate to use the OS's firewall to send backsome ICMP related grumbling (TCP RST if you happen to be using TCP) to pretend the port is closed/unavailable. ICMP in response to a UDP packet can get passed back to the application layer, rather than assuming a retry is required. Of course it depends on the OS's firewall, but in the case of iptables you can start doing rather cunning things like hashbuckets, recent and what not. Cheers -- Alexander Clouter .sigmonster says: Phone call for chucky-pooh.
Josip Almasi wrote:
there is a scenario that might require "no_response_fail = yes".
First, network breaks; power outage, spanking trees, something other but massive. Then clients start comming online, put some heavy load on backend server. Retry, retry, and - clients DoS backend. In that case I might want to send Access-Reject, to get some breathing space.
Or, set "max_outstanding" for the home servers. And set a "fallback" server in the "home_server_pool" section. That fallback server can reject the packets.
I had one case much like this with a buggy BRAS a few years ago. And I was involved in another, where Access-Reject made things much worse, due to buggy IADs - once rejected, they reset to factory defaults:>
So, although I can't really say I need this feature, I know of cases that make it usefull.
There are usually other ways to do the same thing. Alan DeKok.
Alan DeKok wrote:
Josip Almasi wrote:
there is a scenario that might require "no_response_fail = yes".
First, network breaks; power outage, spanking trees, something other but massive. Then clients start comming online, put some heavy load on backend server. Retry, retry, and - clients DoS backend. In that case I might want to send Access-Reject, to get some breathing space.
Or, set "max_outstanding" for the home servers. And set a "fallback" server in the "home_server_pool" section. That fallback server can reject the packets.
Ah, interesting, TY. OK then no_response_fail makes no sense any more. Regards...
participants (3)
-
Alan DeKok -
Alexander Clouter -
Josip Almasi