"richardvoigt@xxxxxxxxx" <richardvoigt@xxxxxxxxx> wrote on 12/06/2009 21:31:08: > > On Fri, Jun 12, 2009 at 8:47 AM, Joakim > Tjernlund<joakim.tjernlund@xxxxxxxxxxxx> wrote: > > "richardvoigt@xxxxxxxxx" <richardvoigt@xxxxxxxxx> wrote on 12/06/2009 15:19:22: > >> > >> On Fri, Jun 12, 2009 at 8:09 AM, Joakim > >> Tjernlund<joakim.tjernlund@xxxxxxxxxxxx> wrote: > >> > Ross Vandegrift <ross@xxxxxxxxxxx> 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. But why should I not be able to add both 4043 and 4044 to the same bridge? I just sent a patch to add split horizon support to the linux bridge. Have a look. More power to the linux bridge that way. Jocke _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
