netdev - Re: [net-next PATCH] net: allow vlan traffic to be received under bond

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Oct 2011 06:13:58 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Hans Schillstrom <hans.schillstrom@...csson.com>
CC:	Jesse Gross <jesse@...ira.com>, Jiri Pirko <jpirko@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"fubar@...ibm.com" <fubar@...ibm.com>
Subject: Re: [net-next PATCH] net: allow vlan traffic to be received under
 bond

On 10/11/2011 4:08 AM, Hans Schillstrom wrote:
> Hello
> On Tuesday 11 October 2011 04:43:03 Jesse Gross wrote:
>> On Mon, Oct 10, 2011 at 7:07 PM, John Fastabend
>> <john.r.fastabend@...el.com> wrote:
>>> On 10/10/2011 3:37 PM, Jiri Pirko wrote:
>>>> Mon, Oct 10, 2011 at 09:16:41PM CEST, john.r.fastabend@...el.com wrote:
>>>>> The following configuration used to work as I expected. At least
>>>>> we could use the fcoe interfaces to do MPIO and the bond0 iface
>>>>> to do load balancing or failover.
>>>>>
>>>>>       ---eth2.228-fcoe
>>>>>       |
>>>>> eth2 -----|
>>>>>          |
>>>>>          |---- bond0
>>>>>          |
>>>>> eth3 -----|
>>>>>       |
>>>>>       ---eth3.228-fcoe
>>>>>
>>>>> This worked because of a change we added to allow inactive slaves
>>>>> to rx 'exact' matches. This functionality was kept intact with the
>>>>> rx_handler mechanism. However now the vlan interface attached to the
>>>>> active slave never receives traffic because the bonding rx_handler
>>>>> updates the skb->dev and goto's another_round. Previously, the
>>>>> vlan_do_receive() logic was called before the bonding rx_handler.
>>>>>
>>>>> Now by the time vlan_do_receive calls vlan_find_dev() the
>>>>> skb->dev is set to bond0 and it is clear no vlan is attached
>>>>> to this iface. The vlan lookup fails.
>>>>>
>>>>> This patch moves the VLAN check above the rx_handler. A VLAN
>>>>> tagged frame is now routed to the eth2.228-fcoe iface in the
>>>>> above schematic. Untagged frames continue to the bond0 as
>>>>> normal. This case also remains intact,
>>>>>
>>>>> eth2 --> bond0 --> vlan.228
>>>>>
>>>>> Here the skb is VLAN tagged but the vlan lookup fails on eth2
>>>>> causing the bonding rx_handler to be called. On the second
>>>>> pass the vlan lookup is on the bond0 iface and completes as
>>>>> expected.
>>>>>
>>>>> Putting a VLAN.228 on both the bond0 and eth2 device will
>>>>> result in eth2.228 receiving the skb. I don't think this is
>>>>> completely unexpected and was the result prior to the rx_handler
>>>>> result.
> 
> I think this OK, but I do have a question
> if bond0 is in Active/Backup mode, eth2 and eth3 got the same MAC.addr,
> what about the VLAN:s ?
> (or is just one of thme working ??)
> 

The VLAN MAC address will not be managed by the bond. In the
storage case a SAN mac may be used (NETDEV_HW_ADDR_T_SAN).
Otherwise the MAC can be managed normally.

Both VLANs will receive frames but in some modes only to packet
handlers that have exact matches. See bond_should_deliver_exact_match().

.John.

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