multithreading, subnet weights, logging info

[Guus Sliepen]

On Mon, Mar 13, 2017 at 10:43:58AM -0700, Ryan, Justin wrote:

> Bumping this in the hope someone can help me.

Oops. I should have answered that some time ago...

> If all the questions are too much, could anyone answer #3: Is there any way
> to have multiple tinc daemons active-active advertising the same subnet

Yes.

> with traffic distributed between the two?

No, it only does failover, no load distribution.

> > 1. Could anyone give an explanation (or point to documentation) of the
> > differences between Connections, Nodes, and Edges in the USR1/2 logging,
> > and the various information in there?

Connections are the "meta-connections" from the manual. These are TCP
connections that tinc nodes use to exchange information with each other
about all other nodes in the VPN. It can also be used for data traffic,
but only if UDP traffic between nodes is not working. You don't need to
have a Connection to all other nodes. In the USR1 log, it shows you only
the meta-connections the local node has with other nodes.

Nodes are the tinc daemons in the VPN. In the USR2 output, this also
shows information about IP address and encryption parameters used for
UDP communication with those nodes.

Edges are actually the same as Connections, but in the USR2 log it shows
you all known Connections in the VPN.

> > 2. Connections appears to match the list of ConnectTo hosts in the main
> > config file -- does this mean this node can only send packets (meta and
> > data connections) directly to those hosts, and that packets destined to
> > others will be relayed through the ConnectTo hosts?

No, if possible tinc will always try to send packets directly to the
destination node via UDP, regardless of the ConnectTo hosts.

> > "nexthop" seems to confirm this -- only Connections are nexthops -- but
> > then ADD_EDGE and REQ_KEY meta messages (as documented here
> > https://www.tinc-vpn.org/documentation/The-meta_
> > 002dprotocol.html#The-meta_002dprotocol) seem to imply direct data
> > packets are possible.

It's true that only Connections are nexthops. But nexthops are just the
next hop in the meta connection graph, it is used as a fallback if no
other form of communication with another node works.

> > 3. What is the routing behavior when multiple nodes advertise the same
> > subnet at the same weight? I think this is it: https://github.com/
> > gsliepen/tinc/blob/master/src/subnet.c#L87-L97, and it means that it's a
> > lexical comparison between names, which will always be the same. We would
> > prefer they be load balanced, due to...

Indeed, if the weights are identical, in tinc 1.0.x they're lexically
ordered.

> > 4. Is it correct that tinc 1.0 is still single-threaded? I've seen some
> > references to it becoming multithreaded, but have only ever observed it
> > working on one cpu at a time, which typically is a bottleneck before
> > bandwidth.

Yes, it's still single-threaded.

-- 
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/20170313/30da034f/attachment.sig>