Switched tinc VPN question

Guus Sliepen guus at tinc-vpn.org
Mon Oct 29 18:31:48 CET 2012


On Mon, Oct 29, 2012 at 04:25:59PM +0200, Valentin Bud wrote:

> My setup is as follows. I have a total of 4 servers. 2 of them are
> directly connected with one Gbps link. The other two of them are located
> elsewhere and they are connected via WAN connection. I would mention
> that the latter two servers are in the same Data Center provider and
> have 100Mbps link between them. 
> 
> Each of those 4 servers have an OpenvSwitch instance and a few VLANs. I
> want to extend the Layer 2 network over the WAN with VPN tunnels using
> tinc because this would ease firewall management, address assignment and
> enable VM migration.

And I assume the two that are directly connected via gigabit also have their
OpenvSwitch instances connected together via their LAN interfaces?

> In my first approach I have configured A to ConnectTo C and D, B to
> ConnectTo C and D, C to ConnectTo A,B,D and D to ConnectTo A,B,C.
[...]
> Without STP after starting up the tinc daemons on all 4 machines a
> broadcast storm results. This was expected. Adding tinc as a port to the
> switch basically transforms the network in 4 switches connected each
> other, thus giving a loop.

If the switches on A and B would only be connected to each other via tinc, then
there would be no broadcast storm.

> Activating STP on all 4 OvS switches resulted
> in endless STP Root Bridge election. So this approach, connecting all
> four together, didn't work out.

This is strange, that should just work... But check that each OvS instance has
a unique MAC address, and/or give each instance a different priority.

> My second approach was to connect only A to C, C to D and D to B.
> I have activated STP from start and after the Root Bridge election the
> `tinc` port on B is in STP_BLOCK status, which is good. I have
> connectivity throughout the entire network.

How you set up ConnectTo's should not matter at all... there should be no
difference between the first and the second approach.

> There is also a third approach. Connecting A to C with one tinc tunnel,
> C with D with another, and D with B with yet another tunnel. This would
> bring a little bit of complexity to the tinc setup because it requires
> one tunnel for each two nodes I want to connect. 
> 
> My question is, which approach would be better? I am asking this because
> in the second approach I have one `tinc` on node C that connects A to C
> and C to D. If for example that interface gets on STP_BLOCK status no
> traffic will flow from A to C or from C to D. 

The tinc interface on node C should never get the STP_BLOCK status, since there
is no loop that would allow a packet sent out via the tinc interface to come
back on /another/ port on C's switch.

> Are my assumptions right or am I completely out of the track here? Is it
> really necessary to have one `tinc` interface between two nodes, or will
> it work reliably only with one?

In principle it should work with only one tinc interface per node.

-- 
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: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20121029/d9452241/attachment.pgp>


More information about the tinc mailing list