High tinc traffic on ethernet without tinc load

[Maximilian Stein]

Hi everybody,

I am operating a tinc network with nearly 200 peers connected over the
internet. Some peers are permanently connected and offer a public, fixed
IP ("servers") while others are behind NAT firewalls ("clients") and
connect to the former primarily.

Unfortunately, sometimes (~ once a day) the traffic on the ethernet
links seems to explode way beyond whats normal (normal: < 50 KB/s, high
load > 1 MB/s). Interestingly, this traffic only manifests on the
ethernet link, but not on the virtual tinc link. I did many tcpdump
recordings and within a 10 seconds recording interval during such a high
traffic phase I typically see less than 1000 packets on the virtual tinc
adapter and 30.000 packets on the physical ethernet adapter (99 % to or
from a tinc peer in my network). Excessive package exchange happens with
about two dozens peers.

As I cannot look into the encrypted tinc packages of course, it's hard
to tell (at least for me) what is actually going on in the network. I
looked at a thread on a similar topic last year [1] on the mailing list,
but I don't have any recursive tinc traffic on my tinc adapter (actually
blocked by iptables). However, I do see some SSDP broadcast packages
(but again, there are way fewer packages on the virtual tinc link than
on the physical ethernet link).

Do you have any idea about how to analyze the situation further? Or
about the actual reasons behind the issue?

My configuration is basically as attached. While the "servers" have the
tinc public keys of all members of the network, the "clients" typically
only have the keys of the servers, if this is important.

Thank you very much for your help!

Cheers,
Max


[1]: https://www.tinc-vpn.org/pipermail/tinc/2019-May/005420.html


-------------- 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/20200319/3eb6806f/attachment.sig>