[strongSwan] IPsec/IKEv2 tunnels scalability issue with load-tester plugin (using strongSwan 5.0.4)

[Chinmaya Dwibedy]

 Hi Martin,
Thanks for your suggestion.  I modified the strongswan
codes to set the soft_add_expires_seconds, hard_add_expires_seconds, soft_use_expires_seconds
and hard_use_expires_seconds to 86400 seconds (i.e., 24 hours) in add_sa()
(kernel_netlink_ipsec.c). 
Thereafter I tested in 600 IPsec connections (with modified
code) for 7 times. For the first five runs, it could able bring up all the 600
tunnels at both sides (IKE initiator and responder). In order to check, I used
the “#ip xfrm state count” command at both ends from time to time. Always it
showed the SAD count to be 1200 and #ipsec statusall command showed that, all
600 connections were up. But in last two runs, it could not bring all 600 IPsec
tunnels (SAD count was 928 and 858). 
To debug the issue, turned on the log at IKE initiator as
well as IKE responder end and found the same error messages (i.e., received a
XFRM_MSG_EXPIRE [KNL] creating delete job for ESP CHILD_SA with SPI c7b31) for
some of the SPIs  in charon.log file at
IKE initiator. However did not notice the same error at IKE responder.
 The
#ip xfrm monitor shows the following at both the ends
IKE Initiator 
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x5e protocol
esp  SPI 0xcdffe578
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x5e protocol
esp  SPI 0xc1ea9979
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x54 protocol
esp  SPI 0xc45ea517
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x54 protocol
esp  SPI 0xc3335aad
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x59 protocol
esp  SPI 0xcda509be
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x59 protocol
esp  SPI 0xc1239ef9
 
IKE Initiator 
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x52 protocol
esp  SPI 0xc099edd1
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x52 protocol
esp  SPI 0xc0e08241
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x53 protocol
esp  SPI 0xc3335aad
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x53 protocol
esp  SPI 0xc45ea517
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x54 protocol
esp  SPI 0xc482bf43
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x54 protocol
esp  SPI 0xc12212fe
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x55 protocol
esp  SPI 0xc60403b6
Async event  (0x20)  timer expired
        src 30.30.30.2
dst 30.30.30.1  reqid 0x55 protocol
esp  SPI 0xc2f5c7db
Async event  (0x20)  timer expired
        src 30.30.30.1
dst 30.30.30.2  reqid 0x56 protocol
esp  SPI 0xc5f84e63
Async event  (0x20)  timer expired
Can you please let me know why this does not work consistently?
Thanks in advance for your support and help.
Regards,
Chinmaya 
 

________________________________
 From: Martin Willi <martin at strongswan.org>
To: Chinmaya Dwibedy <ckdwibedy at yahoo.com> 
Cc: "users at lists.strongswan.org" <users at lists.strongswan.org> 
Sent: Wednesday, August 7, 2013 12:39 PM
Subject: Re: [strongSwan] IPsec/IKEv2 tunnels scalability issue with load-tester plugin (using strongSwan 5.0.4)
  

Hi,

> But in this case,  since I have disabled the rekeying,  the kernel
> should not send XFRM_MSG_EXPIRE event to charon daemon.

I'd guess that the kernel sends expires for the allocated SPIs, and then
the SA for this SPI can't get updated.

You may try to change the hard-coded SPI allocation expiration timeout
at [1]. It gets set to the default retransmission timeout, but in this
special case you might have to adjust it for your needs.

Regards
Martin

[1]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c;h=b34fa149;hb=HEAD#l2668
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130808/8fd8f642/attachment.html>