[Bridge] [PATCH] [bridge] Add split horizon

[Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

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.
Impl. split horizon and add /sys/class/net/br0/bridge/split_horizon
to turn it off.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
Leaving for 1 week vacation next week, but feel free to
comment and/or test.

 Jocke

 net/bridge/br_forward.c  |   12 +++++++++++-
 net/bridge/br_if.c       |    2 +-
 net/bridge/br_private.h  |    1 +
 net/bridge/br_sysfs_br.c |   26 ++++++++++++++++++++++++++
 4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index d2c27c8..cfa1f7e 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -22,7 +22,17 @@
 static inline int should_deliver(const struct net_bridge_port *p,
 				 const struct sk_buff *skb)
 {
-	return (skb->dev != p->dev && p->state == BR_STATE_FORWARDING);
+	struct net_device *indev = skb->dev;
+	struct net_device *todev = p->dev;
+
+	if (p->br->flags & BR_SPLIT_HORIZON) {
+		if (indev->priv_flags & IFF_802_1Q_VLAN)
+			indev = vlan_dev_real_dev(indev);
+		if (todev->priv_flags & IFF_802_1Q_VLAN)
+			todev = vlan_dev_real_dev(todev);
+	}
+
+	return (indev != todev && p->state == BR_STATE_FORWARDING);
 }
 
 static inline unsigned packet_length(const struct sk_buff *skb)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 727c5c5..f23e338 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -203,7 +203,7 @@ static struct net_device *new_bridge_dev(struct net *net, const char *name)
 	br->topology_change = 0;
 	br->topology_change_detected = 0;
 	br->ageing_time = 300 * HZ;
-
+	br->flags = BR_SPLIT_HORIZON;
 	br_netfilter_rtable_init(br);
 
 	INIT_LIST_HEAD(&br->age_list);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index b6c3b71..2c99877 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -98,6 +98,7 @@ struct net_bridge
 #endif
 	unsigned long			flags;
 #define BR_SET_MAC_ADDR		0x00000001
+#define BR_SPLIT_HORIZON	0x00000002
 
 	/* STP */
 	bridge_id			designated_root;
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 603d892..d0eebc1 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -344,6 +344,31 @@ static ssize_t store_flush(struct device *d,
 }
 static DEVICE_ATTR(flush, S_IWUSR, NULL, store_flush);
 
+static ssize_t show_split_horizon(struct device *d,
+				  struct device_attribute *attr, char *buf)
+{
+	struct net_bridge *br = to_bridge(d);
+	int val = !!(br->flags & BR_SPLIT_HORIZON);
+
+	return sprintf(buf, "%d\n", val);
+}
+static int set_split_horizon(struct net_bridge *br, unsigned long val)
+{
+	if (val)
+		br->flags |= BR_SPLIT_HORIZON;
+	else
+		br->flags &= ~BR_SPLIT_HORIZON;
+	return 0;
+}
+
+static ssize_t store_split_horizon(struct device *d,
+				   struct device_attribute *attr,
+				   const char *buf, size_t len)
+{
+	return store_bridge_parm(d, buf, len, set_split_horizon);
+}
+static DEVICE_ATTR(split_horizon, S_IRUGO | S_IWUSR, show_split_horizon, store_split_horizon);
+
 static struct attribute *bridge_attrs[] = {
 	&dev_attr_forward_delay.attr,
 	&dev_attr_hello_time.attr,
@@ -363,6 +388,7 @@ static struct attribute *bridge_attrs[] = {
 	&dev_attr_gc_timer.attr,
 	&dev_attr_group_addr.attr,
 	&dev_attr_flush.attr,
+	&dev_attr_split_horizon.attr,
 	NULL
 };
 
-- 
1.6.2.3

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Benny Amorsen]

Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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.


/Benny

Re: [Bridge] [PATCH] [bridge] Add split horizon

[richardvoigt]

On Fri, Jun 12, 2009 at 4:26 PM, Joakim
Tjernlund<Joakim.Tjernlund@transmode.se> wrote:
> 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.

I call shenanigans.  Got multiple VLANs from the same physical
interface added to a bridge and no loops, almost no trouble of any
sort.  A second bridge on the same router has loops, uses spanning
tree to shut one VLAN down selectively (to automatically bypass a
traffic shaper appliance with a history of failure) and the only
trouble is that the PDUs sent by spanning tree cause klog warnings
when they come back to the other VLAN of the same physical interface.

And I don't think split horizon means what you think it does.

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Jonathan Thibault]

I also use multiple vlans as part of a bridge with no loop and it works 
rather well except for one very strange thing.  If I have two separate 
tagged vlans on the same switch port, the bridge will stop relaying some 
arp replies to those two vlans.  The current network layout doesn't 
require me to have more than one tagged vlan on any switch port except 
the one headed into the bridge interface, so I can work around the issue 
but to date I have not found the cause of this.  We tried different 
NICs, different kernel versions, etc.

As far as the bridge is concerned, arp replies do go through.  But if I 
sniff traffic out of its switch facing interface (with a hub), the 
replies never actually make it onto the wire.

So while I agree that it works for most people, there are situations 
where having multiple vlans bridged might not do what you expect.

Jonathan

richardvoigt@gmail.com wrote:
> On Fri, Jun 12, 2009 at 4:26 PM, Joakim
> Tjernlund<Joakim.Tjernlund@transmode.se> wrote:
>> 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.
> 
> I call shenanigans.  Got multiple VLANs from the same physical
> interface added to a bridge and no loops, almost no trouble of any
> sort.  A second bridge on the same router has loops, uses spanning
> tree to shut one VLAN down selectively (to automatically bypass a
> traffic shaper appliance with a history of failure) and the only
> trouble is that the PDUs sent by spanning tree cause klog warnings
> when they come back to the other VLAN of the same physical interface.
> 
> And I don't think split horizon means what you think it does.
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 01:58:53:
>
> Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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.
What happens?

  Jocke

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Benny Amorsen]

lør, 13 06 2009 kl. 17:03 +0200, skrev Joakim Tjernlund:
> Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 01:58:53:
> >
> > Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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.
> What happens?

"If your topology isn't loop free, run spanning tree in the VLAN's."


/Benny

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 17:12:25:
>
> lør, 13 06 2009 kl. 17:03 +0200, skrev Joakim Tjernlund:
> > Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 01:58:53:
> > >
> > > Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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.
> > What happens?
>
> "If your topology isn't loop free, run spanning tree in the VLAN's."

That would just disable one of the VLANs so the bride won't receive
any more pkgs over that VLAN.

I would really like to read up on the claim that each VLAN is also a physical port.
Any pointers?

 Jocke

Re: [Bridge] [PATCH] [bridge] Add split horizon

[richardvoigt]

On Sat, Jun 13, 2009 at 10:03 AM, Joakim
Tjernlund<joakim.tjernlund@transmode.se> wrote:
> Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 01:58:53:
>>
>> Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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

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.

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.



> What happens?
>
>  Jocke
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 13/06/2009 06:39:50:
>
> On Fri, Jun 12, 2009 at 4:26 PM, Joakim
> Tjernlund<Joakim.Tjernlund@transmode.se> wrote:
> > 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.
>
> I call shenanigans.  Got multiple VLANs from the same physical

No idea what that means, nothing good I suspect :)

> interface added to a bridge and no loops, almost no trouble of any
> sort.  A second bridge on the same router has loops, uses spanning
> tree to shut one VLAN down selectively (to automatically bypass a
> traffic shaper appliance with a history of failure) and the only
> trouble is that the PDUs sent by spanning tree cause klog warnings
> when they come back to the other VLAN of the same physical interface.

ehh, not sure, but this doesn't sound like you have two Linux bridges
connected or you do but STP has closed one of the VLAN interfaces.

>
> And I don't think split horizon means what you think it does.

hmm, what does it mean then? Googling suggest that split horizon prevents
a pkg to be forwarded back over the same interface.
Perhaps you have a better name?

    Jocke

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 13/06/2009 17:57:55:
>
> On Sat, Jun 13, 2009 at 10:03 AM, Joakim
> Tjernlund<joakim.tjernlund@transmode.se> wrote:
> > Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 01:58:53:
> >>
> >> Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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.

>
> 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 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.
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?

 Jocke

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Ross Vandegrift]

On Sat, Jun 13, 2009 at 05:45:47PM +0200, Joakim Tjernlund wrote:
> I would really like to read up on the claim that each VLAN is also a physical port.
> Any pointers?

Note that you added the VLAN tagged subinterface to the bridge.  Using
brctl's functions, you'll be able to see the port numbers assigned to
each port.  You'll be able to display the MACs learned on each port,
along with each port's ID.

Ross

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Benny Amorsen]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 17:12:25:

>> "If your topology isn't loop free, run spanning tree in the VLAN's."
>
> That would just disable one of the VLANs so the bride won't receive
> any more pkgs over that VLAN.

Why don't you try it and find out?

Make eth0.100 and eth0.101 on one machine, bridge them as br0, turn
spanning tree on. Do the same thing on the second machine. Connect the
two machines. Be enlightened.

> I would really like to read up on the claim that each VLAN is also a physical port.
> Any pointers?

What claim?


/Benny

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Benny Amorsen]

Benny Amorsen <benny+usenet@amorsen.dk> writes:

> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
>> Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 17:12:25:
>
>>> "If your topology isn't loop free, run spanning tree in the VLAN's."
>>
>> That would just disable one of the VLANs so the bride won't receive
>> any more pkgs over that VLAN.

Ok I reread this, and what you are saying means that you do understand
what goes on. I.e. you understand that your "split horizon" is
unnecessary. So what is the point?


/Benny

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

Ross Vandegrift <ross@kallisti.us> wrote on 13/06/2009 18:56:40:
>
> On Sat, Jun 13, 2009 at 05:45:47PM +0200, Joakim Tjernlund wrote:
> > I would really like to read up on the claim that each VLAN is also a physical port.
> > Any pointers?
>
> Note that you added the VLAN tagged subinterface to the bridge.  Using
> brctl's functions, you'll be able to see the port numbers assigned to
> each port.  You'll be able to display the MACs learned on each port,
> along with each port's ID.

And ...? Sorry, but I don't see anything about VLAN==physical interface.
I suppose the MACs learned will be different, but how does that matter?

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 18:57:13:
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
> > Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 17:12:25:
>
> >> "If your topology isn't loop free, run spanning tree in the VLAN's."
> >
> > That would just disable one of the VLANs so the bride won't receive
> > any more pkgs over that VLAN.
>
> Why don't you try it and find out?
>
> Make eth0.100 and eth0.101 on one machine, bridge them as br0, turn
> spanning tree on. Do the same thing on the second machine. Connect the
> two machines. Be enlightened.

I am not at work now so you will have to enlighten me.

>
> > I would really like to read up on the claim that each VLAN is also a physical port.
> > Any pointers?
>
> What claim?

Oh, I see that it was Ross who made that claim. You don't agree? If so how
do you explain that is OK to broadcast the same pkg back on that same physical interface?

 Jocke

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Benny Amorsen]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> Oh, I see that it was Ross who made that claim. You don't agree? If so how
> do you explain that is OK to broadcast the same pkg back on that same physical interface?

Why wouldn't it be? If you don't like it you can use ebtables to turn it
off.

So far I haven't seen a real-world use case for NOT passing the packets
out on the same interface (except for the case solved with STP), but I
have seen plenty of real world networks where it was necessary.


/Benny

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Ross Vandegrift]

On Sat, Jun 13, 2009 at 08:32:31PM +0200, Joakim Tjernlund wrote:
> Ross Vandegrift <ross@kallisti.us> wrote on 13/06/2009 18:56:40:
> >
> > On Sat, Jun 13, 2009 at 05:45:47PM +0200, Joakim Tjernlund wrote:
> > > I would really like to read up on the claim that each VLAN is also a physical port.
> > > Any pointers?
> >
> > Note that you added the VLAN tagged subinterface to the bridge.  Using
> > brctl's functions, you'll be able to see the port numbers assigned to
> > each port.  You'll be able to display the MACs learned on each port,
> > along with each port's ID.
> 
> And ...? Sorry, but I don't see anything about VLAN==physical interface.
> I suppose the MACs learned will be different, but how does that matter?

Let me put it another way.  What distinguishes eth0, eth1, and eth0.10
when you bridge them together?

Nothing - one gets untagged frames from the interface associated with
eth0.  One gets untagged frames from the interface associated with
eth1.  The last gets tagged frames from the interface associated with
eth0.  I don't see how there's any distinction between these roles.
Each is just a source & sink for frames.  Some end up using the same
cable, but who cares?

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

Re: [Bridge] [PATCH] [bridge] Add split horizon

[richardvoigt]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

>
>
> 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?


With a gigabit VLAN capable switch, 20 ports in untagged mode on distinct
VLANs, 1 trunking port attached to a gigbit card in my Linux firewall, 1
trunking port to a second gigabit VLAN capable switch configured similarly
in another physical location, it allows me to filter traffic between all 40
attached networks as if my Linux box had 40 network interfaces.  It's a very
useful combination of VLANs and bridging.


>
> Also, I am trying to find where it states that a VLAN is considered its own
> physical port. Any pointers?
>

A linux bridge is like a switching hub, with a separate port for every
interface you add with brctl addif.  All local interfaces get treated the
same -- they each get their own port on the bridge -- whether a physical or
virtual or sub-interface.

[-- Attachment #2: Type: text/html, Size: 1333 bytes --]

Re: [Bridge] [PATCH] [bridge] Add split horizon

[richardvoigt]

[-- Attachment #1: Type: text/plain, Size: 4906 bytes --]

On Sat, Jun 13, 2009 at 11:30 AM, Joakim Tjernlund <
joakim.tjernlund@transmode.se> wrote:

> "richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 13/06/2009
> 17:57:55:
> >
> > On Sat, Jun 13, 2009 at 10:03 AM, Joakim
> > Tjernlund<joakim.tjernlund@transmode.se> wrote:
> > > Benny Amorsen <benny+usenet@amorsen.dk <benny%2Busenet@amorsen.dk>>
> wrote on 13/06/2009 01:58:53:
> > >>
> > >> Joakim Tjernlund <Joakim.Tjernlund@transmode.se> 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.

[-- Attachment #2: Type: text/html, Size: 6685 bytes --]

Re: [Bridge] [PATCH] [bridge] Add split horizon

[Joakim Tjernlund]

Ross Vandegrift <ross@kallisti.us> wrote on 14/06/2009 01:04:53:
>
> On Sat, Jun 13, 2009 at 08:32:31PM +0200, Joakim Tjernlund wrote:
> > Ross Vandegrift <ross@kallisti.us> wrote on 13/06/2009 18:56:40:
> > >
> > > On Sat, Jun 13, 2009 at 05:45:47PM +0200, Joakim Tjernlund wrote:
> > > > I would really like to read up on the claim that each VLAN is also a physical port.
> > > > Any pointers?
> > >
> > > Note that you added the VLAN tagged subinterface to the bridge.  Using
> > > brctl's functions, you'll be able to see the port numbers assigned to
> > > each port.  You'll be able to display the MACs learned on each port,
> > > along with each port's ID.
> >
> > And ...? Sorry, but I don't see anything about VLAN==physical interface.
> > I suppose the MACs learned will be different, but how does that matter?
>
> Let me put it another way.  What distinguishes eth0, eth1, and eth0.10
> when you bridge them together?
>
> Nothing - one gets untagged frames from the interface associated with
> eth0.  One gets untagged frames from the interface associated with
> eth1.  The last gets tagged frames from the interface associated with
> eth0.  I don't see how there's any distinction between these roles.
> Each is just a source & sink for frames.  Some end up using the same
> cable, but who cares?
>

So it seems. I got a lot of opposition w.r.t my patch so I will stop now.
I did learn something new so it wasn't a waste of time.
Thanks for your patience explaining this to me.

    Jocke