tinc - Aug 2017 - using both ConnectTo and AutoConnect to avoid network partitions

Thanks Guss, some comments and questions:

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

> 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?


   -nirmal

On Thu, Aug 31, 2017 at 1:27 PM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Thu, Aug 31, 2017 at 10:40:39AM -0700, Nirmal Thacker wrote:
>
> > Following your suggestion we reconfigured our tinc network as follows.
> > Here is a new graph and below is our updated configuration:
> > http://imgur.com/a/n6ksh
> [...]
> > We are concerned that:
> > - We still dont see edges in the graph that show connections between
> every
> > blue labeled node to both the yellow labeled nodes
> >
> > Any reason why we dont see these edges?
>
> 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 there something missing in our configuration?
>
> 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.
>
> > > > - What is the workaround until we patch with this fix? Using
a
> > > combination of AutoConnect and ConnectTo?
> > >
> > > Yes.
>
> I should've elaborated here.
>
> --
> 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/4fa00c09/attachment.html>

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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170831/e2f58dcc/attachment-0001.sig>

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>