Messages

For me nothing helped but switching to e1000 AND change the ips algorithm to the new keen style variant.

Note: at least in my case, that only seems to work with 20.7.4 and nothing before


Gesendet von iPhone mit Tapatalk

@mb as far as I know it's suricata 4x vs suricata 5.x


Sent from iPhone via Tapatalk

Hi mb, as I wrote in #42 ithe results with nm bridge were better but there was still a huge difference compared to 20.1 WITH enabled ips.
In my oppionion the current kernel is definetely not performing as good as with 20.1 and as such the performance with enables ips is even worse.

Yes, ubench result is good, but overall performance is far away from 20.1. I know you and your team have put a huge amount of work into this but I think it's better to point out potential issues then having to deal with the complaints later on.

To be clear: you can definetely assume that the results mentioned here are not sourced from external factors like esx load, webserver load or something else. I can easily check this by just restoring both vmware snapshots back and forth - it MUST have something to do with 20.7 and/or the kernel. The results are strictly "following the problem atic version" and never appear with 20.1 (as said, performance with 20.1 and enabled ips is always a lot better then 20.7 with disabled ips, rest of the config is exactly the same)

Thanks again for your support and work.


Sent from iPhone via Tapatalk

did some more tests.
its slow if ips is enabled on "wan"
its fast if ips enabled on "lan"
How can that be? What am I missing here? Shouldnt the rules be processed in either scenario? Where does the difference in performance come from?

just for reference:

WRT IPS, I'd suspect from the configuration & rulesets if you were able to attain higher speeds on 20.1.

dont know how because the configuration and rulesets did NOT change.

So I should better go back to 20.1 as you can't reproduce that behavior on your site right?
ruleset is the same so that shouldn't be an issue


Sent from iPhone via Tapatalk

ok, I tested again. Simple http download with disabled suricata/sensei is fast at ~270mbit. If ips is off speeds are max, as soon as its enabled suricata is saturating one core with 100% and speed is capped at 120mbit.

So the reson is definetely something related to ips ...

thanks for your patience.
its much better but not as good as with 20.1 - now its fluctuating between 130 and 275mbps while 20.1 always peaked at 275 (max isp speed)

Hi mb,

Did that also, it's the first quote in my above post but there is no more output other than this.

// during run of nmbridge no traffic forwarding seems to work, ssh is still working though.
if I control+c traffic forwarding continues to work:

Code Select Expand

^C864.502603 main [331] poll timeout [0] ev 1 0 rx 0@42 tx 443, [1] ev 1 0 rx 0@69 tx 511


Sent from iPhone via Tapatalk

what would be the expected output?

Code Select Expand

618.451661 main [247] same interface, endpoint 0 goes to host
618.488299 nm_mmap [990] do not mmap, inherit from parent
618.488349 main [269] ------- zerocopy supported
618.488377 main [276] Wait 4 secs for link to come up...
622.499677 main [280] Ready to go, vmx1 0x1/1 <-> vmx1 0x0/1.

//
If I try to do it between vmx0 and vmx1:

Code Select Expand

./nmbridge -i netmap:vmx0 -i netmap:vmx1 the vm instantly becomes unresponsive and the esx console spams "vmx0 drop mbufs that needs checksum offload"

Hi @mb thanks for your fast response (as always!)

its an esxi 6.7 running on i5-5300U
https://ark.intel.com/content/www/de/de/ark/products/84862/intel-nuc-board-nuc5i5mybe.html

20.1 ubench

Code Select Expand

./ubench -cs
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
FreeBSD 11.2-RELEASE-p20-HBSD FreeBSD 11.2-RELEASE-p20-HBSD  07ef86ce9ca(stable/20.1) amd64
Ubench Single CPU:   420580 (0.40s)

20.7 ubench

Code Select Expand

./ubench -cs
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
FreeBSD 12.1-RELEASE-p9-HBSD FreeBSD 12.1-RELEASE-p9-HBSD  3b652d8ad0e(master) SMP amd64
Ubench Single CPU:   412479 (0.41s)

any thoughts?

Boot loops are fixed for me now however performance went down from 270mbps to 120mbps while using esxi with vmx.

Sensei is disabled, only using ips

Is this known to be an issue?


Sent from iPhone via Tapatalk

What am I missing?

Knowledge?

;D I would say that you need a block/reject rule for DNS ports to all destinations except 172.16.1.5

no, because its blocked by default.

@Xelas, you need a source nat rule too, otherwise your "routing" will be asynchronous. Just rewrite to the opnsense internal ip and you should be fine. You also need to take care that the actual dns (pihole) should still be able to access everything via udp/53

...Wait for kernel fixes....


Cheers,
Franco

Wow, you waited about 2 min for the kernel fixes. Maybe a little more patience? ;-)

I did not. I was asking for a potential test kernel which may already exist. I also asked for an eta if there is any which does not imply I'm unpatiently harassing someone for releasing a fix. It was no more than an informational question.

;)

thanks franco. is there a test kernel or something like that already available? when can we expect a fix?

No Sensei currently but ips is enabled


Sent from iPhone via Tapatalk