similar to: Mode: switch and DHCP problems on network with many nodes

Hi, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo

Thanks for answers. I think its now flaw.. but design.. Tinc auto-mesh is very very handy. You just need to avoid flat networks. There is also IndirectMode w/ forces nodes to be switched by intermediate node... but I would be cautionus how its used. I use it myself for certain nodes behind NATs where they cannot be connected to, so always connect node handles switching for them. You noticed it

Hi, thank for getting back. I'll answer the questions, but I've already gave up on tinc and switch to zerotier-one. On 2020-07-27 5:10 p.m., borg at uu3.net wrote: > Hi. I have few questions out of curiosity.. Cant help for now with > your problem... > > What version is crashing? 1.1 or 1.0 ? 1.1 is crashing > > How your network is segmented..? > I use tinc myself

Hi, Terribly sorry about the duplicated message. I've completed the upgrade to Tinc 1.0.31 but, have not seen much of a performance increase. The change looks to be similar to switching to both aes-256-cbc w/ sha256 (which are now the default so, that makes sense). Out tinc.conf is reasonably simple: Name = $hostname_for_node Device = /dev/net/tun PingTimeout = 60 ReplayWindow = 625

The server has a 1G symmetrical fibre line. It has been speedtested to various local servers to be close to 800-900M. When there is only a single client, there isn't much problem and as soon as the connection is made, the ping time through to tunnel is a respectable 30ms. As soon as a few more clients are connected, ping time degrades to hundreds and sometimes seconds and with dropped packets.

Hi. I have few questions out of curiosity.. Cant help for now with your problem... What version is crashing? 1.1 or 1.0 ? How your network is segmented..? I use tinc myself here a lot too (1.0) but my network is very segmented. I use switch mode and handle routing myself, so mesh links arent large.. I would NOT go beyond 30 nodes for full auto-mesh.. its already like 435 edges... Regards,

Hi Jared, I've seen the same while testing on digital ocean, I think it's the context switching that happens when sending a packet. I've done some testing with wireguard and that has a lot better performance but it's still changing quite a lot and only does a subset of what tinc does so probably not a stable solution. Martin On Wed, 17 May 2017 at 18:05 Jared Ledvina <jared at

Hi all, I have a network with about ~800. The network is a mix of tinc 1.0 and 1.1 nodes. It is gradually expanding for several years now. The problem is that at some point it seams the daemon can not handle the processing of the new connection and the edges. There are 3 major nodes in the system and every other node initially makes connection to one of them. Now after a lot of debugging

Folks, We have a setup where each mobile node connects with 1 or more tinc instances (over different links) to a central node. tinc is running in switch mode. The link is chosen by setting the IP address on the active link's interface, and the central node sees this after the first packet on the link, and moves the MAC address to a different 'ethernet port' (link). This works really

Dear tinc-list, I am a happy tinc user for many years and am using several different VPNs. However today I was unable to add a new server to my "backbone" VPN. I hope it is okay that I write this issue to this list as hours of googling did not help. My setup consists of several servers, all tincing happily ever after. "kallisto" as one of them is happy talking to other

Guus, Below a segment of a log file. I am trying to analyse why the satellite link goes down and up all the time (sometimes 10 to 15 times an hour, sometimes not for a day. My guess is that this indicates packet loss on the satelllite link and tinc not really recovering from that. Where I inserted an empty line the log basically stopped and was silent for I guess for 14 minutes? Would setting

tl;dr - Is anybody "running" a Fedora system via systemd-nspawn under CentOS? Long version: Before CentOS 7, I used chroot to create "lightweight containers" where I could cleanly add extra repos and/or software without the risk of "polluting" my main system (and potentially ending up in dependency hell). The primary driver for this was MythTV, which has dozens of

On 01/30/2014 07:41 AM, Kashyap Chamarthy wrote: > Last night I was tinkering with `systemd-nspawn` -- namespace based > container for testing, I thought I'll post what I tried with libguestfs > here: > > > Prerequisite > ------------ > > Because of an audit subsystem incompatibility bug - rhbz#966807[1], turn > off auditing by booting the host w/

??? ??? systemd-nspawn fails in C7 with ???? ??? ------------ nspawn error -------- ??? sudo? systemd-nspawn ??? Spawning namespace container on /mnt/usb (console is /dev/pts/1). ??? Init process in the container running as PID 1799. ??? Failed to open system bus: No such file or directory ??? Failed to open system bus: No such file or directory ??? Container failed with error code 254. ???

Last night I was tinkering with `systemd-nspawn` -- namespace based container for testing, I thought I'll post what I tried with libguestfs here: Prerequisite ------------ Because of an audit subsystem incompatibility bug - rhbz#966807[1], turn off auditing by booting the host w/ 'audit=0' on Kernel command line. (NOTE: There's work in progress[2] in upstream Kernel to fix

Hello Patrick, >On 7/3/19 8:21 AM, Sven Schwedas via samba wrote: >> Though I'm not sure if docker is the right tool for the job; samba as a >> fat daemon running a bazillion subprocesses orchestrated by a >> persistent database that's very sensitive to instances leaving and >> joining the domain seems the antithesis to docker's philosophy. >>

https://bugzilla.netfilter.org/show_bug.cgi?id=1210 Bug ID: 1210 Summary: nftables gets confused by user namespaces when meta skuid is used Product: nftables Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 Component: nft

On 01/30/2014 04:38 PM, Daniel P. Berrange wrote: [. . .] >> >> Despite reading from the `systemd-nspawn` man page: >> >> ". . .kernel modules may not be loaded from within the container." >> >> I purposefully tried from inside the container: > > With container based virt there is only one kernel image, Noted, that's one of the main

On 7/3/19 8:21 AM, Sven Schwedas via samba wrote: > Though I'm not sure if docker is the right tool for the job; samba as a > fat daemon running a bazillion subprocesses orchestrated by a persistent > database that's very sensitive to instances leaving and joining the > domain seems the antithesis to docker's philosophy. > Docker would be a terrible choice for this;

We run tinc in a linux environment in which it sits there waiting for connections from the clients. All clients are configured to only have one ConnectTo which points to this server. We're seeing in the server log that as soon as a client's connection is activated, a whole bunch of "Flushing x bytes to that host would block" is logged and the whole vpn is bogged down and has