Hello Maximilian, I think may be cause by MTU proble if you have many peer. you can run tincd with -d 5 or tincd -n "yournetname" -k INT , check the log file to see what happen. if so, you can use my patch to fix this. thanks PHB On Sat, Mar 21, 2020 at 7:00 PM <tinc-request at tinc-vpn.org> wrote:> Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > or, via email, send a message with subject or body 'help' to > tinc-request at tinc-vpn.org > > You can reach the person managing the list at > tinc-owner at tinc-vpn.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tinc digest..." > Today's Topics: > > 1. Re: High tinc traffic on ethernet without tinc load (Lars Kruse) > 2. Re: High tinc traffic on ethernet without tinc load > (Maximilian Stein) > 3. Re: High tinc traffic on ethernet without tinc load (Lars Kruse) > 4. Re: High tinc traffic on ethernet without tinc load > (Maximilian Stein) > > > > ---------- Forwarded message ---------- > From: Lars Kruse <lists at sumpfralle.de> > To: tinc at tinc-vpn.org > Cc: > Bcc: > Date: Fri, 20 Mar 2020 15:43:13 +0100 > Subject: Re: High tinc traffic on ethernet without tinc load > Hallo Maximilian, > > Am Thu, 19 Mar 2020 16:31:57 +0100 > schrieb Maximilian Stein <m at steiny.biz>: > > > There I learned the basic patterns of these situations (communication > with > > many peers on ethernet but nearly nothing on the virtual tinc link). > > Did you really try the nice visualizations in the "Statistics" menu? > These should allow you to see, which protocols and which peers cause the > traffic. > > I am slightly confused, that you already took a look at the traffic, but > you did > not mention, which type of traffic makes up the bulk of the excessive > packets > you encountered. You mentioned "a few SSDP packages", but nothing else. > > Or did I just overlook it in your emails? > > Happy traffic hunting! > > Lars > > > > > ---------- Forwarded message ---------- > From: Maximilian Stein <m at steiny.biz> > To: tinc at tinc-vpn.org > Cc: > Bcc: > Date: Fri, 20 Mar 2020 19:43:35 +0100 > Subject: Re: High tinc traffic on ethernet without tinc load > Hi Lars, > > Am 20.03.20 um 15:43 schrieb Lars Kruse: > > Did you really try the nice visualizations in the "Statistics" menu? > > These should allow you to see, which protocols and which peers cause the > > traffic. > > > > I am slightly confused, that you already took a look at the traffic, but > you did > > not mention, which type of traffic makes up the bulk of the excessive > packets > > you encountered. You mentioned "a few SSDP packages", but nothing else. > > > > Or did I just overlook it in your emails? > > > > Happy traffic hunting! > > > > Lars > > _______________________________________________ > > yeah, I had a look at all packages, but there are only very few packages > on the virtual tinc link, but a huge amount of packages on the Ethernet > link. When I tcpdump the packages on the ethernet link and on the tinc > link at the same time I see only as few as 100 packages per second (or > less) but more than 3000 packages per second on the ethernet link that I > can relate to tinc. > > So, I came to the conclusion that this high amount of traffic on the > ethernet link is not directly correlated to the actual virtual traffic, > because in other situations, when there is acutally load on the tinc > network, I see only a very moderate rise of the number of packages on > the ethernet link. So, although I do not know much about the tinc > internals, under normal circumstances the number of packages on ethernet > vs those on the virtual tinc adapter seem to correlate linearly. This is > clearly not the case during those high traffic events. > > My current mitigation is to stop some tinc peers for ten seconds and to > start them again afterwards, that usually causes the excessive traffic > to stop without interrupting service too much. > > Cheers, > Maximilian > > > > > > ---------- Forwarded message ---------- > From: Lars Kruse <lists at sumpfralle.de> > To: tinc at tinc-vpn.org > Cc: > Bcc: > Date: Fri, 20 Mar 2020 21:09:18 +0100 > Subject: Re: High tinc traffic on ethernet without tinc load > Hello Maximilian, > > Am Fri, 20 Mar 2020 19:43:35 +0100 > schrieb Maximilian Stein <m at steiny.biz>: > > > My current mitigation is to stop some tinc peers for ten seconds and to > > start them again afterwards, that usually causes the excessive traffic > > to stop without interrupting service too much. > > I am guessing now: the rise of traffic on the ethernet link is caused by > packets being exchanged between the tinc processes (e.g. port 655)? > I think, you did not mention this explicitly, but the effect of a tinc > restart > points in this direction. This information is quite relevant for the > further > discussion, I guess. > > Cheers, > Lars > > > > > ---------- Forwarded message ---------- > From: Maximilian Stein <m at steiny.biz> > To: tinc at tinc-vpn.org > Cc: > Bcc: > Date: Fri, 20 Mar 2020 21:44:12 +0100 > Subject: Re: High tinc traffic on ethernet without tinc load > Yes, exactly. There are lots of packages exchanged between tinc processes > on port 655, accounting to 99 % of the Ethernet traffic, while the virtual > interface stays almost idle. > > Best, > Maximilian > > Am 20. März 2020 21:09:18 MEZ schrieb Lars Kruse <lists at sumpfralle.de>: >> >> Hello Maximilian, >> >> Am Fri, 20 Mar 2020 19:43:35 +0100 >> schrieb Maximilian Stein <m at steiny.biz>: >> >> My current mitigation is to stop some tinc peers for ten seconds and to >>> start them again afterwards, that usually causes the excessive traffic >>> to stop without interrupting service too much. >>> >> >> I am guessing now: the rise of traffic on the ethernet link is caused by >> packets being exchanged between the tinc processes (e.g. port 655)? >> I think, you did not mention this explicitly, but the effect of a tinc restart >> points in this direction. This information is quite relevant for the further >> discussion, I guess. >> >> Cheers, >> Lars >> ------------------------------ >> tinc mailing list >> tinc at tinc-vpn.org >> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> >> _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20200326/b4f845d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: improve MTU probe.diff Type: application/octet-stream Size: 3657 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20200326/b4f845d6/attachment.obj>
Maximilian Stein
2020-Apr-01 15:53 UTC
High tinc traffic on ethernet without tinc load (Maximilian Stein)
Hey PHB, Thanks for your suggestion and your patch.> I think may be cause by MTU proble if you have many peer. you can run > tincd with -d 5 or tincd -n "yournetname" -k INT , check the log file > to see what happen.I have experimented a bit with the tinc.conf options, and apparently this issue is related to broadcasts. I set `Broadcast = no` and `DecrementTTL = yes` and since that time, there has not been any of these traffic spikes. So it might be that they were caused by packages circulating within the network forever. Moreover, I noticed that according to tinc.conf(5) `Forwarding` is set to `internal` by default (I didn't change this option), which explains why my iptables filters on broadcast packages were useless. Would this be consistent with the MTU issue you described? I am hesitating to revert from this functioning setup (I don't need broadcasts), but of course want to support development if it's a real issue. So, if you think it's worth I try, I'd compile tinc with your patch and try it. Best, Max -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20200401/a0b56a6a/attachment.sig>