Hi to all,
I wanted to share with you the results.
[computer] -- [CCR1009-7G-1C-1S+] -- EoIP (actual MTU 1396) -- IPSEC -- [CCR1009-7G-1C-1S+PC] -- IPSEC -- EoIP -- [CCR1009-7G-1C-1S+] -- [computer]
auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=30m pfs-group=modp2048
Did various test with IPSEC + GRE and EoIP. Will check soon IPIP.
the results are more or less there on the attached screenshot, does it seem right ?
Including the history was tested on windows using jperf 2.0.2.
Will test some more.
v6.40.rc4 GRE-IPSec SMB
You do not have the required permissions to view the files attached to this post.
Re: v6.40.rc4 GRE-IPSec SMB
Looks very low. Can you force it to AES128 and see if there is improvement? May also be getting fragmentation issues.
Re: v6.40.rc4 GRE-IPSec SMB
Code: Select all
/ip ipsec peer print
0 address=10.0.1.1/32 auth-method=pre-shared-key secret="test"
generate-policy=no policy-template-group=default exchange-mode=main
send-initial-contact=yes nat-traversal=no proposal-check=obey
hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp1024 lifetime=1d
dpd-interval=2m dpd-maximum-failures=5
/ip ipsec proposal print
0 name="default" auth-algorithms=sha1 enc-algorithms=aes-128-cbc lifetime=30m
pfs-group=modp1024
/ip ipsec policy print
1 A src-address=10.0.11.0/24 src-port=any dst-address=10.0.22.0/24
dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=10.0.1.1
sa-dst-address=10.0.2.1 proposal=default priority=0 ph2-count=2You do not have the required permissions to view the files attached to this post.
Re: v6.40.rc4 GRE-IPSec SMB
What CPU usage are you seeing during that copy?
Re: v6.40.rc4 GRE-IPSec SMB
First (source lan from windows copy) - Second (copy destination win box)
(correction for the second CPU , there was divided during the screenshot, for the most part was concentrated on one core)
(correction for the second CPU , there was divided during the screenshot, for the most part was concentrated on one core)
You do not have the required permissions to view the files attached to this post.
Re: v6.40.rc4 GRE-IPSec SMB
If you copy a number of files at once, does it increase the throughput?
Re: v6.40.rc4 GRE-IPSec SMB
Without testing I can reply with certainty, no, it does not.
Sent from my D5803 using Tapatalk
Sent from my D5803 using Tapatalk
Re: v6.40.rc4 GRE-IPSec SMB
What is your clamp MSS setting on the EoIP? If you disable encryption how much faster is it?
Re: v6.40.rc4 GRE-IPSec SMB
200Mbps TCP traffic over single ipsec/eoip tunnel is good result. To increase overall performance you need multiple streams (tunnels)
Re: v6.40.rc4 GRE-IPSec SMB
RB1100AHx2 from 5 years ago can do 500mbps+ on a TCP single stream on one EoIP+IPSEC tunnel. 700mbps with multiple TCP streams. Should the CCR not be faster?200Mbps TCP traffic over single ipsec/eoip tunnel is good result. To increase overall performance you need multiple streams (tunnels)
Re: v6.40.rc4 GRE-IPSec SMB
It is faster with multiple streams
Re: v6.40.rc4 GRE-IPSec SMB
Fair enough. Do you think the RB1100AHx4 can beat the x2 with low stream count?It is faster with multiple streams
Re: RE: Re: v6.40.rc4 GRE-IPSec SMB
With bonding after?It is faster with multiple streams
How is it implemented ? With IPSEC from same interfaces and diffrent IPs ?
In paralel ? Multi subnet ipsec on/from the same interface and then EoIP or GRE?
After that bonding the two resulting interfacfes using bonding (balance rr)?
I tried it with´out success, maybe I am doing it wrong .. The second IPSEC has issues for "phase 2"..
Do you have code example for multi stream ipsec config?
Regards.
P.S. Two EoIP on the same IPSEC are doing the same bandwith like one. I am hitting the "rule of tomb 1 ipsec per core".
-
-
JimmyNyholm
Member Candidate
- Posts: 248
- Joined:
- Location: Sweden
Re: v6.40.rc4 GRE-IPSec SMB
One must also ask: Source Media and Destination Media 20Mbyte per second (200Mbit) is about what your average 2" spinning harddrive does after all buffers have been depleted. Allways test network with memory transfers so you test the real performance.
Re: v6.40.rc4 GRE-IPSec SMB
Update
created:
eth7 WAN
eth6 IP0 + IP1-IP2
eth5 IP3-IP4
(apparently on the CCR 1009 1-4 port are switch ports, only the 3 last ones are HW encryption accelerated)
https://wiki.mikrotik.com/wiki/Manual:I ... imizations
Update: CCR1009-7G should have all ports accelerated !! Is this info for all CCR1009 or just the CCR1009-8G ?!?!?!?!
VPN:
4 IPSEC (IP1,IP2,IP3,IP4 each on they own subnet)
4 EoIP On each of the end point (Clamp TCP MSS + Fast Path)
1x BONDING balance RR
Routed the IP1 subnet to the BONDING.
the result is almost same as previous ones, I tried even to change the MTU, it got worse:
The traffic is windows copy: Jperf, two TCP streams in both directions: CPU, during jperf: I even disabled EoIP 2 and 4, there was NO change. The throughput was just balanced on the remaining two EoIP tunnels.
any ideas ?
created:
eth7 WAN
eth6 IP0 + IP1-IP2
eth5 IP3-IP4
(apparently on the CCR 1009 1-4 port are switch ports, only the 3 last ones are HW encryption accelerated)
https://wiki.mikrotik.com/wiki/Manual:I ... imizations
Update: CCR1009-7G should have all ports accelerated !! Is this info for all CCR1009 or just the CCR1009-8G ?!?!?!?!
VPN:
4 IPSEC (IP1,IP2,IP3,IP4 each on they own subnet)
4 EoIP On each of the end point (Clamp TCP MSS + Fast Path)
1x BONDING balance RR
Routed the IP1 subnet to the BONDING.
the result is almost same as previous ones, I tried even to change the MTU, it got worse:
The traffic is windows copy: Jperf, two TCP streams in both directions: CPU, during jperf: I even disabled EoIP 2 and 4, there was NO change. The throughput was just balanced on the remaining two EoIP tunnels.
any ideas ?
You do not have the required permissions to view the files attached to this post.
Re: v6.40.rc4 GRE-IPSec SMB
Thanks to all the feedback.
To conclude this Odyssey, if you need encryption, take another better product. If you need basic routing/firewall go for this product family, but if you need encryption with tunnels you are in bad luck. This is not one of the accelerated aes puppies, even multi treading benefits on this arhitekture is questionable. This is all old software single tread limit.
I am happy that I had 3 of this to make a test lab, to go beyond the mikrotik brochure and marketing and make conclusion on my own. In the future I will use heavily the return policy, if I want to hurt my self some more. Will not hold to promise's of the "will be fixed in the next RC" type. For the peace of mind even the pfsense development and no warranty doesn't sound bad after this 3+ years and counting of beta testing for this specific feature. If that's the norm, the refund policy of your products should be changed to 4 years !
Thanks to my local MT supplier for all the help.
Regards.
To conclude this Odyssey, if you need encryption, take another better product. If you need basic routing/firewall go for this product family, but if you need encryption with tunnels you are in bad luck. This is not one of the accelerated aes puppies, even multi treading benefits on this arhitekture is questionable. This is all old software single tread limit.
I am happy that I had 3 of this to make a test lab, to go beyond the mikrotik brochure and marketing and make conclusion on my own. In the future I will use heavily the return policy, if I want to hurt my self some more. Will not hold to promise's of the "will be fixed in the next RC" type. For the peace of mind even the pfsense development and no warranty doesn't sound bad after this 3+ years and counting of beta testing for this specific feature. If that's the norm, the refund policy of your products should be changed to 4 years !
Thanks to my local MT supplier for all the help.
Regards.