Nathan M wrote:
Thanks for the input. As previously mentioned, it's not what I would really consider a peak load issue, but more of a DOS from a mis-configured or poorly managed NAS, which is entirely outside of our control; however, we have to accept packets from it and have no ability to resolve whatever their problem may be.
That is distinctly anti-social behavior from whoever owns the NAS.
Rather than updating the systems to accommodate 6000 packets/second from this one NAS when it sends a spew of authentication requests, I'll share the solution I'm trying out in case anyone else winds up in a similar predicament. In all tests thus far, this shaves off the wild peak load and distributes it over a short period of time as the NAS I'm working with will retry frequently if the first attempt is dropped.
Another solution is to use RADIUS. :) Set up a proxy for ONLY that NAS. Call it "A". Have it proxy ALL packets to the local proxy you're already running, "B". This configuration should be very, very, small. You can strip out 99% of the normal server configuration. In the configuration for "A", set "max_outstanding" to a low value, like 100 or 200. See raddb/proxy.conf for details. Then, in the "post-proxy type Fail" section, set "do_not_respond". This configuration limits the proxy load to no more than the upstream can handle. It also throws away packets when it receives too many. It's a bit more work than iptables, but it's cross-platform, and guaranteed to work. Alan DeKok.