Hardcoded limit on the number of meta-connections

[Guus Sliepen]

On Tue, Jul 08, 2014 at 10:46:38PM +0100, Graham Cobb wrote:

> > I do agree that if a
> > large fraction of the nodes in the VPN is behind a NAT, it can take
> > quite a time for the current logic to find a node it can connect to.
> 
> Isn't a fairly common scenario a hub and spoke but with a redundant hub?

Yes.

> Nodes A and B are internet servers, with a connection between them.  C1,
> C2, ... Cn are clients, each behind NAT, and each configured to
> ConnectTo A and B.
> 
> Today, the Ci all have two connections: one to each of A and B.  But
> with a connection limit of 3 on A and B, both will be trying to drop the
> connection to Ci to get down to their connection limit.

Again, the AutoConnect feature does not impose a hard limit on the
number of connections. The central nodes will still accept all incoming
connections and will not drop them.

> Presumably the "don't disconnect if this is the last connection for this
> node" test will mean that each Ci will retain one of its connections,
> but only one (some to A, some to B).

First of all, when AutoConnect is enabled on a node, it will never drop
incoming connections, it will only drop outgoing connections. So in your
dual-hub-and-spoke scenario, each Ci will still have two working
outgoing connections to A and B.

> In that case, if a Ci connection goes down, it is isolated until it
> can reestablish a connection (as it is behind NAT, only outbound
> connections work). Will that be attempted immediately?

When the number of connections drops below 3, it will within seconds
attempt to make a new connection.

> Also, is there a way to make sure that the connection between A and B is
> never selected to be dropped (you don't want traffic from A to B routing
> through one of the Ci)?

At the moment only by disabling AutoConnect on A and B. But I will add a
feature to specify mandatory 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: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140709/6ec34fb0/attachment.sig>