[Swan-dev] Pluto memory consumption

Tue Feb 28 15:30:58 UTC 2017

Thanks for the replies.

This is the output of "ipsec status" when running pluto over night (25 
MB memory consumption) described below:

000 Total IPsec connections: loaded 2, active 2
000
000 State Information: DDoS cookies not required, Accepting new IKE 
connections
000 IKE SAs: total(4), half-open(0), open(0), authenticated(4), anonymous(0)
000 IPsec SAs: total(4), authenticated(4), anonymous(0)
000
000 #5538: "mytunnel":500 STATE_PARENT_I3 (PARENT SA established); 
EVENT_SA_EXPIRE in 2s; isakmp#5537; idle; import:admin initiate
000 #5538: "mytunnel" esp.55fd7f47 at 10.48.28.60 esp.8404bfbb at 10.48.28.70 
tun.259e at 10.48.28.60 tun.259f at 10.48.28.70 ref=0 refhim=4294901761 
Traffic:! ESPmax=0B
000 #5537: "mytunnel":500 STATE_PARENT_I3 (PARENT SA established); 
EVENT_SA_REPLACE in 3s; isakmp#0; idle; import:admin initiate
000 #5537: "mytunnel" ref=0 refhim=0 Traffic:
000 #5542: "mytunnel":500 STATE_PARENT_I3 (PARENT SA established); 
EVENT_SA_REPLACE in 39s; newest IPSEC; eroute owner; isakmp#5541; idle; 
import:admin initiate
000 #5542: "mytunnel" esp.55fd7f49 at 10.48.28.60 esp.8404bfbd at 10.48.28.70 
tun.25a2 at 10.48.28.60 tun.25a3 at 10.48.28.70 ref=0 refhim=4294901761 
Traffic:! ESPmax=0B
000 #5541: "mytunnel":500 STATE_PARENT_I3 (PARENT SA established); 
EVENT_SA_REPLACE in 52s; isakmp#0; idle; import:admin initiate
000 #5541: "mytunnel" ref=0 refhim=0 Traffic:
000 #5539: "mytunnel":500 STATE_PARENT_R2 (received v2I2, PARENT SA 
established); EVENT_SA_REPLACE in 29s; isakmp#0; idle; import:respond to 
stranger
000 #5539: "mytunnel" ref=0 refhim=0 Traffic:
000 #5543: "mytunnel":500 STATE_PARENT_R2 (received v2I2, PARENT SA 
established); EVENT_SA_REPLACE in 77s; newest ISAKMP; isakmp#0; idle; 
import:respond to stranger
000 #5543: "mytunnel" ref=0 refhim=0 Traffic:
000 #5540: "mytunnel_subnet":500 STATE_PARENT_R2 (received v2I2, PARENT 
SA established); EVENT_SA_REPLACE in 9s; isakmp#5539; idle; 
import:respond to stranger
000 #5540: "mytunnel_subnet" esp.55fd7f48 at 10.48.28.60 
esp.8404bfbc at 10.48.28.70 tun.25a0 at 10.48.28.60 tun.25a1 at 10.48.28.70 ref=0 
refhim=4294901761 Traffic:! ESPmax=0B
000 #5544: "mytunnel_subnet":500 STATE_PARENT_R2 (received v2I2, PARENT 
SA established); EVENT_SA_REPLACE in 57s; newest IPSEC; eroute owner; 
isakmp#5543; idle; import:respond to stranger
000 #5544: "mytunnel_subnet" esp.55fd7f4a at 10.48.28.60 
esp.8404bfbe at 10.48.28.70 tun.25a4 at 10.48.28.60 tun.25a5 at 10.48.28.70 ref=0 
refhim=4294901761 Traffic:! ESPmax=0B
000
000 Bare Shunt list:
000

I'm not seeing thousands of tunnels waiting to get expired...

I can also add that when running with IKEv1 instead of IKEv2 the memory 
consumption doesn't seem to grow at all. Or very modest at least.

Regards,

Erik

On 2017-02-28 15:34, Paul Wouters wrote:
> I think your rekey times are too fast and you create tunnels faster then we let them linger. Run "ipsec status" and I bet you are seeing thousands of tunnels waiting to get expired.
>
> I do think we are keeping those around for far too long (an hour or so instead of like 20s or so)
>
> Paul
>
> Sent from my iPhone
>
>> On Feb 28, 2017, at 09:28, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>>
>> | From: Erik Andersson <erik at ingate.com>
>>
>> (This is a quick reply, not a careful one.)
>>
>> | I ran the tunnels for 6 days and recognized that the memory consumption of
>> | pluto was quite high. It started using around 8 MB and after six days it used
>> | around 140 MB on both hosts.
>>
>> That's not good.
>>
>> | The leak detective reported the following when I shutdown pluto:
>>
>> | Feb 27 13:56:13: leak detective found 6 leaks, total size 192
>>
>> Clearly this isn't the problem.  It only accounts for 192 bytes.
>> n
>> | Is this "normal" memory consumption? 140 MB seems quite high to me but I'm not
>> | sure.
>>
>> It should not be normal.
>>
>> | I ran another test with valgrind over night. The pluto process started with 8
>> | MB and rose to 25 MB. I noticed two places where a lot of memory were still
>> | reachable:
>>
>> NSS does its own memory allocation and is thus invisible to the leak
>> detective.  Anything NSS-related is thus suspect.  Think: keys and
>> related stuff.  So you are probably on the right track.
>>
>> | ==2935== 5,095,216 bytes in 938 blocks are still reachable in loss record 652
>>
>> | ==2935==    at 0x4C2B975: calloc (vg_replace_malloc.c:711)
>> | ==2935==    by 0x6B3B351: PORT_ZAlloc_Util (in /usr/lib64/libnssutil3.so)
>>
>> | ==2935==    by 0x16B228: symkey_from_symkey (crypt_symkey.c:283)
>>
>>
>>
>> | 7,202,832 bytes in 1,326 blocks are still reachable in loss record 653 of 653
>>
>> | ==2935==    at 0x4C2B975: calloc (vg_replace_malloc.c:711)
>> | ==2935==    by 0x6B3B351: PORT_ZAlloc_Util (in /usr/lib64/libnssutil3.so)
>>
>> | ==2935==    by 0x16B356: chunk_from_symkey (crypt_symkey.c:319)
>>
>> 25MB - 8MB is bigger than 5MB + 7MB so there's more going on.
>> _______________________________________________
>> Swan-dev mailing list
>> Swan-dev at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan-dev
>
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
>