Re: 10g IPsec ?
Hi Andrey, For the moment we are not using hardware crypto offloading devices except AESNI instruction set mainly because our product are certified by common criteria and thus have restriction on how crypto can be made. We have some plan to look at intel quick-assist, chelsio or melanox devices in the future. Damien -- Damien Deville IPS Technical Leader http://www.stormshield.eu Stormshield 2/6 Avenue de l'Horizon, Bat. 6 - FR 59650 Villeneuve d'Ascq - Le 7 Nov 19, à 17:12, ae a...@freebsd.org a écrit : | On 07.11.2019 12:52, Damien DEVILLE wrote: |> At Stormshield we have various patches related to that topic that we |> can share. | | Hi, | | that would be nice. | |> The goal was to optimize this code in the context of a single IPsec |> tunnel and a single network flow in that tunnel. On one of our high |> end hardware (Intel(R) Xeon(R) E-2176G with 6 cores / ixl network |> cards), the previous code was running around 2.4Gbps using AES-GCM | | Have you thought about implementing hardware IPsec offloading on NICs? | I saw Intel's and Mellanox's documentation about such support, I think | Chelsio also does support it. It probably can give good performance boost. | | | -- | WBR, Andrey V. Elsukov ___ 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 ?
Hi, There are no limitation in term of interoperability with other IPsec stack. Funding is not needed as working on FreeBSD is part of my day time job. Available time is more the issue ;) Damien -- Damien Deville IPS Technical Leader http://www.stormshield.eu Stormshield 2/6 Avenue de l'Horizon, Bat. 6 - FR 59650 Villeneuve d'Ascq - Le 7 Nov 19, à 14:05, Santiago Martinez s...@codenetworks.net a écrit : | Super interesting, I'm also up for it, i guess i can help with some funding. | | Santi | | | On 2019-11-07 10:41, Kurt Jaeger wrote: |> Hi! |> |>> At Stormshield we have various patches related to that topic that we can share. |>> |>> On the flow id part, we have a patch that recompute a new flowid for the IPsec |>> flow after encapsulation based on the spi. |>> This force the usage of the same transmit queue on the network card side for |>> each tunnel/SPI. |>> |>> If you are interested i can make a review for this one to upstream it, it is a |>> small and simple modification. |> Yes, please. If you have the review, please add me to it. |> |>> On one of our high end hardware (Intel(R) Xeon(R) E-2176G with 6 cores / ixl |>> network cards), the previous code was running around 2.4Gbps using AES-GCM with |>> a mix of packet size whose average size was around 650 bytes. |>> After various heavy optimization in opencrypto/crypto.c and on IPsec stack we |>> managed to increase the performance on the same test to around 5Gbps. Take care |>> this is mainly targeted to the subset of opencrypto feature we are using in our |>> products (mainly IPsec with or without hardware cryptography) |>> |>> I can take some time to review and submit this big patch if there is some |>> interest in it. |> I would appreciate this -- would it help if my company pays some |> money for this to make it happen ? |> |>> It will require some work on our side cause at the moment this patch is for |>> FreeBSD 10.3 and has some depencies to our custom polling code which is not in |>> FreeBSD. We made the modification to work using kproc in the non polling code |>> but we have still to test those on an unmodified FreeBSD. |> Again, depending on the amount of work: it would definitly be interesting. |> |>> I can also share the various benchmark we did to illustrate the impact of some |>> of the optimisation we did. |> That would be very interesting. The final point would be: How |> interoperable is the resulting IPsec connect with non-FreeBSD |> counterparts 8-} ? ___ 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 ?
Super interesting, I'm also up for it, i guess i can help with some funding. Santi On 2019-11-07 10:41, Kurt Jaeger wrote: Hi! At Stormshield we have various patches related to that topic that we can share. On the flow id part, we have a patch that recompute a new flowid for the IPsec flow after encapsulation based on the spi. This force the usage of the same transmit queue on the network card side for each tunnel/SPI. If you are interested i can make a review for this one to upstream it, it is a small and simple modification. Yes, please. If you have the review, please add me to it. On one of our high end hardware (Intel(R) Xeon(R) E-2176G with 6 cores / ixl network cards), the previous code was running around 2.4Gbps using AES-GCM with a mix of packet size whose average size was around 650 bytes. After various heavy optimization in opencrypto/crypto.c and on IPsec stack we managed to increase the performance on the same test to around 5Gbps. Take care this is mainly targeted to the subset of opencrypto feature we are using in our products (mainly IPsec with or without hardware cryptography) I can take some time to review and submit this big patch if there is some interest in it. I would appreciate this -- would it help if my company pays some money for this to make it happen ? It will require some work on our side cause at the moment this patch is for FreeBSD 10.3 and has some depencies to our custom polling code which is not in FreeBSD. We made the modification to work using kproc in the non polling code but we have still to test those on an unmodified FreeBSD. Again, depending on the amount of work: it would definitly be interesting. I can also share the various benchmark we did to illustrate the impact of some of the optimisation we did. That would be very interesting. The final point would be: How interoperable is the resulting IPsec connect with non-FreeBSD counterparts 8-} ? ___ 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 ?
Hi! > At Stormshield we have various patches related to that topic that we can > share. > > On the flow id part, we have a patch that recompute a new flowid for the > IPsec flow after encapsulation based on the spi. > This force the usage of the same transmit queue on the network card side for > each tunnel/SPI. > > If you are interested i can make a review for this one to upstream it, it is > a small and simple modification. Yes, please. If you have the review, please add me to it. > On one of our high end hardware (Intel(R) Xeon(R) E-2176G with 6 cores / ixl > network cards), the previous code was running around 2.4Gbps using AES-GCM > with a mix of packet size whose average size was around 650 bytes. > After various heavy optimization in opencrypto/crypto.c and on IPsec stack we > managed to increase the performance on the same test to around 5Gbps. Take > care this is mainly targeted to the subset of opencrypto feature we are using > in our products (mainly IPsec with or without hardware cryptography) > > I can take some time to review and submit this big patch if there is some > interest in it. I would appreciate this -- would it help if my company pays some money for this to make it happen ? > It will require some work on our side cause at the moment this patch is for > FreeBSD 10.3 and has some depencies to our custom polling code which is not > in FreeBSD. We made the modification to work using kproc in the non polling > code but we have still to test those on an unmodified FreeBSD. Again, depending on the amount of work: it would definitly be interesting. > I can also share the various benchmark we did to illustrate the impact of > some of the optimisation we did. That would be very interesting. The final point would be: How interoperable is the resulting IPsec connect with non-FreeBSD counterparts 8-} ? -- p...@freebsd.org +49 171 3101372 One year to go ! ___ 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 ?
Hi freebsd-net, At Stormshield we have various patches related to that topic that we can share. On the flow id part, we have a patch that recompute a new flowid for the IPsec flow after encapsulation based on the spi. This force the usage of the same transmit queue on the network card side for each tunnel/SPI. If you are interested i can make a review for this one to upstream it, it is a small and simple modification. On the single tunnel optimisation we recently took some time to optimize some code we made earlier and commited to FreeBSD 11 https://github.com/freebsd/freebsd/commit/fbc9da5dbe50b72a335de7a27b6834fba8ee3cf0 + https://github.com/freebsd/freebsd/commit/c8b6f569add600b6ce341848bcc28a79fb5f273b The goal was to optimize this code in the context of a single IPsec tunnel and a single network flow in that tunnel. On one of our high end hardware (Intel(R) Xeon(R) E-2176G with 6 cores / ixl network cards), the previous code was running around 2.4Gbps using AES-GCM with a mix of packet size whose average size was around 650 bytes. After various heavy optimization in opencrypto/crypto.c and on IPsec stack we managed to increase the performance on the same test to around 5Gbps. Take care this is mainly targeted to the subset of opencrypto feature we are using in our products (mainly IPsec with or without hardware cryptography) I can take some time to review and submit this big patch if there is some interest in it. It will require some work on our side cause at the moment this patch is for FreeBSD 10.3 and has some depencies to our custom polling code which is not in FreeBSD. We made the modification to work using kproc in the non polling code but we have still to test those on an unmodified FreeBSD. I can also share the various benchmark we did to illustrate the impact of some of the optimisation we did. Damien -- Damien Deville IPS Technical Leader http://www.stormshield.eu Stormshield 2/6 Avenue de l'Horizon, Bat. 6 - FR 59650 Villeneuve d'Ascq - Le 7 Nov 19, à 8:48, Eugene Grosbein eu...@grosbein.net a écrit : | 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" ___ 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 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"
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"
Re: 10g IPsec ?
06.11.2019 5: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. Some speedup may be achieved switching from direct NETISR mode to deferred mode, so interrupt processing merely places traffic to the ISR queue. Several (net.isr.numthreads) other kernel threads will process incoming traffic later including bpf, IPSEC, filtering, routing lookups, NETGRAPH etc. ___ 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 ?
Olivier Cochard-Labb wrote this message on Tue, Nov 05, 2019 at 23:45 +0100: > 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. Can't the async crypto sysctl be used to help offload the crypto to other threads? if (V_async_crypto) crp->crp_flags |= CRYPTO_F_ASYNC | CRYPTO_F_ASYNC_KEEPORDER; But yes, I think the biggest limitation will be pushing all the data through a single queue... -- 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 ?
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? ___ 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 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. Regards, Olivier ___ 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 05.11.2019 um 20:15 schrieb John-Mark Gurney: Kurt Jaeger wrote this message on Mon, Nov 04, 2019 at 20:46 +0100: Has anyone experience with operating a highspeed IPsec connection up to 10gigabit/s between 2 FreeBSD hosts ? Is that speed achievable ? How much tuning is necessary ? I haven't, but do know some hints. Make sure that you have a machine w/ AESNI, AND make sure you're using AES-GCM or AES-CTR.. Using AES-GCM is best as it avoids using a costly auth algorithm, as the AESNI instructions provide instructionts to make the GCM (auth) part of AES-GCM faster. 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. 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/ Best, 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 ?
Kurt Jaeger wrote this message on Mon, Nov 04, 2019 at 20:46 +0100: > Has anyone experience with operating a highspeed IPsec connection > up to 10gigabit/s between 2 FreeBSD hosts ? > > Is that speed achievable ? How much tuning is necessary ? I haven't, but do know some hints. Make sure that you have a machine w/ AESNI, AND make sure you're using AES-GCM or AES-CTR.. Using AES-GCM is best as it avoids using a costly auth algorithm, as the AESNI instructions provide instructionts to make the GCM (auth) part of AES-GCM faster. 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. -- 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"
