Re: [Bloat] Can't Run Tests Against netperf.bufferbloat.net

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Thu, 6 Feb 2020 18:47:06 -0500
Rich Brown <richb.hanover@gmail.com> 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