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

Hi

Today our Tinc network saw a network partition when we took one tinc node
down.

We knew there was a network partition since the graph showed a split. This
graph is not very helpful but its what I have at the moment:

http://i.imgur.com/XP2PSWc.png

- (ignore node labeled ignore, since its a dead node anyways)
- node R was shutdown for maintenance
- We saw a network split
- we brought node R back up.
- Tinc didn't restore a mesh and the split remained. The graph was
generated at this point

Some info regarding our config:
- we are using tinc 1.1pre14
- we are using tinc in router mode
- We do not have any ConnectTo variables mentioned in any nodes (maybe this
is our problem)
- All nodes use AutoConnect=yes

How we fixed it:
- we explicitly added some ConnectTo variables to node R
- We reloaded tinc on node R (tinc reload)
- The mesh was restored

Some questions:
- should we have a combination of both ConnectTo and AutoConnect to avoid
such a network split?
- Say we have 3 ConnectTo variables and then AutoConnect=yes, would there
ever be more than 3 connections ? (I read somewhere that AutoConnect will
make upto 3 connections only)

Any other tips and suggestions to avoid such a network split would be
great!

   -nirmal
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170821/e5b77f62/attachment.html>

On Mon, Aug 21, 2017 at 05:37:06PM -0700, Nirmal Thacker wrote:
> Today our Tinc network saw a network partition when we took one tinc node
> down.
> 
> We knew there was a network partition since the graph showed a split. This
> graph is not very helpful but its what I have at the moment:
> 
> http://i.imgur.com/XP2PSWc.png
The graph is very clear.
> Some questions:
> - should we have a combination of both ConnectTo and AutoConnect to avoid
> such a network split?
No, it's a bug in AutoConnect. I've just pushed a fix to the 1.1 branch
that will try to continue to connect to unreachable nodes, even if a
node already has 3 or more connections.
> - Say we have 3 ConnectTo variables and then AutoConnect=yes, would there
> ever be more than 3 connections ? (I read somewhere that AutoConnect will
> make upto 3 connections only)
There can always be more than 3 connections, even when AutoConnect is
enabled.

When starting, tinc will try to make outgoing connections to all nodes
listed in ConnectTo statements. This can be more than 3 nodes. After
that, the AutoConnect algorithm kicks in.

The AutoConnect algorithm tries to regulate the number of established
connections, either by creating more outgoing connections, or by
closing connections that it made itself. It will never close incoming
connections, and it also won't close outgoing connections to a node that
isn't already connected to at least one other node.

Ideally, after a while connections get rearranged such that no node has
more than 3 connections. But this can take a while, or it might never
happen; for example if you have 5 nodes behind NAT, and one public node,
then the public node will always have 5 connections.

-- 
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/20170822/857b8705/attachment.sig>

Hi Guus

Thanks for clarifying. Some follow up questions:

- How do we patch 1.1pre14 with this fix? Or will there be a 1.1pre15 to
upgrade to?
- What is the workaround until we patch with this fix? Using a combination
of AutoConnect and ConnectTo?
- When we use ConnectTo, is it mandatory to have a cert file in the hosts/*
dir with an IP to ConnectTo ?


   -nirmal

On Tue, Aug 22, 2017 at 12:10 PM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Mon, Aug 21, 2017 at 05:37:06PM -0700, Nirmal Thacker wrote:
>
> > Today our Tinc network saw a network partition when we took one tinc
node
> > down.
> >
> > We knew there was a network partition since the graph showed a split.
> This
> > graph is not very helpful but its what I have at the moment:
> >
> > http://i.imgur.com/XP2PSWc.png
>
> The graph is very clear.
>
> > Some questions:
> > - should we have a combination of both ConnectTo and AutoConnect to
avoid
> > such a network split?
>
> No, it's a bug in AutoConnect. I've just pushed a fix to the 1.1
branch
> that will try to continue to connect to unreachable nodes, even if a
> node already has 3 or more connections.
>
> > - Say we have 3 ConnectTo variables and then AutoConnect=yes, would
there
> > ever be more than 3 connections ? (I read somewhere that AutoConnect
will
> > make upto 3 connections only)
>
> There can always be more than 3 connections, even when AutoConnect is
> enabled.
>
> When starting, tinc will try to make outgoing connections to all nodes
> listed in ConnectTo statements. This can be more than 3 nodes. After
> that, the AutoConnect algorithm kicks in.
>
> The AutoConnect algorithm tries to regulate the number of established
> connections, either by creating more outgoing connections, or by
> closing connections that it made itself. It will never close incoming
> connections, and it also won't close outgoing connections to a node
that
> isn't already connected to at least one other node.
>
> Ideally, after a while connections get rearranged such that no node has
> more than 3 connections. But this can take a while, or it might never
> happen; for example if you have 5 nodes behind NAT, and one public node,
> then the public node will always have 5 connections.
>
> --
> 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/20170822/bf08c61c/attachment.html>