[Openswan Users] Scalability and performance of OpenSwan tunnels compared to individual SSL request/response cycles

Samba saasira at gmail.com
Sun Aug 28 13:10:13 EDT 2011


Thanks a lot Paul, for the detailed response.
This helps a lot in clearing some doubts in my mind.

Regards,
Samba

------------------------------------------------------------------------------------------------------------------------------------
On Sun, Aug 28, 2011 at 10:36 PM, Paul Wouters <paul at xelerance.com> wrote:

> On Wed, 24 Aug 2011, Samba wrote:
>
>  Here are my questions/doubts regarding the scalability/performance of this
>> setup:
>>  *  First of all, we plan to use CentOS6, so will the kernel support for
>> IPSec in CentOS6 sufficient to establish
>>    tunnels between machines or should I need to OpenSwan still?
>>
>
> openswan is part of centos. You have a choice of NETKEY kernel stack and
> KLIPS kernel stack.
> You can pick the default NETKEY stack, unless you have overlapping IPs on
> your connecting clients
> subnets (eg multiple 192.168.0.0/16 subnets or duplicate subnets behind a
> NAT router). Then you
> need to use KLIPS with SAref.
>
>   *  Can the IPSec software scale as much as we need to support creating a
>> few thousand tunnels on the server machine
>>
>>    with the above mentioned hardware configuration?
>>
>
> Yes.
>
>   *  What will be the CPU  and memory consumption when we make those many
>> tunnels on the server machine?
>>
>
> Memory consumption is pretty low. CPU usage depends on amount of traffic,
> not the amount of tunnels.
>
>   *  It is said that a web server scales many times  for ordinary https
>> requests than keep-alive https requests; wouldn't
>>
>>    that same analogy apply here where having each application make a
>> separate SSL request for a short period of time
>>    and closing the connection scale much better than having those many
>> thousands of dedicated tunnels running live,
>>    although idly?
>>
>
> Yes, it should reduce the overhead of SSL/TLS. The IPsec SA lookup should
> be really fast per-packet.
>
>   *  we would want the server system to also do some very essential stuff
>> other than managing this tunnelling business,
>>
>>    so can this design scale and perform reasonably?
>>
>
> I think so, but it depends on the other things you run and how much
> resources those take.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110828/d66e00a6/attachment.html 


More information about the Users mailing list