Date: Sun, 07 Apr 2019 14:35:43 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 237072] netgraph(4): performance issue? Message-ID: <bug-237072-7@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237072 Bug ID: 237072 Summary: netgraph(4): performance issue? Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: ler@FreeBSD.org >From my post to the #hardenedbsd IRC, but this *MAY* be a generic netgraph(= 4) perf issue. <ler> Hey all: I'm having a performance issue with netgraph(4) on OPNSense (based on HBSD-11.2).=20=20 <ler> I've got https://github.com/aus/pfatt loading / configuring netgraph(= 4), and a 1g/1g ATT Fiber link. <ler> with this setup, my Download side is ~600 meg. <ler> with my previous setup, a ubiquiti USG, I got ~900+ meg <ler> I'm currently using a https://protectli.com/product/fw4a/ as the fire= wall <ler> I also have a https://protectli.com/product/fw6b/ coming monday <ler> I'm using OPNSense's 19.1.4-netmap kernel, and have done some of the em(4) tuning from their IPS/IDS forum topic. <ler> The tuning DEFINITELY helped the UPLOAD side, but did nothing for the DOWNLOAD side. <ler> I'm looking for ideas on how to troubleshoot this. <ler> I'm more than happy to work with whoever, including making access available to the FW. <ler> the manufacturer (protectli.com) has run iperf tests on the raw hardw= are (without the netgraph(4) stuff in play) and gets ~940meg across it. <ler> (using OPNSense 19.1.4) <ler> so that's why I'm pointing the finger at netgraph(4). <ler> I see the same issue on a https://protectli.com/product/fw1/=20 <ler> Let me know what all you need/want, and I'll supply it. - {Day changed to April 7, 2019} <Ellenor> Can your installation be done without netgraph? <ler> No. Needs to be there to do the 802.1X dance with the ATT ONT. Read = the README at https://github.com/aus/pfatt for more details. <ler> And tag all the packets going to the ONT as VLAN0. <Ellenor> Ok. <Ellenor> l/ 45 <lattera> ler: for opnsense questions, #opnsense would be the right channel <ler> This is more a hardendbsd perf issue. <lattera> did you test in freebsd? <ler> No, as this is a FW issue, and I refuse to try pfSense. <ler> I have philosophical issues with them. <lattera> understood. but, to help me out, I'd prefer if you tested your se= tup with vanilla fbsd. hbsd's only changes to the networking stack were to use = ipv6 privacy extensions by default <ler> and ASLR <lattera> ASLR affects userland, not kernel, which is where the bulk of net= work performance occurs <lattera> https://github.com/HardenedBSD/hardenedBSD/wiki#generic-system-hardening <lattera> we do set net.inet.ip.random_id, too <lattera> so you could unset that to start with, I guess <ler> it's definitely netgraph(4) related, see the statement above re: protectli testing on the same HW/SW w/o netgraph(4), and getting expected p= erf. <ler> I doubt that random_id is affecting this, for that same reason. <lattera> agreed. can you file a bug report with us? https://github.com/HardenedBSD/hardenedBSD/issues <ler> sure. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237072-7>