[strongSwan] Under high load, two IKE initiators send the IKE_SA_INI​T requests with the same SPI

[Chinmaya Dwibedy]

Hi Martin/All,
Thanks for your valuable response. Using the atomic
incrementation to avoid this race condition, I am getting better results. It
means all the 250k IPsec tunnels are getting up (with 850+ TPS) except 10-20. Debugged
the issue (why the 10-20 IPsec tunnels are not getting established)  and found that, the IKE Initiator sends all the 250k IKE_SA_INIT
requests to its peer. The IKE Responder also receives all these 250k requests
including retransmissions. But it generates 249997 IKE_SA_INIT responses. The
struct receiver_t receives packets from the UDP socket, performs light-weight
parsing and adds them to the job queue. I found, it does not drop IKE_SA_INIT
request due to below stated
	1. Because of
cookie/overload checking
	2. if peer has
too many IKE_SAs half open.
	3. if global
half open IKE_SA limit reached.
	4. if job load
acceptable.
 
Can you please suggest what might be the cause behind sending
lesser IKE_SA_INIT responses than received IKE_SA_INIT request? Any hints to
proceed in right direction. 
Regards,
Chinmaya 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140526/22b03ca9/attachment.html>