[Bloat] Can't Run Tests Against netperf.bufferbloat.net
Jesper Dangaard Brouer
brouer at redhat.com
Fri Feb 7 07:02:02 EST 2020
On Thu, 6 Feb 2020 18:47:06 -0500
Rich Brown <richb.hanover at 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
More information about the Bloat
mailing list