tinc Digest, Vol 185, Issue 3

[Peng Haibo]

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>