[strongSwan] Ipsec up/down(brining up one client up/down) is a trigger to bring back up A non-responsive server

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello meenakshi,

Did you check if the IPsec SAs are still there for the tunnels, when you
get timeouts? I would like to get some information on the state of the
ipsec stack when that happens. Stuff like the statistics of the policies
("ip -s x p") and the CPU usage. This is likely a problem with the IPsec stack of the
Linux kernel, as it does traffic processing.

Mit freundlichen Grüßen/Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 20.02.2015 um 23:22 schrieb meenakshi bangad:
> I am experiencing a very interesting behaviour with Strongswan server.
>
> Using the load tester plugin I can bring up multiple clients. I have set up about 200 clients on 2 machines (each running 100 Ipsec tunnels to the servers).
> I have my own traffic generator which is sending traffic across this multiple tunnels.
>
> Initially everything runs fine, but after some time  I start getting time-outs in my traffic generator application. I have tried modifying the sysctl settings etc,
> but nothing has worked. If during that time I bring up another client everything starts to work back again. So the trigger to non -responsive server is brining a tunnels up and down. Since
> I have been doing this the generator on the other 200 tunnels never times out. It seems like the server is stuck somewhere and the a tunnel up or down breaks that loop.
>
> Has anyone else experiencing the same behaviour ?
>
> Thanks,
>
> Meenakshi
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJU65POAAoJEDg5KY9j7GZYWBwQAI12PJ6yIvSnsgR88itkgf+2
oMn7Ww5bwBJpXE903H8LnoNM9DMxm1FP+hhUQtTwT4fGbL4n+yRKCd5IbWqo1fhE
Iul7DTyIjw6YvaoCSKBz6iVfWjkSrm48PSHqrdHka/MI3rv5JpD0k8uLxXn+aqH2
l+xcPS89rERFw28aL5pXHRGVgfZcjmnPwpCSUCVIqE7it67wMNi4eKOTIIdzjHbR
bQ0n3gKKlDrNsspWm9HWhlG9d0JzNkqSDfaoLR3NxCLNPnr7zpcDX6Ifd2gWJZzn
IbLuBYfefuyFV0/N9MHxX55Sl7U6iJxW1qSAuiry1paen90BlsIDLrMgzULmwUqt
0Qt3uQlewPMTU5R/lvR5dKmmrULB8TnJLDJm66k40TzSA5paCnnGdeA8vGSSKyBc
Xk6S/f8Wi2MySD/9+EBvEzw5NOtnDfJG+yngwjkWB8BJpTGKkTyvcsJLmBEKZYsd
azK7lsvEhMcjt7gGT+OWo0QIc8p8XqMqX31qASp7DhMMuu16ZNUF2icOEzquHxbK
lkUu4fRosDfEe0js6pC1vpMQTjlgvqE3/x7ugxonSR3JU9FxMhp2xgT2BbO81JHT
xMY9rTxiuOj2DUzWWT1H33q4nJepo0aUcK6oKQ6vCCBHLX8FlyVP/WJjc91dcTSd
c3Coq5ffPDqjDiSJnnFA
=0CAd
-----END PGP SIGNATURE-----