Re: 10g IPsec ?
07.11.2019 14:32, John-Mark Gurney wrote: > Don't we have the option of doing soft re-classification? Where we > recalculate the hash, and then do a netisr defer? I mean that'd burn > a bunch of extra cpu cycles, but you gotta do what you gotta do. If the host got a packet already, it can just process it without extra re-classification. The only case I know when such re-classification can be useful is assigning M_FLOWID to the mbuf so that lagg(4) using LACP could send it further using such M_FLOWID and maybe distribute distinct IPsec flows over distinct ports of LAGG group. I doubt this has much practical use :-) Generally we terminate IPsec locally or route packets to other hosts without need to differ them from other transit traffic. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
Lawrence Stewart wrote this message on Thu, Nov 07, 2019 at 13:04 +1100: > On 7/11/19 12:52 pm, Eugene Grosbein wrote: > > 07.11.2019 8:36, Lawrence Stewart wrote: > > > AES-GCM can run at over 1GB/sec on a single core, so as long as the > traffic can be processed by multiple threads (via multiple queues > for example), it should be doable. > > > >>> I didn't bench this setup (10Gb/s IPSec) but I believe we will have the > >>> same problem with IPSec as with all VPN setups (like PPPoE or GRE): the > >>> IPSec tunnel will generate one IP flow preventing load sharing between all > >>> the NIC's RSS queues. > >>> I'm not aware of improvement to remove this limitation. > >> > >> I never understood why the IPsec SPI couldn't be used to shard > >> traffic... does anyone know if there is a technical reason why doing so > >> would be problematic? > > > > Generic way do distribute load over CPUs is distinct hardware receive > > queues of NIC > > using distinct interrupts to deliver packets to the host while interrupts > > are bound > > to distinct CPU cores. It needs hardware capable of splitting packet stream > > by IPsec SPI > > and I'm aware of only some 40Gpbs Intel NICs that can be programmed to do > > so. > > Right, a "consumers need to ask for it" issue more so than an inherently > problematic approach. I assumed as much but wasn't sure. Don't we have the option of doing soft re-classification? Where we recalculate the hash, and then do a netisr defer? I mean that'd burn a bunch of extra cpu cycles, but you gotta do what you gotta do. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
On 7/11/19 12:52 pm, Eugene Grosbein wrote: > 07.11.2019 8:36, Lawrence Stewart wrote: > AES-GCM can run at over 1GB/sec on a single core, so as long as the traffic can be processed by multiple threads (via multiple queues for example), it should be doable. >>> I didn't bench this setup (10Gb/s IPSec) but I believe we will have the >>> same problem with IPSec as with all VPN setups (like PPPoE or GRE): the >>> IPSec tunnel will generate one IP flow preventing load sharing between all >>> the NIC's RSS queues. >>> I'm not aware of improvement to remove this limitation. >> >> I never understood why the IPsec SPI couldn't be used to shard >> traffic... does anyone know if there is a technical reason why doing so >> would be problematic? > > Generic way do distribute load over CPUs is distinct hardware receive queues > of NIC > using distinct interrupts to deliver packets to the host while interrupts are > bound > to distinct CPU cores. It needs hardware capable of splitting packet stream > by IPsec SPI > and I'm aware of only some 40Gpbs Intel NICs that can be programmed to do so. Right, a "consumers need to ask for it" issue more so than an inherently problematic approach. I assumed as much but wasn't sure. Cheers Lawrence ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
07.11.2019 8:36, Lawrence Stewart wrote: >>> AES-GCM can run at over 1GB/sec on a single core, so as long as the >>> traffic can be processed by multiple threads (via multiple queues >>> for example), it should be doable. >>> >>> >> I didn't bench this setup (10Gb/s IPSec) but I believe we will have the >> same problem with IPSec as with all VPN setups (like PPPoE or GRE): the >> IPSec tunnel will generate one IP flow preventing load sharing between all >> the NIC's RSS queues. >> I'm not aware of improvement to remove this limitation. > > I never understood why the IPsec SPI couldn't be used to shard > traffic... does anyone know if there is a technical reason why doing so > would be problematic? Generic way do distribute load over CPUs is distinct hardware receive queues of NIC using distinct interrupts to deliver packets to the host while interrupts are bound to distinct CPU cores. It needs hardware capable of splitting packet stream by IPsec SPI and I'm aware of only some 40Gpbs Intel NICs that can be programmed to do so. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
On 6/11/19 9:45 am, Olivier Cochard-Labbé wrote: > On Tue, Nov 5, 2019 at 8:15 PM John-Mark Gurney wrote: > >> AES-GCM can run at over 1GB/sec on a single core, so as long as the >> traffic can be processed by multiple threads (via multiple queues >> for example), it should be doable. >> >> > I didn't bench this setup (10Gb/s IPSec) but I believe we will have the > same problem with IPSec as with all VPN setups (like PPPoE or GRE): the > IPSec tunnel will generate one IP flow preventing load sharing between all > the NIC's RSS queues. > I'm not aware of improvement to remove this limitation. I never understood why the IPsec SPI couldn't be used to shard traffic... does anyone know if there is a technical reason why doing so would be problematic? Cheers, Lawrence ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Jails with VIMAGE and VLANS.
Hi everyone, how you are doing well. During the last months, I have been working with JAIL and VIMAGE to perform some network test/validations. I have been facing the following weird behaviour that while it has been happening before, it used to be once in a while but now it is happening almost all the time. When a jail is stopped, it seems that the interface associated with it is not released/de-associated to the no longer existing jail. This makes the system (no jailed) not to see the interface (using netstat / ifconfig) however it cannot destroy it or create it again (as it already exists). Sometimes after a few minutes, the interface is "released" and it is visible again to ifconfig or netstat. Is anybody else having the same issues? Any hints on how to debug this? Best regards. Santiago Environment details: OS : FreeBSD 13.0-CURRENT (NEC) #70 r354360M net config : bxe1 with bxe1.70 and bxe1.80 Jail setup : IPERF_TEST_ZONE1 (bxe1.70) / IPERF_TEST_ZONE2 (bxe1.80) Trigger : start jails, move some traffic, stop jails. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 240135] Correctness issue in IPv6 extension headers input processing routines
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240135 Bjoern A. Zeeb changed: What|Removed |Added Status|New |Open Assignee|n...@freebsd.org |b...@freebsd.org --- Comment #1 from Bjoern A. Zeeb --- I think I have fixed this in a local tree as part of removing most of the PULLDOWN_TEST and IP6_EXTHDR* foo. I'll hopefully upload a clean patch for review later today and will point you at it. It's really helpful to have another pair of eyes on these things. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
Am 06.11.2019 um 13:03 schrieb Eugene Grosbein: 06.11.2019 18:29, Muenz, Michael wrote: Am 06.11.2019 um 01:21 schrieb Eugene Grosbein: 06.11.2019 4:55, Muenz, Michael wrote: These were my short results via OPNsense on 4 year old XEONs. So its 11.2, mostly untuned and strongswan as IPsec implementation. If you need more detailed specs just drop me a line. https://www.routerperformance.net/comparing-opnsense-vpn-performance/ Was it strongswan in user-level IPsec processing mode or kernel-level? Not really sure if I understand you right, encryption and ESP should run in kernel space, only IKE packets for SA handling run in user space. AFAIK strongswan may process all traffic in user-land via tun(4) interface for some setups. It differs from racoon that never processes payload by itself. I know that for route-based IPSEC strongswan creates a tun(4) interface, classic policy-based IPSEC is pushed via enc(4). Strongswan itself is not really clear about this and I never used racoon. Maybe Andrey Elsukov knows better. :) Michael ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
On 06/11/2019 01:45, Olivier Cochard-Labbé wrote: On Tue, Nov 5, 2019 at 8:15 PM John-Mark Gurney wrote: AES-GCM can run at over 1GB/sec on a single core, so as long as the traffic can be processed by multiple threads (via multiple queues for example), it should be doable. I didn't bench this setup (10Gb/s IPSec) but I believe we will have the same problem with IPSec as with all VPN setups (like PPPoE or GRE): the IPSec tunnel will generate one IP flow preventing load sharing between all the NIC's RSS queues. I'm not aware of improvement to remove this limitation. Is it possible to make load-sharing based on fmod(ipsec_seq_number / NUM_CPU_CORES) for example? -- CU, Victor Gamov ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
06.11.2019 18:29, Muenz, Michael wrote: > Am 06.11.2019 um 01:21 schrieb Eugene Grosbein: >> 06.11.2019 4:55, Muenz, Michael wrote: >> >>> These were my short results via OPNsense on 4 year old XEONs. >>> So its 11.2, mostly untuned and strongswan as IPsec implementation. >>> If you need more detailed specs just drop me a line. >>> >>> https://www.routerperformance.net/comparing-opnsense-vpn-performance/ >> Was it strongswan in user-level IPsec processing mode or kernel-level? >> > > Not really sure if I understand you right, encryption and ESP should run in > kernel space, only IKE packets for SA handling run in user space. AFAIK strongswan may process all traffic in user-land via tun(4) interface for some setups. It differs from racoon that never processes payload by itself. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10g IPsec ?
Am 06.11.2019 um 01:21 schrieb Eugene Grosbein: 06.11.2019 4:55, Muenz, Michael wrote: These were my short results via OPNsense on 4 year old XEONs. So its 11.2, mostly untuned and strongswan as IPsec implementation. If you need more detailed specs just drop me a line. https://www.routerperformance.net/comparing-opnsense-vpn-performance/ Was it strongswan in user-level IPsec processing mode or kernel-level? Not really sure if I understand you right, encryption and ESP should run in kernel space, only IKE packets for SA handling run in user space. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
