netdev - Re: [PATCH net-next 2/2] bonding: support QinQ for bond arp interval

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]

Message-ID: <20140320094040.GB28839@unicorn.suse.cz>
Date:	Thu, 20 Mar 2014 10:40:40 +0100
From:	Michal Kubecek <mkubecek@...e.cz>
To:	Ding Tianhong <dingtianhong@...wei.com>
Cc:	Jay Vosburgh <fubar@...ibm.com>, vfalico@...hat.com,
	andy@...yhouse.net, kaber@...sh.net, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] bonding: support QinQ for bond arp interval

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 <dingtianhong@...wei.com> 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

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