[Bridge] RFC: Simple Private VLAN impl.

richardvoigt at gmail.com richardvoigt at gmail.com
Fri Jun 12 12:31:08 PDT 2009


On Fri, Jun 12, 2009 at 8:47 AM, Joakim
Tjernlund<joakim.tjernlund at transmode.se> wrote:
> "richardvoigt at gmail.com" <richardvoigt at gmail.com> wrote on 12/06/2009 15:19:22:
>>
>> On Fri, Jun 12, 2009 at 8:09 AM, Joakim
>> Tjernlund<joakim.tjernlund at transmode.se> wrote:
>> > Ross Vandegrift <ross at kallisti.us> wrote on 12/06/2009 14:52:14:
>> >>
>> >> On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
>> >> > Yes, sets would be nice. However I wonder if this case isn't a bug
>> >> > in any case:
>> >> > Consider these VLANS:
>> >> >  eth0.4042
>> >> >  eth0.4043
>> >> >  eth0.4044
>> >> >
>> >> > Add them to a bridge and the bridge will pass pkgs between them, right?
>> >> > However no real switch I know would do that because they are on
>> >> > the same physical interface.
>> >>
>> >> No, that's not a problem at all.  Any dot1q bridge would behave
>> >> exactly as Linux does if it supports VLAN bridging (which at least
>> >> Cisco, Nortel, and Juniper do in varying capcities).
>> >>
>> >> Moreover, any dot1q bridge that doesn't support VLAN bridging can
>> >> (be careful!) have the feature added by adding one untagged port into
>> >> each VLAN and cabling them to a dot1d bridge.  Linux just saves you
>> >> cables.
>> >>
>> >> The split-horizon rule is for flooding into a broadcast domain.  For
>> >> purposes of split-horizon flooding, each of your VLAN interfaces are
>> >> physical interfaces - a broadcast frame arrived on one of the ports
>> >> and needs to be flooded out all of the others.
>> >
>> > hmm, then I don't understand how Private VLAN is supposed to work over
>> > the interswitch port. If I understand you correctly, a Bcast pkg arriving
>> > on VLAN 4042 will be forwarded back over 4043 and 4044 VLANs, then the
>> > receiving switch will forward back these to pkgs once again and
>> > it never stops?
>>
>> Only one switch would be configured to bridge between VLANs.
>>
>> VLANs are by default (in the absence of enabling bridging) isolation barriers.
>>
>> Most entry-level physical switches (basic VLAN support only) consider
>> all VLANs with the same ID to be members of the same bridge, there is
>> one such bridge for each configured VLAN.  Linux allows you to have
>> this operation trivially, but allows far more powerful combinations.
>>
>> All this "promiscuous VLAN" stuff is just an attempt to bring some of
>> the features of software bridging (e.g. Linux) to hardware switches in
>> a standard way.
>
> OK, this would suggest that the default mode of the linux bridge is wrong
> and can cause loops and other ill effects. A user should not have
> to resort to ebtables just to turn off this behaviour.
>
>  Jocke

The default mode of linux bridging is just fine.  I'm suspecting you
have followed some complicated example setup which wasn't appropriate
for your environment and broke things.

If you want linux to act like a physical switch:

add ethN.0 to br0
add ethN.1 to br1
add ethN.j to brj

all VLANs will be isolated from each other just like a simple
VLAN-capable switch.

If you don't want traffic from VLAN 4042 to go out over VLAN 4043,
don't add them to the same bridge instance.


More information about the Bridge mailing list