From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2AE6E3B29E for ; Fri, 7 Feb 2020 07:02:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581076943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5qPilQWA85nSAqcVHwr9rVzTZtzAKTo4LPmRGGCpWnw=; b=LinqSjsLWPVs5pktFt0OP0OjSP7ACwIsFIdsbaYGuTscBEHUltsGlymwjCo8ZJQy26Xy6c rtGjEzu4YdkjT8mDxloOxqDGPeSlRKihPbD3t7Mr1HaqwkKDQ6Px2iAtxvdu5UkSpbCm/O kticvuhnPsnOAd1TqZsp0/mrAJxcOjA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-373-oA7scWhcP8GpU_cGax9CQQ-1; Fri, 07 Feb 2020 07:02:09 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 813EC1857344; Fri, 7 Feb 2020 12:02:08 +0000 (UTC) Received: from carbon (ovpn-200-56.brq.redhat.com [10.40.200.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id 374B089F08; Fri, 7 Feb 2020 12:02:04 +0000 (UTC) Date: Fri, 7 Feb 2020 13:02:02 +0100 From: Jesper Dangaard Brouer To: Rich Brown Cc: brouer@redhat.com, bloat@lists.bufferbloat.net Message-ID: <20200207130202.5fb87763@carbon> In-Reply-To: <073CE9AB-FE12-402E-BFE3-179DF7BF2093@gmail.com> References: <073CE9AB-FE12-402E-BFE3-179DF7BF2093@gmail.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: oA7scWhcP8GpU_cGax9CQQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] Can't Run Tests Against netperf.bufferbloat.net X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 12:02:24 -0000 On Thu, 6 Feb 2020 18:47:06 -0500 Rich Brown 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