Date:	Mon, 23 Jun 2014 16:03:56 -0700
From:	Wilson Kok <wkok@...ulusnetworks.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
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

Resending the original message (in quotes) without HTML as the full 
message did not appear on the mailing list.  Please find response at the 
end of the email.

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

There are three issues regarding data packet forwarding in such topology 
that need to be addressed:
   1. reduce the usage of the inter-chassis link to reduce the 
possibility of congestion and need of over-provisioning
   2. reduce the possibility of a dual-homed host receiving duplicate 
copies of the same packet
   3. prevent out of order delivery of packets to a dual-homed host when 
there are multiple paths to reach it

The proposed patch addresses #1, as soon as a dual-homed host MAC 
address is learned on a host link, the local path becomes and remains 
the preferred path to the host for unicast packets.  It also addresses 
#3, as it prevents packets destined to the dual-homed host from flipping 
between the local path and the inter-chassis path following the MAC 
address move.

To address #2 and also to reduce flooding, a simple filtering logic 
(will be submitting in a later patch) can be used such that packets 
crossing the inter-chassis link do not get forwarded to dual-homed 
hosts, the assumption being that the packet should have already been 
forwarded on the originating switch to the same host. With this 
filtering in place, the proposed patch becomes necessary to ensure that 
packets to a dual-homed host be forwarded locally on the originating 
switch and not cross the inter-chassis link, or else they will get 
dropped."


On 6/23/14, 2:19 PM, Stephen Hemminger wrote:
> 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.
>

Yes, this is bridging over a host bond interface that terminates on two 
different switches.  Normal bridging and MAC learning operations over 
such a bond interface will give rise to the three issues listed above, 
hence the need for a solution such as the proposed additional logic in 
MAC learning in the bridge code.  I guess I'm not clear about your 
concern and wondering if you have an alternative suggestion in mind.

Thanks,
Wilson.
--
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

Powered by blists - more mailing lists