Earlier, my tinc topology is this: https://ibb.co/bP1EJa
<https://ibb.co/bP1EJa>, let me explain a little bit:
client configuration:
Name = client
AddressFamily = ipv4
ProcessPriority = high
PingTimeout = 10
TunnelServer = yes
1. All tinc nodes configured with “IndirectData = yes”, and the lines shown on
the picture with arrow means the directional “ConnectTo”, so all the tinc
traffic will go follow the “ConnectTo” indicated on the topology. (a1, a2, a3
will be transit node relay traffic from south to north)
2. The yellow highlighted number indicate the weight for the default route
advertised by server nodes, the lower the preferred; the client is on the
bottom of the diagram
3. Based on the above two points, the traffic to default route will follow
below redundant path prioritized as below:
All fine : client1 > a1 > h1
if h1 down : client1 > a1 > h2
if h1/h2 down : client1 > a1 > server1
same for other node on the top line failed
if a1 down : client1 > a2 > h1
if a1/a2 down : client1 > a3 > h1
if a1/a2/a3 down : client1 > server4
The above is the setup will cause irregular tinc down events, and when the
event happens, the client1 drop all connections to
a1/a2/a3/server4/server5/server6, but the connections between a1/a2/a3 to
h1/h2/server1/server2/server/3 are pretty stable.
But after I changed the tinc topology to this: https://ibb.co/eOS4ZF
<https://ibb.co/eOS4ZF>, the connection from client1 to a1 is much stable,
never drop after couple of days….
> On 14 Sep 2017, at 7:15 AM, Bright Zhao <[email protected]> wrote:
>
> I don't know why, but for my case, I reduced the tinc topology from a complex
> one(which provide layered redundancy) to a very simpled one(one connection),
> and that connection drop disappeared.
>
> Later, let me draw the topology and share the config to you to see if there's
> any findings of the cause.
>
> Guus Sliepen <[email protected] <mailto:[email protected]>>于2017年9月14日
> 周四上午3:20写道：
> On Wed, Sep 13, 2017 at 08:02:11PM +0100, Etienne Dechamps wrote:
>
> > It seems like that kind of problem could be solved by making sure that tinc
> > continues PINGing over TCP metaconnections even when an UDP tunnel is
> > established, to keep the metaconnection alive. In fact I was under the
> > impression that the 1.1 branch already did that or that I had submitted
> > some code to do that at some point in the past, but it looks like I maybe
> > be misremembering things.
>
> Tinc always sends regular PINGs over its metaconnections, regardless of
> what happens with UDP. This has been the case at least since 1.0 was
> released.
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <[email protected] <mailto:[email protected]>>
> _______________________________________________
> tinc mailing list
> [email protected] <mailto:[email protected]>
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
> <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc>
> --
> Sent from iPhone
_______________________________________________
tinc mailing list
[email protected]
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
