Florian Schoedel
2014-Jun-12 04:52 UTC
memory leak with vlan tagged traffic in switch mode
Hi, has anybody a running setup with 2 or more tinc daemons in switch mode which transport 8021q tagged traffic? I am trying to connect two segments with about 4 x 1000 mac addresses (distributed on different vlans). I am always running out of memory on one side. This happens only on the side where the arp requests come from. Currently there is no unicast traffic between the sides; only broadcasted arp requests. It looks like tincd reserves memory with each arp request which isn't freed afterwards or tincd builds internal structures for the arp cache, based on the wrong information from the ethernet header, when I transport 8021q tagged traffic. If I change my config from switch to hub mode, everything works fine. Are there any drawbacks If I use hub mode when there are only two connected sites? Thanks for your help Florian -----Original Message----- From: "Florian Schoedel" <Florian.Schoedel at meteringservice.de> To: tinc-devel at tinc-vpn.org Date: Wed, 11 Jun 2014 19:40:45 +0200 Subject: Fwd: memory leak Hi, I've observed this strange behaviour for a while in my test environment. It looks like that all problems gone away when I switch to "hub-mode" instead of switch mode. Does tinc still work properly in switch mode when I transport vlan tagged traffic within that tunnel? In my environment the side, which is receiving arp requests from the wired interface, is running out of memory. The other side, which receivces the arp requests through the tunnel doesn't run out of memory. Best regards Florian -----Original Message----- From: "Florian Schoedel" <Florian.Schoedel at meteringservice.de> To: tinc-devel at tinc-vpn.org Date: Fri, 06 Jun 2014 09:50:33 +0200 Subject: memory leak Hi, I am running tinc on alpine linux 2.7.8 in 2 seperate environments. The first environment is running for about a month without any problems. The second environment causes some trouble. It looks like a memory leak on the client side. tincd.conf: ConnectTo=ServerHost Device=/dev/net/tun Mode=switch Name=ClientHost PMTUDiscovery = yes DeviceType=tap PriorityInheritance = yes Compression=10 hosts/ServerHost Address=XXXX PMTUDiscovery = yes PriorityInheritance = yes -----BEGIN RSA PUBLIC KEY----- XXX -----END RSA PUBLIC KEY----- Linux Kernel 3.10.40-0-grsec #1-Alpine SMP Wed May 14 07:59:37 UTC 2014 x86_64 Linux apk info tinc tinc-1.0.23-r1 description: tinc is a Virtual Private Network (VPN) daemon tinc-1.0.23-r1 webpage: http://www.tinc-vpn.org/ tinc-1.0.23-r1 installed size: 180224 apk info openssl openssl-1.0.1h-r0 description: Toolkit for SSL v2/v3 and TLS v1 openssl-1.0.1h-r0 webpage: http://openssl.org openssl-1.0.1h-r0 installed size: 589824 apk info lzo lzo-2.03-r5 description: LZO -- a real-time data compression library lzo-2.03-r5 webpage: http://www.oberhumer.com/opensource/lzo lzo-2.03-r5 installed size: 131072 It doesn't matter if I bypass-security or disable / enable compression. Can anybody confirm, that tinc is running on alpine linux with this software versions? Thanks a lot Florian Th?ga MeteringService GmbH, Sitz: Naila, eingetragen beim Amtsgericht in Hof, HRB: 4125 Gesch?ftsf?hrer: Peter Hornfischer StNr.: 223/140/10756, gef?hrt beim Finanzamt Hof, USt-ID-Nr.: DE 246359579 Bankverbindung: BayernLB M?nchen, BLZ 700 500 00, Konto-Nr. 4113816 Gesch?ftsadresse Th?ga MeteringService GmbH, Zum Kugelfang 2, 95119 Naila Haftungsausschluss: Diese Nachricht erh?lt vertrauliche Informationen, welche nur f?r den Empf?nger bestimmt sind. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte sofort und vernichten Sie s?mtliche Kopien (digital/Papier). Danke. Disclaimer: The information contained in this message is confidential and may only be used by the intended recipient. If you received it in error, please notify us immediately and destroy any copies (digital and paper). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140612/23b97e4b/attachment.html>
On Thu, Jun 12, 2014 at 06:52:15AM +0200, Florian Schoedel wrote:> I am trying to connect two segments with about 4 x 1000 mac addresses > (distributed on different vlans). I am always running out of memory on one > side. This happens only on the side where the arp requests come from. > Currently there is no unicast traffic between the sides; only broadcasted > arp requests. > It looks like tincd reserves memory with each arp request which isn't freed > afterwards or > tincd builds internal structures for the arp cache, based on the wrong > information from the ethernet header, when I transport 8021q tagged traffic.Tinc reserves memory for each MAC address it sees. Unfortunately, it's not too space efficient with those, so if all 4000 MAC addresses are being seen by tinc, that can easily cause tinc to allocate 1 megabyte of memory. How much memory do you have and how much do you see tinc use in your setup?> If I change my config from switch to hub mode, everything works fine. > Are there any drawbacks If I use hub mode when there are only two connected > sites?If it's only two sites, there is no drawback to using hub mode. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140615/f2b36938/attachment.sig>