Hardcoded limit on the number of meta-connections

[Graham Cobb]

On 08/07/14 21:42, Guus Sliepen 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?

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.

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

Is the impact on traffic to/from Ci any different from today's scenario
in which Ci is connected to both A and B simultaneously?

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

Graham