Messages

151

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: September 11, 2021, 03:27:42 pm »

I also have an ix based card and it seems you're also having the same issue I'm having in regards to ip6 not having RSS enabled.  Not sure why this would be but it was enabled for me with the previous kernel version.

Good find, seems that the .2 kernel has changes for IPv6. Just took a look at my ixl output from the previous kernel, and compared to the .2 one ixl also lost IPv6 hybrid there.
So, it's gone for ix and ixl at least.

152

21.7 Legacy Series / Re: MyCircle parental controls -- arp spoofing

« on: September 11, 2021, 12:12:19 pm »

After factory reset of the device and the management app and repeating initial setup.  It gets as far as connecting the device to WIFI, and then the app can't find it, which has to happen before it can actually do anything.  The AP shows it connected, and DHCP is giving it an IP.  But the app can't find it.

A few things I would take a look at.
The FAQ says that you should not connect the device to WiFi but use a wired connection. This makes sense, because the speed of the kids internet will depend on the WiFi connection of the device then, and it will also generally take up WiFi airtime by pushing the kid's traffic back and forth again through WiFi, which you could avoid by connecting it wired.
If you are using a UniFi AP, make sure to turn off "High Performance Devices" in the SSID settings and Auto-Optimize Network (which would enable the aforementioned option). I guess the box might only do 2.4G, and if it was pushed to 5G erroneously, it would lose it's connection.
In general, an upgrade of your AP's firmware might have caused ARP spoofing to be handled differently, so you could also take a look there, if you depend on connecting the device to WiFi.

The problems reaching the MyCircle box after connecting it to WiFi could be caused by your phone living in the parent's IP network and not in the same network as the kids. Try to connect to the kid's SSID to see if the app is working then.

153

21.7 Legacy Series / Re: MyCircle parental controls -- arp spoofing

« on: September 11, 2021, 11:12:24 am »

What a load of hypocritical bs. 

It's very obvious that he is doing both and that he obviously put alot of effort in researching different solutions that fits his needs.

Tell me, why are you not using the social approach to "protect them from evil"?
And how well does your current solution work when they bring their devices away from home?

Well, malware has many faces. While I do tell them how to recognize malicious acts, it seems to be a good idea to also filter malicious content at firewall level.

Away from home, the ARP-based LAN solution depending on extra hardware is probably not going to work that fine either… but then again I seem to be into hypocritical bs, what do I know, right? 😉

Their gear is set up to also leverage the built in youth protection, so that might have some effect when they are away.

However, I am out of here now. Too much hostility against alternative opinions in this thread. Have a nice weekend anyways. 😊

154

21.7 Legacy Series / Re: MyCircle parental controls -- arp spoofing

« on: September 11, 2021, 09:47:57 am »

While OPNsense does have client traffic filtering it's not enough.  I tried Sensei and honestly it looks cool but I found it difficult to get detailed data whenever I had an issue (ex:  something being blocked that shouldn't be, or not being blocked) and it's just too limiting.

The home edition comes with a blocked session explorer and a live security events monitor, so debugging problems is quite easy there.

My approach differs from yours though, it is not to technically limit the kids time on something, but to protect them from evil. ATM, the classic approach that also worked OK for my TV time back when I was young, as in talking & agreeing with the kids upon times they can use their gear, seems to do well here so far for my 8 & 13 y/o. I might be forced to change my mind at some point but so far I still believe in the social approach vs. the technical one.

155

21.7 Legacy Series / Re: MyCircle parental controls -- arp spoofing

« on: September 10, 2021, 07:04:50 pm »

OPNsense already does child protection perfectly here, using Sensei. You can even pay for it (which I did because it’s worth it).

Unless there's something I don't understand, and that very well may be the case, Sensei is security and threat-prevention, which is great, and brings OPNsense up to part with the big commercial players.  But it's not parental controls.  I need to enforce off-time for specific users (which I can pre-define by MAC address), with an easy way to grant additional time.  I need to enforce basic content filters, again for specific users (so one kid can use facebook, but the other can't).  The Circle device accomplishes both of these and more, beautifully -- until it quit working 

Sensei has pretty fine grained application and web filters, including adult, proxy, DoH etc. Try it, it’s free.
If you really need scheduling, you can setup firewall rule scheduling on top.

156

21.7 Legacy Series / Re: MyCircle parental controls -- arp spoofing

« on: September 10, 2021, 06:45:43 pm »

Hi--

I have a Mycircle device.  It's a parental controls device -- it connects to WIFI, and then uses arp spoofing to "become" the default route so it can see who's talking to who.  Based on client MAC (which can be grouped up under profiles -- in our case per kid, so the teenager has different filters than the 9 year old), it can filter access to specific sites, or block all access, and it's controlled by a simple app.   ((as an aside, I absolutely hate this device -- I would love it if OPNsense did this, I'd even pay for it))  I have a separate "Kids" VLAN that has the Circle, the regular VLAN doesn't...

The device hasn't been working, and support is saying it isn't their fault, it must be the firewall preventing arp spoofing.  They say it's designed to work with a normal network, not an enterprise network (their words).

I haven't changed anything on the firewall in a long time, but I *HAVE* kept up on firmware updates.  In fact I just upgraded to 21.7.2.

My question is...  Did something change in the last, lets say, 6 months, that would affect this?  Is OPNsense now able to detect an arp spoofing / IP takeover, and somehow prevent it?  Can I disable that on a per interface basis?

Many thanks,

-msturtz-

OPNsense already does child protection perfectly here, using Sensei. You can even pay for it (which I did because it’s worth it).

157

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: September 10, 2021, 04:31:38 pm »

ix also seems to have support for RSS, passed through my other 10G card to OPNsense.

Code: [Select]

ix0: <Intel(R) X520 82599ES (SFI/SFP+)> port 0xf020-0xf03f mem 0xfd600000-0xfd67ffff,0xfd680000-0xfd683fff irq 10 at device 17.0 on pci0
ix0: Using 2048 TX descriptors and 2048 RX descriptors
ix0: Using 4 RX queues 4 TX queues
ix0: Using MSI-X interrupts with 5 vectors
ix0: allocated for 4 queues
ix0: allocated for 4 rx queues
ix0: Ethernet address: ***
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0: Error 2 setting up SR-IOV
ix0: netmap queues/slots: TX 4/2048, RX 4/2048

root@OPNsense:~ # sysctl -a | grep rss
net.inet.rss.bucket_mapping: 0:0 1:1 2:2 3:3 4:0 5:1 6:2 7:3
net.inet.rss.enabled: 1
net.inet.rss.debug: 0
net.inet.rss.basecpu: 0
net.inet.rss.buckets: 8
net.inet.rss.maxcpus: 64
net.inet.rss.ncpus: 4
net.inet.rss.maxbits: 7
net.inet.rss.mask: 7
net.inet.rss.bits: 3
net.inet.rss.hashalgo: 2
hw.bxe.udp_rss: 0
hw.ix.enable_rss: 1

root@OPNsense:~ # netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 direct          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6    256   flow  default   ---
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0     4        0      664        0     6779     7443
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     0        0        0        0        0        0
   0   0   arp        0     0      415        0        0        0      415
   0   0   ether      0     0     2429        0        0        0     2429
   0   0   ip6        0     1       39        0        0        6       45
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0     6        0      688        0     6492     7180
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     7        0        0        0      338      338
   1   1   arp        0     0      188        0        0        0      188
   1   1   ether      0     0     1955        0        0        0     1955
   1   1   ip6        0     2      114        0        0       31      145
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0     5        0     1341        0     2715     4056
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     0        0        0        0        0        0
   2   2   arp        0     0       73        0        0        0       73
   2   2   ether      0     0     4118        0        0        0     4118
   2   2   ip6        0     0      782        0        0        0      782
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0    16        0      353        0     4932     5285
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     0        0        0        0        0        0
   3   3   ether      0     0      568        0        0        0      568
   3   3   ip6        0     1       26        0        0        1       27
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0

158

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: September 08, 2021, 06:28:37 pm »

Disable after reboot works for me. I think this is the default also when nothing was specified.


Cheers,
Franco

Thanks, it seems I had to delete the tunable instead of setting it to 0. After a reboot it was gone.
But I think, even after removing all of the tunables & rebooting, my ixl network card still balances the connections. There are 4 very active if_io_tqg_* when iperf'ing -P8 through the firewall.

Code: [Select]

PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
  0 root        -76    -      0   656K CPU3     3   0:44  91.01% [kernel{if_io_tqg_3}]
  0 root        -76    -      0   656K CPU1     1   0:58  90.08% [kernel{if_io_tqg_1}]
  0 root        -76    -      0   656K -        2   0:51  82.79% [kernel{if_io_tqg_2}]
 11 root        155 ki31      0    64K RUN      0 268:36  72.36% [idle{idle: cpu0}]
 11 root        155 ki31      0    64K RUN      2 269:19  15.18% [idle{idle: cpu2}]
  0 root        -76    -      0   656K -        0   0:53  11.80% [kernel{if_io_tqg_0}]
 11 root        155 ki31      0    64K RUN      1 255:37   9.32% [idle{idle: cpu1}]
 11 root        155 ki31      0    64K RUN      3 269:09   6.96% [idle{idle: cpu3}]

159

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: September 08, 2021, 12:32:18 pm »

Thanks @tuto2!

Wanted to post my iperf3 results, but somehow I cannot compare with the stock kernel, no idea how to revert. Turning off RSS does not work, looks like this after a reboot:

Cannot turn it off anymore:

Code: [Select]

root@OPNsense:~ # cat /boot/loader.conf | grep rss
net.inet.rss.enabled="0"
root@OPNsense:~ # sysctl net.inet.rss.enabled
net.inet.rss.enabled: 1

160

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: September 08, 2021, 10:47:39 am »

Sure, kernel is

# opnsense-update -zkr 21.7.2-rss

Make sure to set net.inet.rss.enabled to "1" from System: Settings: Tunables and reboot. As mentioned the sysctl cannot be changed at runtime anymore.


Cheers,
Franco

Thanks, updated to that kernel and set dispatch to hybrid manually again (do I have to?)

Code: [Select]

root@OPNsense:~ # netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 direct          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6    256   flow  default   ---
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0     9        0     2531        0     1853     4384
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     0        0        0        0        0        0
   0   0   arp        0     0        2        0        0        0        2
   0   0   ether      0     0     3519        0        0        0     3519
   0   0   ip6        0     0      138        0        0        0      138
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0    11        0     4706        0     4646     9352
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     0        0        0        0        0        0
   1   1   arp        0     0        4        0        0        0        4
   1   1   ether      0     0     5731        0        0        0     5731
   1   1   ip6        0     0      146        0        0        0      146
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0     9        0     1794        0     5857     7651
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     5        0        0        0      153      153
   2   2   arp        0     0        0        0        0        0        0
   2   2   ether      0     0     2374        0        0        0     2374
   2   2   ip6        0     1      189        0        0        7      196
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0     6        0     2706        0     4659     7365
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     0      250        0        0        0      250
   3   3   ether      0     0     3526        0        0        0     3526
   3   3   ip6        0     1      137        0        0        3      140
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0

root@OPNsense:~ # sysctl -w net.isr.dispatch=hybrid
net.isr.dispatch: direct -> hybrid

root@OPNsense:~ # netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 hybrid          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6    256   flow  default   ---
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0     9        0     2797        0     5265     8062
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     0        0        0        0        0        0
   0   0   arp        0     0        3        0        0        0        3
   0   0   ether      0     0     4026        0        0        0     4026
   0   0   ip6        0     0      160        0        0        0      160
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0    11        0     5042        0     4827     9869
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     0        0        0        0        0        0
   1   1   arp        0     1        4        0        0        2        6
   1   1   ether      0     0     6351        0        0        0     6351
   1   1   ip6        0     0      170        1        0        0      171
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0     9        0     2109        0     8354    10463
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     5        0        0        0      164      164
   2   2   arp        0     0        0        0        0        0        0
   2   2   ether      0     0     2829        0        0        0     2829
   2   2   ip6        0     1      228        1        0       11      240
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0     6        0     3034        0     6392     9426
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     0      385        0        0        0      385
   3   3   ether      0     0     4073        0        0        0     4073
   3   3   ip6        0     1      145        0        0        3      148
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0

161

21.7 Legacy Series / Connectivity problem after switch update

« on: September 05, 2021, 11:45:28 am »

After I run a firmware update on my 10G switch, or simply reboot it, OPNsense gateway monitoring starts to fail frequently. I can reach the OPNsense box fine on LAN (ixl0, native) but the following problems seem to be responsible for gateway monitoring problems. Restarting the VM (passed through the Intel(R) Ethernet Controller X710 for 10GbE SFP+ controller with Proxmox) immediately fixes the problem.

Code: [Select]

Sep  5 11:18:17 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_DOWN'
Sep  5 11:18:19 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_DOWN'
Sep  5 11:18:19 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_DOWN'
Sep  5 11:18:20 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_DOWN'
Sep  5 11:18:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_UP'
Sep  5 11:20:08 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_UP'
Sep  5 11:20:41 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_UP'
Sep  5 11:20:59 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_UP'
Sep  5 11:21:21 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_DOWN'
Sep  5 11:21:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_DOWN'
Sep  5 11:21:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_DOWN'
Sep  5 11:21:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_DOWN'
Sep  5 11:21:23 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_UP'
Sep  5 11:22:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_UP'
Sep  5 11:22:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_UP'
Sep  5 11:22:22 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_UP'
Sep  5 11:22:50 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_DOWN'
Sep  5 11:22:51 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_DOWN'
Sep  5 11:22:51 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_DOWN'
Sep  5 11:22:51 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_DOWN'
Sep  5 11:22:52 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_UP'
Sep  5 11:23:56 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_UP'
Sep  5 11:23:57 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_UP'
Sep  5 11:23:57 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_UP'
Sep  5 11:24:25 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_DOWN'
Sep  5 11:24:26 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_DOWN'
Sep  5 11:24:26 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_DOWN'
Sep  5 11:24:27 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl1 type=LINK_UP'
Sep  5 11:25:14 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0 type=LINK_UP'
Sep  5 11:25:14 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan200 type=LINK_UP'
Sep  5 11:25:14 OPNsense.local-lan devd[93739]: Processing event '!system=IFNET subsystem=ixl0_vlan106 type=LINK_UP'

162

Zenarmor (Sensei) / Re: Deciso DEC840/850 Sensei throughput

« on: August 31, 2021, 08:40:19 am »

Hi @athurdent, we had an email exchange about this with the OPNsense team a while ago.

And it looks like the team is very close to getting RSS in the kernel

https://twitter.com/opnsense/status/1425402746602246150

After it hits one of the OPNsense releases, we'll go ahead and enable multi-core support for Sensei.

Hi @mb, that sound great! So if all works out, the "single core high performance CPU" limit should be lifted I guess and we can use multicore CPUs to gain more speed?

Here are my results, maybe you could take an educated look at those? I think it might be working OK but I am not sure... 
https://forum.opnsense.org/index.php?topic=24409.msg117836#msg117836

163

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: August 31, 2021, 08:33:45 am »

It should benefit Sensei in theory, but Sensei needs to support libnetmap API also, which will be added in version 21.7.2.

Great to hear this, thank you. 👍

In general, I am seeing those a lot of those when booting up, also see the attached screenshot. They were there before, but not that often I think.

Code: [Select]

ixl0: Failed to remove 0/1 filters, error I40E_AQ_RC_ENOENT
Here are my results:

Set the variables, installed the kernel and rebooted.

Code: [Select]

root@OPNsense:~ # netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 direct          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6    256    cpu   hybrid   C--
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0   366        0  3456666        0  1796298  5252964
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     0        0        0        0        0        0
   0   0   arp        0     0        1        0        0        0        1
   0   0   ether      0     0  7630456        0        0        0  7630456
   0   0   ip6        0     2        0      452        0      712     1164
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0   674        0  5662158        0   233572  5895730
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     4        0        0        0      212      212
   1   1   arp        0     0     3280        0        0        0     3280
   1   1   ether      0     0 13568727        0        0        0 13568727
   1   1   ip6        0     4        0     1108        0      649     1757
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0   538        0  3493297        0  2252147  5745444
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     0        0        0        0        0        0
   2   2   arp        0     0        2        0        0        0        2
   2   2   ether      0     0  8776535        0        0        0  8776535
   2   2   ip6        0     8        0     1538        0      987     2525
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0   870        0  4571265        0  1898993  6470258
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     0      943        0        0        0      943
   3   3   ether      0     0 10272150        0        0        0 10272150
   3   3   ip6        0     4        0      446        0      391      837
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0



sysctl -a | grep rss
net.inet.rss.bucket_mapping: 0:0 1:1 2:2 3:3 4:0 5:1 6:2 7:3
net.inet.rss.enabled: 1
net.inet.rss.debug: 0
net.inet.rss.basecpu: 0
net.inet.rss.buckets: 8
net.inet.rss.maxcpus: 64
net.inet.rss.ncpus: 4
net.inet.rss.maxbits: 7
net.inet.rss.mask: 7
net.inet.rss.bits: 3
net.inet.rss.hashalgo: 2
hw.bxe.udp_rss: 0
hw.ix.enable_rss: 1

sysctl -a | grep isr
net.route.netisr_maxqlen: 256
net.isr.numthreads: 4
net.isr.maxprot: 16
net.isr.defaultqlimit: 256
net.isr.maxqlimit: 10240
net.isr.bindthreads: 1
net.isr.maxthreads: 4
net.isr.dispatch: direct
I noticed that dispatch was still direct, so I set it and now it looks like this:

Code: [Select]

sysctl -w net.isr.dispatch=hybrid

sysctl -a | grep isr
net.route.netisr_maxqlen: 256
net.isr.numthreads: 4
net.isr.maxprot: 16
net.isr.defaultqlimit: 256
net.isr.maxqlimit: 10240
net.isr.bindthreads: 1
net.isr.maxthreads: 4
net.isr.dispatch: hybrid


root@OPNsense:~ # netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 hybrid          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6    256    cpu   hybrid   C--
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0   455        0  6256523        0  3911206 10167729
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     0        0        0        0        0        0
   0   0   arp        0     1        1        0        0       44       45
   0   0   ether      0     0 14655754        0        0        0 14655754
   0   0   ip6        0     2        0      575        0      923     1498
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0   936        0 10885857        0   366966 11252823
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     4        0        0        0      218      218
   1   1   arp        0     1     4332      670        0       42     5044
   1   1   ether      0     0 26865660        0        0        0 26865660
   1   1   ip6        0     4        0     1306        0      833     2139
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0   538        0  6589372        0  4728075 11317447
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     0        0        0        0        0        0
   2   2   arp        0     1        2        0        0        6        8
   2   2   ether      0     0 16633885        0        0        0 16633885
   2   2   ip6        0     8        0     2286        0     1388     3674
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0  1000        0  8687234       71  4575663 13262897
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     1     1403        0        0        5     1408
   3   3   ether      0     0 20808614        0        0        0 20808614
   3   3   ip6        0     4        0      848        0      479     1327
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0
Do I have to set it explicitly and is RSS working OK? Does not seem to make a difference, throughput with Sensei enabled is always the same (stock kernel and this kernel, dispatch policy direct or hybrid). As long as there is no speed degradation, everything should be fine I guess, as neither Sensei nor Suricata benefit from RSS ATM.

I am getting around 1.5 to 1.9G from my local librespeed instance that lives in my WAN transport net. Testing from LAN with a MacBook Pro and a 2.5G adapter. Blindtest in LAN shows 2.5G with that adapter, so everything is working like it should.

164

Zenarmor (Sensei) / Re: Deciso DEC840/850 Sensei throughput

« on: August 30, 2021, 06:43:19 pm »

10 Gbps throughput support does not require specialized hardware.

If your 10GbE adapter supports RSS (Receive Side Scaling) - and almost all 10GbE ethernets already do - you're good to go. Just make sure that your adapter is playing well with netmap.

Having said that, since default RSS configurations do not provide "symmetric" hashing, that is something we need to talk about with the OPNsense team. It's a relatively straightforward development, but still means a bit of deviation from the upstream kernel source.

Hi @mb, there is an RSS kernel to test now, will Sensei already benefit from that? I can test it and report back here, if you like. Got 2 ixl (Intel(R) Ethernet Controller X710 for 10GbE SFP+) connected to a 10G switch and can measure throughput locally.

165

23.7 Legacy Series / Re: [Tutorial/Call for Testing] Enabling Receive Side Scaling on OPNsense

« on: August 30, 2021, 06:37:02 pm »

Thanks for the nice explanation, tuto2!

This sounds cool, I can surely test this.
I have ixl nics for LAN and WAN (passed through to the OPNsense VM in Proxmox, recognized as Intel(R) Ethernet Controller X710 for 10GbE SFP+), connected to a 10G switch and an old i3 2 core / 4 threads CPU (Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz)
Over in the Sensei forum, mb mentioned that Sensei would also benefit from RSS when it comes to reaching 10G speeds.
As I am not using Suricata on the ixl interfaces, but I am using Sensei on LAN, will it also benefit?

Code: [Select]

root@OPNsense:~ # sysctl -a | grep rss
hw.bxe.udp_rss: 0
hw.ix.enable_rss: 1
root@OPNsense:~ # dmesg | grep vectors
ixl0: Using MSI-X interrupts with 5 vectors
ixl1: Using MSI-X interrupts with 5 vectors
ixl0: Using MSI-X interrupts with 5 vectors
ixl1: Using MSI-X interrupts with 5 vectors