On Thu, 6 Feb 2020 18:47:06 -0500 Rich Brown <[email protected]> wrote:
> > On Feb 6, 2020, at 12:00 PM, Matt Taggart wrote: > > > > This smells like a munin or smokeping plugin (or some other sort of > > monitoring) gathering data for graphing. > > Yup. That is a real possibility. The question is what we do about it. > > If I understood, we left it at: > > 1) Toke was going to look into some way to spread the > 'netperf.bufferbloat.net' load across several of our netperf servers. > > 2) Can someone give me advice about iptables/tc/? to identify IP > addresses that make "too many" connections and either shut them off > or dial their bandwidth back to a 3 or 5 kbps? Look at man iptables-extensions and find "connlimit" and "recent". > (If you're terminally curious, Line 5 of > https://github.com/richb-hanover/netperfclean/blob/master/addtoblacklist.sh > shows the current iptables command to drop connections from "heavy > users" identified in the findunfilteredips.sh script. You can read > the current iptables rules at: > https://github.com/richb-hanover/netperfclean/blob/master/iptables.txt) Sorry but this is a wrong approach. Creating an iptables rule per source IP-address, will (as you also demonstrate) give you a VERY long list of rules (which is evaluated sequentially by the kernel). This should instead be solved by using an ipset (howto a match from iptables see man iptables-extensions(8) and "set"). And use the cmdline tool ipset to add and remove entries. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
