General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Rich Brown <richb.hanover@gmail.com>
Cc: brouer@redhat.com, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Can't Run Tests Against netperf.bufferbloat.net
Date: Fri, 7 Feb 2020 13:02:02 +0100	[thread overview]
Message-ID: <20200207130202.5fb87763@carbon> (raw)
In-Reply-To: <073CE9AB-FE12-402E-BFE3-179DF7BF2093@gmail.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


  parent reply	other threads:[~2020-02-07 12:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.5.1581008402.30625.bloat@lists.bufferbloat.net>
2020-02-06 23:47 ` Rich Brown
2020-02-07 11:11   ` Toke Høiland-Jørgensen
2020-02-07 12:02   ` Jesper Dangaard Brouer [this message]
2020-02-08 22:35     ` Rich Brown
2020-02-08 23:17       ` Rich Brown
2020-02-09 16:31         ` Dave Taht
2020-02-09 19:08           ` Dave Taht
2020-02-05  2:18 Taran Lynn
2020-02-05  8:15 ` Toke Høiland-Jørgensen
2020-02-05 14:49   ` Rich Brown
2020-02-05 16:12     ` Toke Høiland-Jørgensen
2020-02-05 21:55     ` Matt Taggart
2020-02-05  8:57 ` Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200207130202.5fb87763@carbon \
    --to=brouer@redhat.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=richb.hanover@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox