On Fri, Mar 20, 2015 at 02:07:56PM +0000, Michael Drzal wrote: > I am using tinc to connect together VPCs in AWS across multiple regions and > accounts to provide secure communication. For the most part, it works > great. A few times, I have seen issues where something got into an > unstable state that didn't seem to resolve itself. Shutting down tinc on > all hosts and restarting seemed to do the trick, but I'd like to see if > there is something that I can change with the configuration to mitigate > this. Here is what the issue looks like when it happens with the > hostnames/ips changed: > > Feb 26 07:39:20 host1 [daemon.info] tinc.network[1022]: host2 (1.1.1.1 port > 655) could not flush for 9 seconds (324908 bytes remaining) > Feb 26 07:39:20 host1 [daemon.notice] tinc.network[1022]: Closing connection > with host2 (1.1.1.1 port 655)
It looks like there is a lot of data that host1 wants to send to host2
via TCP, but it is not able to handle all the data in a timely manner.
Tinc killed the connection in an attempt to get rid of the problem.
> Feb 26 07:39:20 host1 [daemon.info] tinc.network[1022]: Trying to connect to
> host2 (1.1.1.1 port 655)
> Feb 26 07:39:20 host1 [daemon.info] tinc.network[1022]: Connected to host2
> (1.1.1.1 port 655)
> Feb 26 07:39:20 host1 [daemon.notice] tinc.network[1022]: Connection with
> host2 (1.1.1.1 port 655) activated
> Feb 26 07:39:20 host1 [daemon.info] tinc.network[1022]: host2 (1.1.1.1 port
> 655) could not flush for 5 seconds (459308 bytes remaining)
Ok, immediately after connecting it tries to send half a megabyte of
data... Looking at the number of hosts and subnets, I would expect
around 60 kB of data being sent to synchronise the state between the
hosts, not 460 kB. Could it be there was a lot of VPN traffic going on at
the same moment? Maybe broadcast traffic?
I suggest adding the following to your configuration files:
Broadcast = no
PingTimeout = 15
This will prevent broadcast traffic from being forwarded. It could be
that with the number of hosts you have, this is adding a significant
amount of network traffic. If you don't need that, it's best to disable
it. The increased PingTimeout will cause tinc to wait a bit longer
before giving up on a connection.
> Please let me know if any other details would help.
If the problem persists, capturing a more detailed log of what tinc is
doing would b every helpful. You can send a running tincd the INT signal
to raise its debug level to 5, and send it again to revert to the value
it had when starting.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
