similar to: If two identical host get up, what will happen?

Will the later one can't get onto the tinc domain, or either one may get disconnected? I may give a try later to validate this. Sent from iPhone > 在 2017年5月11日，上午1:46，Guus Sliepen <guus at tinc-vpn.org> 写道： > >> On Tue, May 09, 2017 at 05:28:43PM +0800, Bright Zhao wrote: >> >> I mean exactly the same configuration, including the pub-pri key. > > You

Hi, tinc experts abc to def at x.x.x.x port 655 options d weight 540 How’s the 540 weight been calculated? What does it mean? How can I leverage this weight? The d of after options mean direct?

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,

Hi, All Due to some routing rotation purpose, I use crontab to add below info: 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 1 * * * * /usr/sbin/tincd -n myvpn -k 1 * * * * /usr/sbin/tincd -n myvpn --debug=3 30 * * * * sed -i '/54.169.128.0\/17/d' /etc/tinc/myvpn/hosts/aws_sgp

Thank you, that is very helpful. And actually I do have a few further questions regarding this: 1. This weight is not the one specified in Subnet, this should be something related to the host, where can I manually configure this? 2. The weight value is ONLY take round trip latency as the measurement, or including CPU power and other factors into consideration? 3. I don't know how this

Hi, All Recently, one of my tinc client always suffer connection drop, I was suspect the connection was not stable to cause this issue, and BTW, I’ve set the PingTimeout to 10 seconds already, but this situation still happens a lot sometimes, but when the connection drop happens, the connection recovery pretty fast, normally in a minutes. In order to deep dive into the cause, or proven the

Hi, When the meta connection get lost, it’ll be reconnect like below: Trying to re-establish outgoing connection in 5 seconds, and if it’s failed, then the timer will be increased for another try. My question is, how to adjust the reconnect timer, in some cases, the reconnect delay for a while(increase to something longer) will be beneficial for the unstable connection.

Two tinc networks/daemons, and received same subnet from the two daemons, how tinc will choose which one is preferred? And the weight settings in each daemon for subnet will or will not be the judge?

Hi, Tinc expert For use case of multi-tenancy use case, should I use multiple netnames (/etc/tinc/tenant1, /etc/tinc/tenant2/, etc.) for the network, so that even different tenant have overlapped network address will be possible to work in the same physical host? or can not?

Hi, Lars Thanks for your suggestion, will give it a try later to see how it performs. But, yesterday, I did a below test: A ConnectTo B and C, B ConnectTo D, C ConnectTo D; All nodes turned "IndirectData" on in its host configuration, so the tunnel only follow metacomnection instead of direct connect. D announced default route by having the Subnet = 0.0.0.0/0 statement in its host

Due to unknown reason, tinc failed to negotiate into UDP mode when first connecting, but will tinc keep trying/negotiating into UDP? or it has to be restart the tinc in order to start the negotiation process? Best Regards Bright Zhao ✉ -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Reason behind that is we have some use cases wouldn’t like to make some nodes to become the transit node, but there’re some other nodes in the topology act as the transit nodes. So if the tinc node forward subnet update it learning from one side to the other side, then it possible to become transit node if one side only have route to go through it. That node I would call it “spoke-only”

Hi, Guus I noticed th default reconnect for the first time is 5s, if failed the timer will be increase, I would like to know if this timer can be adjusted? The Max Timeout you mentioned seems not exactly the one, from the description below, it looks to me it is the total time for connect to be re-established, if not it trying other tinc daemon? Different tinc deamons have nothing related to

I mean, if I changed pingtimeout on tinc.conf, -kHUP will force the tinc to re-read that parameter into effective? If no, any other ways to make it effective other that kill the process? for tinc 1.0.

An very interesting test did yesterday that, LAN1 and LAN2 setup an tinc VPN which is quite simple(the physical link between tinc nodes are quite stable/fast), and no any application traffic to go through the tinc. Later, I setup smokeping which LAN1 initial 20 ping to LAN2 on a per-minute basis, but as you saw from the below picture, it had packet drop. But if I perform a constantly ping from

I don't know why, but for my case, I reduced the tinc topology from a complex one(which provide layered redundancy) to a very simpled one(one connection), and that connection drop disappeared. Later, let me draw the topology and share the config to you to see if there's any findings of the cause. Guus Sliepen <guus at tinc-vpn.org>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017

I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is natively designed to optimize TCP, instead of TCP-over-TCP, but could you articulate a bit more about the beneficial of “sending host when there is a UDP tinc tunnel” in the middle”? > On 30 Sep 2017, at 11:23 AM, Ryan Mounce <ryan at mounce.com.au> wrote: > > I'm not aware that BBR claims nor

Sure, let me reply all here for my finding. @Lars @Guus A’s tinc.conf: Name = bright AddressFamily = ipv4 ConnectTo = aly_hk A’s tinc-up: #!/bin/sh ifconfig $INTERFACE 10.0.0.110 netmask 255.255.255.0 A’s host config: Subnet = 10.0.0.110/32 (VPN address) Subnet = 192.168.31.0/24 (LAN address) IndirectData = yes (enabled for every tinc nodes) The node aly_hk (vpn address 10.0.0.3) connects with

Hi, Guus I don’t quite understand what you describe below, to me, no matter tinc or any other router/PC get an IP packet, it will go to check with its route table, to match the destination IP against the route table for the next hop, if I put "ip route add default via <C’s VPN IP address> dev $INTERFACE", I thought tinc will match the packet’s destination IP to the “default”, and

And, I ran a constant ping from the tinc client’s IP to the tinc server’s IP, it shows, the pings are all successfully back and forth, no any packet loss during the connection drop happens, so will this help to exclude any NAT/firewall cause the connection drop? And as you saw from the earlier screen shot, when it happens, it drop all tinc connections, and those connections are for different