Hi,
On 31.12.2015 16:01, Guus Sliepen wrote:
If, on each node, you ConnectTo all other
nodes, that will cause tinc to generate a lot of metadata. However, you
don't need to do that, only a few ConnectTo statements is usually enough.
If you have a few central nodes to which all other nodes ConnectTo, that
should work fine as well.
~40 ConnectTo lines. When I reduce the ConnectTo lines to say 5 nodes,
will tinc still use the Address= lines to form a full mesh? So when A &
B ConnectTo C, A sending data to B will still become direct as long as A
or B has an Address= line?
Yet it shouldn't crash and burn like that :-)
Topology is roughly like this:
stack of physical servers (tincd, tincd, tincd, ...)
-> virtual servers (more tincd, tincd, tincd, ...)
internet Uplink A, NAT for IPv4, some static IPv6
stack of physical servers (tincd, tincd, tincd, ...)
-> virtual servers (more tincd, tincd, tincd, ...)
internet Uplink B, IPv4 only location, NAT for some IPv4s
satellite root servers (tincd)
-> virtual servers (tincd, tincd, tincd, ...)
internet Uplink C, D, E, ... again some NAT, some not
Now imagine Uplink A failing for some time. Then recovering. Many tincds
trying to ConnectTo many other tincds. VPN dead.
As for logs, I have also found some of these:
tinc.vpn-13[4578]: Old connection_t for server1053 (x.x.x.x port y)
status 0010 still lingering, deleting...
But the crash starts out with connection resets, like this between two
nodes:
server1070 (virtual server on Uplink B):
Dec 30 10:14:52 xxx tinc.vpn-13[4578]: Metadata socket read error for
server1073 (x.x.x.x port y): Connection reset by peer
server1073 (physical server on Uplink A):
Dez 30 10:17:13 xxx tincd[1124]: Flushing meta data to server1070
(x.x.x.x port y) failed: Connection reset by peer
And from that point on, almost exclusively the latter random connection
resets on all nodes, with some "old connection_t" until daemons are
stopped, restarted.
I will try reducing the ConnectTo lines to a sane set of highly
available, well connected physical servers.
Happy new year and thanks for the hint,
Pierre Beck
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
