<div dir="ltr"><div>Thanks Guus. <br></div><div><br></div><div>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.<br></div><div><br></div><div>Reachability = (value returned by 'tinc dump reachable nodes' ) / (value returned by 'tinc dump nodes')<br></div><div><br></div><div>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?</div><div><br></div><div>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. <br></div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">   -nirmal</div></div>
<br><div class="gmail_quote">On Thu, Aug 31, 2017 at 1:51 PM, Guus Sliepen <span dir="ltr"><<a href="mailto:guus@tinc-vpn.org" target="_blank">guus@tinc-vpn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Aug 31, 2017 at 01:37:28PM -0700, Nirmal Thacker wrote:<br>
<br>
> If you make the yellow nodes ConnectTo all other nodes, and not have<br>
> > AutoConnect = yes, and the other nodes just have AutoConnect = yes but<br>
> > no ConnectTo's, then you will get the desired graph.<br>
><br>
> The reason this approach is not desirable is because it fails at<br>
> automation. It requires us to add a new line of AutoConnect = <new node<br>
> that joined tinc> to both yellow nodes everytime a new node node joins,<br>
> while in the current setup as long as the keys of every new node are<br>
> exchanged between the new nodes and the yellow nodes, the ConnectTo's can<br>
> stay constant<br>
<br>
</span>That's true. Although it wouldn't be impossible to script that a little,<br>
for example by adding the following host-up script:<br>
<br>
#!/bin/sh<br>
tinc add ConnectTo $NODE<br>
<span class=""><br>
> > Yes, AutoConnect will still remove outgoing connections that it thinks<br>
> > are redundant. So even if the initial ConnectTo's will cause nodes to<br>
> > connect to the yellow ones, after a while they can remove those.<br>
><br>
> Is this optimization also vulnerable to the bug we saw earlier with regard<br>
> to the network split? Or given that the ConnectTo's exist, peer nodes, will<br>
> fall back onto these, thereby 'recovering' in some sense if a network split<br>
> were to occur due to the the AutoConnect bug?<br>
<br>
</span>Yes, in 1.1pre14 enabling AutoConnect on all nodes, regardless of how<br>
many ConnectTo's they have, may result in a split network.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Met vriendelijke groet / with kind regards,<br>
     Guus Sliepen <<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>><br>
</div></div><br>______________________________<wbr>_________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-<wbr>bin/mailman/listinfo/tinc</a><br>
<br></blockquote></div><br></div>