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

[Rich Brown]

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. 

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 <richb.hanover at gmail.com> wrote:
> 
> Toke and Jesper,
> 
> Thanks both for these responses. 
> 
> 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.
> 
> Here's my plan:
> 
> 1) Unless anyone can recommend a better hosting service ...
> 
> 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.
> 
> 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 :-)
> 
> 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...) 
> 
> Thanks
> 
> Rich
> 
>> On Feb 7, 2020, at 7:02 AM, Jesper Dangaard Brouer <brouer at redhat.com> wrote:
>> 
>> 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
>> 
>