[RFC] [PATCH] Mode=Switch: add per-VLAN forwarding database

Guus Sliepen guus at tinc-vpn.org
Tue Jan 6 16:53:34 CET 2015


On Tue, Jan 06, 2015 at 12:31:20PM +0100, Michael Braun wrote:

> I'm inter-connecting AccessPoints using a tinc mesh and have bridge-nodes to bridge this vpn into some existing backbone.
> The AccessPoints bridge their users into 802.1q VLANs (per WiFi-Client, there can be multiple VLANs active on each AP) in the tinc mesh, and the bridge nodes bridge some vlans into the backbone.
> Now there is a router in the backbone that uses the same MAC on all VLANs, thus its MAC appears on all bridge nodes.
> As the forwarding database of tinc currently is not aware of vlans, this leads to conflicting subnet entries for the router mac pointing to one of the bridge nodes. Thus, only one subnet will work at a time.
> 
> To resolve this, please find attached a patch that enables tinc to have the VLAN-id included in its SUBNET_MAC entries.
> For backward compatibility, adding the VLAN-id to SUBNET_MAC entries needs to be enabled using a configuration option.

This is an interesting problem. I wonder how you would solve it if you
would have a real (managed) switch instead of tinc to connect the
access points and bridge nodes together?

Your solution basically tells tinc to not route only on the MAC address,
but on MAC+VLAN. That's indeed an elegant solution to your problem.
But what is exactly going wrong? Even though only one subnet works at a
time, packets having the MAC address of that router in the backbone as
the desination address are still being routed towards that router. Is
the problem that this is perhaps not an efficient route, or is there
some real switch along the way that doesn't like an unexpected VLAN tag?

> The patch is based on tinc 1.0.25.

Thank you for the patch. I don't think I'll apply it to the 1.0.x branch
though, but rather to the 1.1 branch, after things have stabilized there.

-- 
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-devel/attachments/20150106/d0c59feb/attachment.sig>


More information about the tinc-devel mailing list