On Wed, Jun 10, 2009 at 9:32 AM, Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx> wrote:
Stephen Hemminger <shemminger@xxxxxxxxxx> wrote on 10/06/2009 16:45:42:
>I am not sure this is so special anymore. I know that this
> On Wed, 10 Jun 2009 15:32:06 +0200
> Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx> 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.
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
_______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
