From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ding Tianhong Subject: Re: [PATCH net-next 2/2] bonding: support QinQ for bond arp interval Date: Thu, 20 Mar 2014 18:21:25 +0800 Message-ID: <532AC125.7030202@huawei.com> References: <1395057975-19084-1-git-send-email-dingtianhong@huawei.com> <1395057975-19084-3-git-send-email-dingtianhong@huawei.com> <21958.1395078364@death.nxdomain> <20140320082414.GA28839@unicorn.suse.cz> <532AB503.6020004@huawei.com> <20140320094040.GB28839@unicorn.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Jay Vosburgh , , , , , To: Michal Kubecek Return-path: Received: from szxga02-in.huawei.com ([119.145.14.65]:28195 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757308AbaCTKXI (ORCPT ); Thu, 20 Mar 2014 06:23:08 -0400 In-Reply-To: <20140320094040.GB28839@unicorn.suse.cz> Sender: netdev-owner@vger.kernel.org List-ID: On 2014/3/20 17:40, Michal Kubecek wrote: > On Thu, Mar 20, 2014 at 05:29:39PM +0800, Ding Tianhong wrote: >> On 2014/3/20 16:24, Michal Kubecek wrote: >>> On Mon, Mar 17, 2014 at 10:46:04AM -0700, Jay Vosburgh wrote: >>>> Ding Tianhong wrote: >>>>> >>>>> ip link add link bond0 bond0.20 type vlan proto 802.1ad id 20 >>>>> ip link add link bond0.20 bond0.20.200 type vlan proto 802.1q id 200 >>>> >>>> Is this nesting backwards? The way I read it (and the way I >>>> recall that VLANs nest), "bond0.20" is the "regular" VLAN, i.e., if we >>>> just have bond0.20 it would be a standard 802.1q (ethertype 0x8100) >>>> VLAN. Adding the second VLAN, .200 in this example, would be the second >>>> (outer) tag, and would be the 802.1ad (ethertype 0x88a8) tag. >>>> >>>> In other words, adding a VLAN to an already existing VLAN makes >>>> the newly added VLAN the "outer" and the already existing VLAN the >>>> "inner." Am I confused? >>> >>> I don't think so. My understanding is that when sending a packet to >>> a vlan device, it is tagged (according to its "proto") and passed to its >>> underlying device. >>> >>> So in the case above, sending a packet to bond0.20.200 would add an >>> 802.1q tag and pass the result to bond0.20 which would add an 802.1ad >>> tag and pass the result to bond0. Which is the way it should work. >> >> I agree with your analysis of QinQ for vlan in common usage, but I think you miss >> something for how the arp interval works, the bonding need to create a new >> arp request with vlan tag to confirm that the slave should be active or unactive, >> the skb could not be passed to bond0.20.200, we have to build QinQ skb ourselves. > > My comment referred only to the way stacked interfaces are set up in the > quoted example, not to the original issue. > > Michal Kubecek > Sorry for that, I misunderstood.:) Ding > > . >