From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 34AA23B29D for ; Sat, 8 Feb 2020 18:17:53 -0500 (EST) Received: by mail-qv1-xf32.google.com with SMTP id dp13so1444571qvb.7 for ; Sat, 08 Feb 2020 15:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WScVnxCZL0VAquAdkLE7vh2GPaoOK2uLT5WVn0YdkHo=; b=E7SXEdDZqONFBCUcH4Mpey7S3Tvru8v/v3avxYCZX4sTfgJ3rnk4rQxm0dez1adWNd luCZBRxgmxt8wiRrja9ZreJ7ONAGyOPfByHgaX4HE+0SyyaaHM8b6ZlLllEu11PYIBy1 Lo2RH7mwD7GsdEN+g+qJwIzFTeQLedF3yqtwhWrITaovuA0S4Ppmuk1T6K7DZVQwRaHk /ysTuUOdfrdqcWxMTi2i5LqRLj9YQTSQBcDiPhsEEkQxBvsJ7YonWorE/9e5kNiLPx+e vQ3DEQ2jnnGxMP4dS2QmMDemGofrgW+jWOeElF9nVPxKJSYknNzfiqKnOF7ZLElSHaYT nvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WScVnxCZL0VAquAdkLE7vh2GPaoOK2uLT5WVn0YdkHo=; b=Nd4fUnwc8XJM1xbC3ZY61dqbgFe3ZK/qGQ57oy98EuYW362KCA5S3y+d6Vjyx22gV5 9CaqCXr5/wD7Vwu0XO8G2YCj2yUILBu4j40SUrkNzpwh2QuVK8iOvnNOJko5Vbs+RJZZ owKhR5CQhOieCntboPeHyiN2Fg9HjMtEx8PEENphpKO2CUPFtkPtK17NhxLkPjw5UBGT 9eUHyJa+5Fvgt0nRxaoLJLZ0N/Zm48E0BMKvBKG0HzLwbx4cTKUhLBj0qJf8uVNPbHTb 2XDae/PMsxcCk0rUyZ6ZTdNrP3XOuhDT4CN9AdpLrj/gcLZvCSUmBjnMD2Nil1+oRqKS Hhkw== X-Gm-Message-State: APjAAAVZoE5D9vOeUHit5cuT031b+tlkKqWjeKYjdNrqsAZOHOP4SGM9 pEon6RSGMe7NVUAVjYldWs0= X-Google-Smtp-Source: APXvYqzKxzdvTvc6q2GpxDnTF4kTQCuDJe1LSrQLdceKs4hXHVJYW1Fxe+CGh3VA6y0itk45daz6Lg== X-Received: by 2002:a05:6214:927:: with SMTP id dk7mr4492415qvb.200.1581203872742; Sat, 08 Feb 2020 15:17:52 -0800 (PST) Received: from richs-mbp-10337.lan ([64.223.173.60]) by smtp.gmail.com with ESMTPSA id d20sm3722538qto.2.2020.02.08.15.17.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Feb 2020 15:17:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Rich Brown In-Reply-To: <5B290AD9-1398-4897-97F0-1CA0AA48B522@gmail.com> Date: Sat, 8 Feb 2020 18:17:51 -0500 Cc: bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <8C2A342C-C2E7-4824-8689-60AA7E4AC30A@gmail.com> References: <073CE9AB-FE12-402E-BFE3-179DF7BF2093@gmail.com> <20200207130202.5fb87763@carbon> <5B290AD9-1398-4897-97F0-1CA0AA48B522@gmail.com> To: Jesper Dangaard Brouer , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3608.60.0.2.5) 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: Sat, 08 Feb 2020 23:17:53 -0000 Update: (I thought I had sent the previous message yesterday. My = mistake.) I now have atl3.richb-hanover.com running a netperf server. it's a stock = Ubuntu 18.04.4 LTS - uname -a shows: Linux atl3 4.15.0-76-generic = #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 = GNU/Linux. I have installed netperf 2.6.0, and little else. Next steps: 1) Please hammer on the server to see if it's a suitable replacement for = the canonical "netperf.bufferbloat.net". Please feel free to check both = its ability to handle traffic as well as any security surprises you = discover... 2) I welcome suggestions for configuring the server's TCP stack to be = most useful for researchers. fq_codel, bbr, - I'm open to your thoughts.=20= 3) It's not too soon for advice on an iptables strategy for limiting the = access/bandwidth/traffic to people who're abusing the service... Once we have all this in place, we can change the = netperf.bufferbloat.net name to point to this server. Thanks. Rich > On Feb 8, 2020, at 5:35 PM, Rich Brown = wrote: >=20 > Toke and Jesper, >=20 > Thanks both for these responses.=20 >=20 > netperf.bufferbloat.net is running an OpenVZ VPS with a 3.10 kernel. = Tech support at Ramnode tells me that I need to get to a KVM instance in = order to use ipset and other fancy kernel stuff. >=20 > Here's my plan: >=20 > 1) Unless anyone can recommend a better hosting service ... >=20 > 2) Over the weekend, I'll stand up a new KVM server at Ramnode. They = offer a 2GB RAM, 2 core, 65 GB SSD, with 3TB per month of data. It'll = cost $10/month: adding 2x1TB at $4/month brings it to a total of = $18/month, about what the current server costs. I can get Ubuntu 18.04 = LTS as a standard install. >=20 > 3) While that's in-flight I would request that an iptables expert on = the list recommend a better strategy. (I was just makin' stuff up in the = current setup - as you could tell :-) >=20 > 4) I'd also accept any thoughts about tc commands for setting up the = networking on the host to work best as a netperf server. (Maybe enable = fq_codel or better...)=20 >=20 > Thanks >=20 > Rich >=20 >> On Feb 7, 2020, at 7:02 AM, Jesper Dangaard Brouer = wrote: >>=20 >> On Thu, 6 Feb 2020 18:47:06 -0500 >> Rich Brown wrote: >>=20 >>>> On Feb 6, 2020, at 12:00 PM, Matt Taggart wrote: >>>>=20 >>>> This smells like a munin or smokeping plugin (or some other sort of=20= >>>> monitoring) gathering data for graphing. =20 >>>=20 >>> Yup. That is a real possibility. The question is what we do about = it. >>>=20 >>> If I understood, we left it at: >>>=20 >>> 1) Toke was going to look into some way to spread the >>> 'netperf.bufferbloat.net' load across several of our netperf = servers. >>>=20 >>> 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?=20 >>=20 >> Look at man iptables-extensions and find "connlimit" and "recent". >>=20 >>=20 >>> (If you're terminally curious, Line 5 of >>> = https://github.com/richb-hanover/netperfclean/blob/master/addtoblacklist.s= h >>> 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) >>=20 >> 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). >>=20 >> 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. >>=20 >> --=20 >> Best regards, >> Jesper Dangaard Brouer >> MSc.CS, Principal Kernel Engineer at Red Hat >> LinkedIn: http://www.linkedin.com/in/brouer >>=20 >=20