See below...
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Saturday, August 21, 2010 12:03 AM To: CentOS mailing list Subject: Re: [CentOS] OpenVPN throughput
On 08/20/2010 10:19 AM, Bill Campbell wrote:
Comparisons with gigabit networks seems a pointless given that most VPNs will be used over the Internet which limits bandwidth, how fast is fast enough?
Boris said in his first email that the link between the two networks was 1 Gps. _______________________________________________
Perhaps a bit late on this thread, but i thought of adding my $0.02 ...
Last year i've been doing some experiments with openvpn. Just as the O.P. I was curious about sustainable throughput, and was disapointed about the results
To obtain maximum resulst, i did: - use two rather heavy machines (HP DL380-G6, dual quad core) - two dedicated 10Gb-nic's - cross-connect both nics - DISABLE openvpn-debug (as it is VERY cpu expensive) - raise MTU to 4K
Bottleneck was (in my case) the openvpn-process, that was running 100% on a single core, While network was not saturated.
So for max throughput, it is probably strongswan (ipsec) or hw-encryption [or both]
hw
______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
On Mon, Aug 30, 2010 at 4:20 AM, J.Witvliet@mindef.nl wrote:
Last year i've been doing some experiments with openvpn. Just as the O.P. I was curious about sustainable throughput, and was disapointed about the results
To obtain maximum resulst, i did:
- use two rather heavy machines (HP DL380-G6, dual quad core)
- two dedicated 10Gb-nic's
- cross-connect both nics
- DISABLE openvpn-debug (as it is VERY cpu expensive)
- raise MTU to 4K
Bottleneck was (in my case) the openvpn-process, that was running 100% on a single core, While network was not saturated.
So for max throughput, it is probably strongswan (ipsec) or hw-encryption [or both]
What was the bandwidth when the cpu bottlenecked? Were you running a single tcp connection transferring a single file? Or, a mix of traffic with multiple tcp connections, udp traffic, etc? I'm wondering if a more complex traffic mix would get the other cpus working, and increase the total throughput.
On 08/30/10 6:10 AM, drew einhorn wrote:
On Mon, Aug 30, 2010 at 4:20 AM,J.Witvliet@mindef.nl wrote:
Last year i've been doing some experiments with openvpn. Just as the O.P. I was curious about sustainable throughput, and was disapointed about the results
To obtain maximum resulst, i did:
- use two rather heavy machines (HP DL380-G6, dual quad core)
- two dedicated 10Gb-nic's
- cross-connect both nics
- DISABLE openvpn-debug (as it is VERY cpu expensive)
- raise MTU to 4K
Bottleneck was (in my case) the openvpn-process, that was running 100% on a single core, While network was not saturated.
So for max throughput, it is probably strongswan (ipsec) or hw-encryption [or both]
What was the bandwidth when the cpu bottlenecked? Were you running a single tcp connection transferring a single file? Or, a mix of traffic with multiple tcp connections, udp traffic, etc? I'm wondering if a more complex traffic mix would get the other cpus working, and increase the total throughput.
I'm pretty sure one SSL-VPN tunnel == one process. its not going to fork different packets to different threads, as its really paying no attention to sockets and connections within that tunnel.
did you try forcing the blowfish cipher? I've heard that's lower in CPU overhead than most others, although I've not tested this.
On 08/30/2010 10:35 AM, John R Pierce wrote:
did you try forcing the blowfish cipher? I've heard that's lower in CPU overhead than most others, although I've not tested this.
Blowfish is the default. I also tested with AES-128-CBC and didn't see much difference in the throughput.
On 08/30/2010 03:20 AM, J.Witvliet@mindef.nl wrote:
Bottleneck was (in my case) the openvpn-process, that was running 100% on a single core, While network was not saturated.
I found the same thing on a 1Gbps network. It's no surprise that the situation would be the same on a 10Gbps network.
So for max throughput, it is probably strongswan (ipsec) or hw-encryption [or both]
Is strongswan threaded? What did its throughput look like?
-
drew einhorn -
Gordon Messmer -
J.Witvliet＠mindef.nl -
John R Pierce