[strongSwan] Issue with tunnel establishment under high load

Chinmaya Dwibedy ckdwibedy at yahoo.com
Wed Jun 4 08:05:34 CEST 2014


Hi,
Under high load, the  check_and_put_init_hash() function returns ALREADY_DONE ( for some of
the IKE_SA_INIT new requests ) at IKE responder end. In such case,  if I create the new IKE_SA in checkout_by_message
() function, it works fine.  I mean , all
the 250k security associations are getting established with 1000 TPS.  Can anyone please verify the below stated changes
and suggest if it will lead to other problems? Thanks in advance for your help
and support.  
 
METHOD(ike_sa_manager_t, checkout_by_message, ike_sa_t*,
                private_ike_sa_manager_t*
this, message_t *message)
{
---------------------------;
                ---------------------------;
 
switch (check_and_put_init_hash(this, hash, &our_spi))
                                {
                                ---------------------------;
                                ---------------------------;
 
                                                case
NOT_FOUND:
case
ALREADY_DONE:
                                                {                                              
---------------------------;
                                                                                ---------------------------;
                                                                                ike_sa
= ike_sa_create(id, FALSE, ike_version);
                                                }
//case
ALREADY_DONE:
 
}
Regards,
Chinmaya 


On Monday, June 2, 2014 1:09 PM, Chinmaya Dwibedy <ckdwibedy at yahoo.com> wrote:
  


Hi Martin/All,

I think, my email missed your kind attention.  Thus I request your goodness to have a look into this and respond. Your help in this regard will be highly appreciated.

Regards,
Chinmaya  


On Thursday, May 29, 2014 6:39 PM, Chinmaya Dwibedy <ckdwibedy at yahoo.com> wrote:
  






Hi Martin,

Can you
please have a look into the below stated and let me know if it a bug with
strongswan-5.0.4 in high load?

The
IKE_SA-Manager is responsible for managing all initiated and responded
IKE_SA's. Under high load (i.e. 900-1000 TPS and 250k IPsec tunnels), the IKE
Responder end does not respond to all the IKE_SA_INIT request messages received
from IKE Initiator.  During debugging I found
that,   at IKE responder end,   the call
to checkout_by_message () does return the IKE_SA for some of IKE_SA_INIT request
messages (not retransmission message). Surprisingly the check_and_put_init_hash()
function returns ALREADY_DONE saying that, the message with the given hash has
been seen before. I think, if a responder receives an IKE_SA_INIT request, it determines
whether the packet is a retransmission belonging to an existing  half-open IKE_SA (in which case the responder
retransmits the same  response), or a new
request (in which case the responder creates a new IKE_SA and sends a fresh
response). But I find Charon daemon (IKE Responder) drops some of the new requests
and all the retransmitted packets. But with reduced setup rate (200+),
everything works as expected. 

 

Regards,

Chinmaya   

 


On Tuesday, May 27, 2014 7:42 PM, Chinmaya Dwibedy <ckdwibedy at yahoo.com> wrote:
  


Hi,
Using the
load tester plugin of strongswan (5.0.4), could able to achieve the 250k IPsec
tunnels with 1000 tunnels per second. However I found that, some of the tunnels
(approximately 10-20) were not getting up. Upon debugging found that, at IKE
responder end, the checkout_by_message() of ike_sa_manager_t does not return
pointer to ike_sa_t for some of the IKE_SA_INIT request messages (in execute()
routine of job). But if I reduce the setup rate to 200, all the tunnels come
up. Is it an bug with strongswan 5.0.4 in high load? Can anyone please suggest
what might be the issue? Thanks in advance for your support.
 
Regards,
Chinmaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140603/5aad5ceb/attachment-0001.html>


More information about the Users mailing list