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

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

On Wed, Jan 07, 2015 at 09:49:59AM +0100, M. Braun wrote:
> > 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".
Aha. I'm wondering whether it's even necessary to make it optional, as
it seems to me that if you use VLANs, this behaviour is always
preferable over not looking at the VLAN tag. But maybe there are
situations where this is not the case?
> > [...] 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.
Ok, that's clear.

-- 
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/20150107/04d1b67d/attachment.sig>

Am 07.01.2015 um 13:03 schrieb Guus Sliepen:
> Aha. I'm wondering whether it's even necessary to make it optional,
as
> it seems to me that if you use VLANs, this behaviour is always
> preferable over not looking at the VLAN tag. But maybe there are
> situations where this is not the case?
I've only made it optional for backward compatibility, as otherwise
clients without this patch could not parse the new SUBNET_MAC messages
and thus not learn the mac. I don't know a use case which would require
this feature disabled.

With kind regards,
 M. Braun