On Sat, Jun 13, 2009 at 11:30 AM, Joakim Tjernlund < [email protected]> wrote:
> "[email protected]" <[email protected]> wrote on 13/06/2009 > 17:57:55: > > > > On Sat, Jun 13, 2009 at 10:03 AM, Joakim > > Tjernlund<[email protected]> wrote: > > > Benny Amorsen <[email protected] <benny%[email protected]>> > wrote on 13/06/2009 01:58:53: > > >> > > >> Joakim Tjernlund <[email protected]> writes: > > >> > > >> > Currently the bridge does not impl. split horizon which will easily > > >> > cause loops when 2 or more VLANs are added from the same physical > interface. > > >> > > >> Why would they cause loops? If your topology isn't loop free, run > > >> spanning tree in the VLAN's. Yet another thing most hardware switches > > >> can't do, incidentally. > > > > > > ehh, connect two Linux bridges that have 2 VLANs in common on the > interswitch connection. > > > > For example, here is a configuration that meets your problem > > description and has no loops: > > > > host A eth0 connected to hostB eth0 > > > > host A: > > brctl add br0 > > brctl addif br0 eth0.1 > > brctl addif br0 eth1 > > brctl add br1 > > brctl addif br1 eth0.2 > > brctl addif br1 eth2 > > Yes, but eth1 and eth2 don't talk. You've been asking how to do private ports on bridges. By definition they wouldn't talk. Below, you ask about mimicking VLAN-capable switch hardware. This does, it represents the case where eth1 and eth2 are untagged ports in VLAN1 and VLAN2, respectively, and eth0 is a trunking port. > > > > > > host B: > > brctl add br0 > > brctl addif br0 eth0.1 > > brctl addif br0 wlan0.1 > > brctl add br1 > > brctl addif br1 eth0.2 > > brctl addif br1 wlan0.2 > > > > Let's compare this to your complaint: > > Two Linux hosts.... check > > Two VLANs in common.... check > > Both VLANs on the inter-switch connection.... check > > > > Nope, there are no loops. > > Of course not. You can always fix what you want somehow but that > doesn't mean that there may be better ways of doing things. You're just confusing the issue with very vague wording of your problem scenario, then claiming it has troublesome loops. Express your scenario as a set of brctl commands or we'll never be discussing the same thing, because we're thinking of the command set that achieves what you want, while you're thinking of the command set that doesn't do what you want without a patch. > > > > > You need to stop calling "a machine running bridging" a "Linux > > bridge". A "bridge", in Linux, is a virtual interface inside a > > machine with the bridging module loaded. There can be more than zero, > > one, or multiple bridges in a single Linux machine. I think that when > > you understand that, all your problems will go away with a simpler > > configuration and no changes to the Linux kernel. > > Aha, I had/have the impression that one bridge instance should mimic > a real bridge, if not you are making some sense. No, a bridge instance is better compared to a VLAN inside a VLAN-capable switch. The switch moves traffic between all ports which are members of the same VLAN, without crossing VLANs. That's what a Linux bridge instance does. Incidentally the Linux way allows you to remap VLAN IDs in the process. For example, you could merge two VLAN trunks (eth1 and eth2), both using VLAN IDs 1-9, such that on the combined trunk (eth0) the eth1 VLANs become 11-19 and the eth2 VLANs become 21-29. On VLAN-capable switches, the VLAN is completely determined by its ID. On Linux, the VLAN interface is determined by a combination of parent interface and VLAN ID, there is not automatically any association between eth0.1 and eth1.1 > But now I start asking myself what are the semantics for a Linux > bridge instance? > > I would really like to know in what situation you would use > the current behavior to forward back VLAN pkgs over the same interface > it was received on? > > Also, I am trying to find where it states that a VLAN is considered its own > physical port. Any pointers? > It is its own "logical interface". Physical interfaces are only different because they are implemented by NIC drivers talking to real hardware, vs virtual interface drivers which are pure software. The rest of the networking stack just looks at logical interfaces. VLANs are virtual interfaces. So are bridge, bonding, tun/tap, and veth virtual machine connections. I'm pretty sure you can have VLANs on a tun/tap interface, in which case there is no physical interface at all. I know you can have VLANs on bonded interfaces, in which case there's more than one underlying physical interface. You talk a lot about "physical port" or "physical interface" but the patch you offered doesn't do what you claim because the vlan_dev_real_dev function doesn't have any guarantee that the return value is a "physical" interface like you think it does.
_______________________________________________ Bridge mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/bridge
