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 <[email protected]> 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 <[email protected]> wrote: >> >> On Thu, 6 Feb 2020 18:47:06 -0500 >> Rich Brown <[email protected]> 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 >> > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
