[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    [strongSwan] Repetitive "ignoring request with ID , already processing" message in high load
From:       Vahid Ashrafian <vahid.arn () gmail ! com>
Date:       2015-06-25 10:50:09
Message-ID: CA+N8a5qy9Z9EW=SJUk5Z6dXm1k4LDuO0B9z3kUUfm-82RYDUDw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi

I need to test IPSec VPN in a powerful server with intel "E5-2650 v2" CPU,
10Gbps network link.
In the test when number of users (connections) reaches over 3000 or 4000
(simultaneously), network bandwidth starts to decrease and we have lots of
logs like "ignoring request with ID 1, already processing".
One thing I check is that start of rekeying process is related to this
problem since it's enforcing more load to the system, so I tried to
increase key-lifetime and rekeying margin to have more smooth distribution
in rekeying process, but that didn't help enough.

I also can simulate same log (ignoring request ...) by enforcing much more
of connection load (five times).

I need to mention that all the time, CPU usage never exceeds 20%. I also
optimized some kernel parameters to support this load (sysctl, etc) and
some strongswan parameters like number of charon threads and
ikesa_table_size.

Do you know what limitations can cause such problem?

[Attachment #5 (text/html)]

<div dir="ltr"><div><div><div><div><div><div>Hi<br><br></div>I need to test IPSec VPN \
in a powerful server with intel &quot;E5-2650 v2&quot; CPU, 10Gbps network \
link.<br></div>In the test when number of users (connections) reaches over 3000 or \
4000 (simultaneously), network bandwidth starts to decrease and we have lots of logs \
like &quot;ignoring request with ID 1, already processing&quot;.<br></div>One thing I \
check is that start of rekeying process is related to this problem since it&#39;s \
enforcing more load to the system, so I tried to increase key-lifetime and rekeying \
margin to have more smooth distribution in rekeying process, but that didn&#39;t help \
enough.<br><br></div>I also can simulate same log (ignoring request ...) by enforcing \
much more of connection load (five times).<br><br></div>I need to mention that all \
the time, CPU usage never exceeds 20%. I also optimized some kernel parameters to \
support this load (sysctl, etc) and some strongswan parameters like number of charon  \
threads and ikesa_table_size.<br><br></div>Do you know what limitations can cause \
such problem?<br></div>



_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[prev in list] [next in list] [prev in thread] [next in thread]