using both ConnectTo and AutoConnect to avoid network partitions

[Nirmal Thacker]

Thanks Guus.

Lets say I wanted to predict a network split. For that purpose I define a
metric called 'reachability' at each node in the tinc mesh.

Reachability = (value returned by 'tinc dump reachable nodes' ) / (value
returned by 'tinc dump nodes')

Would you say that the reachability of a node needs to be very low, for
that node to cause a split in the network when it is taken down?

The reason I ask is, until we find a way to ensure this never happens, I'm
hoping to build something around getting alerting to get this metric at a
regular instance from each node in the network.

And if the hypothesis is correct (low reachability at a node, can cause a
split at that point in the network), then is the 'tinc dump [reachable]
nodes' command fine to execute at a regular (1min - 10min) interval?

At some point we need to decide if we'd like to patch tinc1.1pre14 with the
patch you've provided above, or we wait for an upgrade to tinc1.1pre15. Is
there a timeline of tinc1.1pre15?


   -nirmal

On Thu, Aug 31, 2017 at 1:51 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:

> On Thu, Aug 31, 2017 at 01:37:28PM -0700, Nirmal Thacker wrote:
>
> > If you make the yellow nodes ConnectTo all other nodes, and not have
> > > AutoConnect = yes, and the other nodes just have AutoConnect = yes but
> > > no ConnectTo's, then you will get the desired graph.
> >
> > The reason this approach is not desirable is because it fails at
> > automation. It requires us to add a new line of AutoConnect = <new node
> > that joined tinc> to both yellow nodes everytime a new node node joins,
> > while in the current setup as long as the keys of every new node are
> > exchanged between the new nodes and the yellow nodes, the ConnectTo's can
> > stay constant
>
> That's true. Although it wouldn't be impossible to script that a little,
> for example by adding the following host-up script:
>
> #!/bin/sh
> tinc add ConnectTo $NODE
>
> > > Yes, AutoConnect will still remove outgoing connections that it thinks
> > > are redundant. So even if the initial ConnectTo's will cause nodes to
> > > connect to the yellow ones, after a while they can remove those.
> >
> > Is this optimization also vulnerable to the bug we saw earlier with
> regard
> > to the network split? Or given that the ConnectTo's exist, peer nodes,
> will
> > fall back onto these, thereby 'recovering' in some sense if a network
> split
> > were to occur due to the the AutoConnect bug?
>
> Yes, in 1.1pre14 enabling AutoConnect on all nodes, regardless of how
> many ConnectTo's they have, may result in a split network.
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> 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/20170831/878ebbb7/attachment.html>