netdev - Re: [RFC PATCH net-next] bridge: Add bridge port learn filter and priority

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140623141915.3310c3b8@nehalam.linuxnetplumber.net>
Date:	Mon, 23 Jun 2014 14:19:15 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Wilson Kok <wkok@...ulusnetworks.com>
Cc:	roopa@...ulusnetworks.com, davem@...emloft.net,
	netdev@...r.kernel.org, scotte@...ulusnetworks.com,
	ddutt@...ulusnetworks.com, shm@...ulusnetworks.com,
	nolan@...ulusnetworks.com, sfeldma@...ulusnetworks.com,
	jhs@...atatu.com
Subject: Re: [RFC PATCH net-next] bridge: Add bridge port learn filter and
 priority

On Mon, 23 Jun 2014 14:05:36 -0700
Wilson Kok <wkok@...ulusnetworks.com> wrote:

> On 6/18/14, 1:34 PM, Stephen Hemminger wrote:
> > On Wed, 18 Jun 2014 00:16:07 -0700
> > roopa@...ulusnetworks.com wrote:
> >
> >> One such topology is when there are multiple paths to a dual-homed host.
> > That is called a loop.
> > Loops are not allowed on bridge networks.
> > Sorry, this is just the kind of things spanning tree and TRILL were supposed
> > to address. Solving in local bridge is not a good idea.
> 
> This is not a loop situation.  The topology we're referring to is a 
> multi-chassis LAG topology (a widely supported feature by networking 
> vendors, e.g. Arista's MLAG and Cisco's VPC), where some hosts are 
> dual-homed on a pair of switches, and some hosts are single-homed on one 
> of the two switches, and there is a inter-chassis link between the 
> switches.  A dual-homed host can and will source packets from either or 
> both its uplinks with the same source MAC address. The packets may be 
> locally forwarded on the first hop switch, and they may also cross the 
> inter-chassis link from one switch to the other switch, e.g. in a 
> multicast or flood situation or just unicast to a single-homed host 
> connected to the other switch.  As such, the host's source MAC can be 
> learned on the inter-chassis link or the host link, and can move between 
> the two.  A dual-homed host may receive packets from either or both it's 
> uplinks, and in some cases it may receive duplicate copies of the same 
> packet.
> 

Isn't this bridging over a bond (or team) interface.
The point is this really shouldn't be part of bridge code.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html