tinc devel - Jan 2015 - [RFC] [PATCH] Mode=Switch: add per-VLAN forwarding database

Hi,

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.

The patch is based on tinc 1.0.25.

Any comments?

Regards,
 M. Braun

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tinc-add-vlan-fdb.patch
Type: text/x-diff
Size: 12415 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150106/58d937e9/attachment.patch>
-------------- 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-devel/attachments/20150106/58d937e9/attachment.sig>

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>

Hi,

thanks for the feedback.
> 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?
in the backbone we have HP ProCurve switches and all of them (except for
the oldest series from more than 10 years ago) separate their forwarding
database per vlan. HP calls this "multiple forwarding database".
> 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 destination 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?
Imagine some vlans A and B and some bridge nodes A and B. Bridge node A
only bridges vlan A and bridge node B only bridges vlan B as to avoid
loops. Having different bridge nodes for different vlans is done due to
load balancing.

Now if the Access Point uses its subnet entry for bridge node A, packets
tagged with vlan B will be dropped at bridge node A, as bridge node A
only forwards packets tagged with vlan A (not B). If it would also
forward packets tagged with vlan B, there would be a loop. And I cannot
catch this loop at ebtables level as the origin of the packet (other
bridge node or not) is not indicated. And that's all.

Regards,
 M. Braun