Community discussions

MikroTik App
 
vanikcz
newbie
Topic Author
Posts: 36
Joined: Wed Oct 14, 2015 11:06 pm

Optimal settings for IPSec hardware offload

Fri Jan 14, 2022 6:07 pm

Dear forum visitor!
can you please advise me on optimal settings for IPSec hardware offloading on devices such as RBM33G or RB750Gr3 according to this table?
https://wiki.mikrotik.com/wiki/Manual:I ... celeration

Can the settings look like this or there is place for optimalisation?
In the Installed SA tab, there is th H flag present.
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=AcceleratedProfile
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=AcceleratedProposal pfs-group=modp2048
Best Regards, Jan
 
tdw
Forum Guru
Forum Guru
Posts: 1843
Joined: Sat May 05, 2018 11:55 am

Re: Optimal settings for IPSec hardware offload

Fri Jan 14, 2022 6:37 pm

AES-128 is sufficiently secure for most applications which would increase performance compared to AES-256 - the Mikrotik test results indicate 472.6Mbps compared to 359.5Mbps for 1400byte payloads.

The Diffie-Hellman calculations are always carried out in software but only occur during initial key exchange and subsequent rekeying intervals (set by the profile and proposal lifetime= setting). Less bits is faster, the minimum currently considered to be secure is 2048.

Another factor in performance is if the encrypted packet is too large to be transmitted in its entirety and has to be fragmented, see viewtopic.php?p=881409#p881409
 
vanikcz
newbie
Topic Author
Posts: 36
Joined: Wed Oct 14, 2015 11:06 pm

Re: Optimal settings for IPSec hardware offload

Sat Jan 15, 2022 1:08 am

Dear tdw,
thank you for comment on MTU, it seems to bring stability to tunnel. Before changing MSS it was running at speed oscilating from 0,5 to 20 mbps. After change MSS, tunnel is running on 60-70mbps.
It is on 100mbps line running solidly at speed of 95mbps. So it can be better but result is fair enough.

Best regards, Jan
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: Optimal settings for IPSec hardware offload

Sat Jan 15, 2022 10:28 am

@vanikcz, how did you test the tunnel speed? There are actually two effects of fragmentation.

One is systematic and foreseeable - doubling the rate of "packets" (actually, fragments) to be transported and slightly increasing the bit rate as Ethernet & IP headers for the fragments have to be added. This effect alone should just reduce the throughput smoothly.

The other one can only be seen on some network paths that drop the 2nd fragments, which effectively causes the complete packets to be lost as they cannot be reassembled. And if this happens, throughput testing using Mikrotik /tool bandwidth-test shows variable throughput similar to what you describe, but if you sniff what actually happens, you find out that some TCP sessions stall completely and get replaced by new ones. Whether real TCP sessions, i.e. not those created by bandwidth-test in multi-session mode, succeed depends on whether all fragments are dropped or only part of them, and on how the TCP stacks of the enpoints deal with packet loss and retransmission.

Also worth noting - fragmentation does not increase the amount of IPsec calculations per payload packet, because what gets fragmented are the resulting (transport) packets, not the payload ones.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1275
Joined: Tue Jun 23, 2015 2:35 pm

Re: Optimal settings for IPSec hardware offload

Sat Jan 15, 2022 11:57 am

@sindy
Would we be able to get better performance for the IPsec if we are using CPE for specific user (IRQ).
ATM other users are on auto,but im planning to assign specificate CPE (hEX S), and one unique for crypto.
see the folowing picture
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: Optimal settings for IPSec hardware offload

Sat Jan 15, 2022 12:53 pm

@nichky,
I have no knowledge how it actually works under the hood, so the following is just my assumption based on the fact that arrival of the encrypted packets in wrong order has detrimental effects on the throughput and that there used to be issues related to this in the early days of multi-core implementations: I would expect that the system itself sticks the processing of each particular security association to a single core (to avoid packet overtaking) automatically. So what could be helpful for IPsec performance would be to prevent all other tasks from using the same core rather than to just manually stick all crypto processing to a single one, but this could only be done on dual core systems as you can only manually specify a single core for each irq, not a list. I'll go even further in my assumptions - since the performance test results published on the product pages always show better results for a single tunnel, I would expect the system to stick the SA for each direction of the single tunnel to a separate core. If so, locking crypto processing to a single core would even have a negative effect on the throuhgput as it would force both SAs to the same core.

Who is online

Users browsing this forum: Google [Bot] and 30 guests