tinc - May 2017 - How tinc route traffic when two subnets are identical?

Hi, All

Two remote tinc nodes(A, B) advertised the same route to the Tinc domain, and
the local tinc node(C) has two ConnectTo to point to those two remote nodes, and
I found, and let’s assume connection from C to A is better than C to B (better
latency from ping) :
1. when two remote nodes are up, the traffic always send through A
2. when A is down, traffic send through B
3. when A recovered, traffic send back to A
4. when B is down, traffic will go through A
5. when B is recovered, traffic not switch to B, instead, still goes on A.

So I would like to know, the underlying mechanism for equal path of Subnet is
what? Tinc will test the latency, or something else to make the decision?

BTW, I know if I put weight on the Subnet, it will select by weight, but in my
case, same weight.

Hello,


Am Thu, 4 May 2017 15:45:52 +0800
schrieb Bright Zhao <startryst at gmail.com>:
> [..]
> 
> So I would like to know, the underlying mechanism for equal path of Subnet
is
> what? Tinc will test the latency, or something else to make the decision?
tinc only _allows_ certain traffic to pass - it does no routing on its own.

You will need to manipulate your routing setup with the subnet-up/down scripts:
* assign different weights to both subnets
* use the weight for the route metric
* make sure to add the route in subnet-up and remove it in subnet-down

Cheers,
Lars

On Thu, May 04, 2017 at 03:45:52PM +0800, Bright Zhao wrote:
> Two remote tinc nodes(A, B) advertised the same route to the Tinc domain,
and the local tinc node(C) has two ConnectTo to point to those two remote nodes,
and I found, and let’s assume connection from C to A is better than C to B
(better latency from ping) :
> 1. when two remote nodes are up, the traffic always send through A
> 2. when A is down, traffic send through B
> 3. when A recovered, traffic send back to A
> 4. when B is down, traffic will go through A
> 5. when B is recovered, traffic not switch to B, instead, still goes on A.
> 
> So I would like to know, the underlying mechanism for equal path of Subnet
is what? Tinc will test the latency, or something else to make the decision?
It is currently unspecified what tinc will do when you have two nodes
with exactly the same Subnet. The only guarantee currently is that
traffic goes to one of the nodes that is online.

The implementation currently has the effect that, from the set of nodes
that is online, tinc will choose the one that has the lowest Name (when
sorted alphabetically). So if both A and B are up, A will always be
preferred, because "A" sorts before "B". However, please do
not rely on
this. In the future, this might change to route towards the closest
node.

In general, tinc tries its best to ensure that traffic reaches *a*
destination node, but it does not spend much effort in finding out what
the *best* node is if there are multiple possibilities, and similarly
when routing traffic to a given node, it tries its best to find *a*
working path to it, but not necessarily the *best* path (although it
does favor direct connections, which are *usually* optimal).

-- 
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/20170504/536478c0/attachment.sig>

2017-05-04 14:00 GMT+02:00 Lars Kruse <lists at
sumpfralle.de>:
>
> tinc only _allows_ certain traffic to pass - it does no routing on its own.
>
> You will need to manipulate your routing setup with the subnet-up/down
scripts:
> * assign different weights to both subnets
> * use the weight for the route metric
> * make sure to add the route in subnet-up and remove it in subnet-down
Or use mode=switch and a proper routing protocol.

On Thu, May 4, 2017, at 09:04, Guus Sliepen wrote:
> It is currently unspecified what tinc will do when you have two nodes
> with exactly the same Subnet. The only guarantee currently is that
> traffic goes to one of the nodes that is online.
> 
> The implementation currently has the effect that, from the set of nodes
> that is online, tinc will choose the one that has the lowest Name (when
> sorted alphabetically). So if both A and B are up, A will always be
> preferred, because "A" sorts before "B". However,
please do not rely on
> this. In the future, this might change to route towards the closest
> node.
> 
> In general, tinc tries its best to ensure that traffic reaches *a*
> destination node, but it does not spend much effort in finding out what
> the *best* node is if there are multiple possibilities, and similarly
> when routing traffic to a given node, it tries its best to find *a*
> working path to it, but not necessarily the *best* path (although it
> does favor direct connections, which are *usually* optimal).
I'm a tinc n00b, not yet actually using it yet but investigating as it
seems it will solve a lot of problems with our current solutions.

Can I rely on this configuration as a lazy man's failover solution? I
understand I can't set priorities or anything of that sort, I just want
a simplistic failover if one or the other internet connection dies for
locations that have multiple external routes/connections.

There might be a better way, I'm still wrapping my head around
everything.