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>
Pierre Emeriaud
2017-May-04 18:12 UTC
How tinc route traffic when two subnets are identical?
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-downOr 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.
Reasonably Related Threads
- How tinc route traffic when two subnets are identical?
- How tinc route traffic when two subnets are identical?
- How tinc route traffic when two subnets are identical?
- Identical Subnets with equal weight
- What exactly is the meaning of "Subnet" parameter in tinc/$NETNAME/hosts/$SOMEHOSTNAME?