[Bridge] RFC: Simple Private VLAN impl.

[Daniel Robbins]

On Wed, Jun 10, 2009 at 9:32 AM, Joakim Tjernlund <
joakim.tjernlund at transmode.se> wrote:

> Stephen Hemminger <shemminger at vyatta.com> wrote on 10/06/2009 16:45:42:
> >
> > On Wed, 10 Jun 2009 15:32:06 +0200
> > Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
> >
> > >
> > > Even though some folks on this list thinks ebtables should be used
> > > to deploy Private VLAN I find using ebtables a bit clumsy.
> > >
> >
> > I prefer ebtables be used to "patch" bridge to do these kind
> > of special case things.  Remember any code that is put in mainline
> > adds additional API's and long term support burden.
>
> I am not sure this is so special anymore. I know that this
> adds "support burden" but so does a lot of stuff in the kernel.
>
> Have anybody managed to do Private VLAN with several switches by
> just using ebtables? Seems like most people here thinks that
> ebtables is the right tool but none has provided any examples
> on how to do it so I am starting to think that noone is so the
> claim to just use ebtables might be false.
>
>  Jocke


Hi Jocke,

I have not yet done this with ebtables but I plan to in the next two weeks.
I am also interested in doing some testing for your patch, do see if it is
better or preferable to the ebtables approach.

I do think that having the bridge code do PVLANs could end up being better.
In particular, I think this could be *very* useful for virtualization, where
you are adding/removing interfaces from the bridge often. Why? Because it
eliminates the need to dynamically create/remove ebtables rules and keep
them in sync with the interfaces on the bridge.

Stephen, I think one needs to consider the complexity of the patch in terms
of maintenance -- but it's important to note that the bridge code in the
kernel is there to serve *us* and be useful to *us*. In other words, the
highest priority of the code is to be useful. While it is important for the
code to be maintainable, this should never be the highest priority. This is
a very small patch so rejecting it on the basis that it increases the
maintenance burden does not seem like a legitimate argument. And if this
approach is much simpler in practice then using ebtables, then I think
something like this should be added.

I do think that if the bridging code can take care of layer 2 PVLANs, and I
only have to worry about locking down layer 3 via iptables, then this could
be a superior solution to using ebtables.

Regards,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20090611/4a112fee/attachment-0001.htm