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

Guus Sliepen guus at tinc-vpn.org
Wed Jan 7 13:03:10 CET 2015


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>


More information about the tinc-devel mailing list