From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address Date: Mon, 30 Mar 2015 13:13:18 -0500 Message-ID: <1427739198.1913.25.camel@redhat.com> References: <1427409698.18540.11.camel@redhat.com> <1427409822.18540.13.camel@redhat.com> <20150328193254.6c79784d@griffin> <1427726230.1913.9.camel@redhat.com> <1427737479.1913.20.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Jiri Benc , linux-netdev To: Mahesh Bandewar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54781 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752743AbbC3SNA (ORCPT ); Mon, 30 Mar 2015 14:13:00 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 2015-03-30 at 10:56 -0700, Mahesh Bandewar wrote: > On Mon, Mar 30, 2015 at 10:44 AM, Dan Williams wrote: > > On Mon, 2015-03-30 at 09:54 -0700, Mahesh Bandewar wrote: > >> On Mon, Mar 30, 2015 at 7:37 AM, Dan Williams wrote: > >> > On Sat, 2015-03-28 at 19:32 +0100, Jiri Benc wrote: > >> >> On Fri, 27 Mar 2015 22:56:15 -0700, Mahesh Bandewar wrote: > >> >> > The current logic disables broadcast by default and enables only when > >> >> > an IPv4 address is added. If this is inverted and - > >> >> > enables broadcast by default but disables it when only IPv6 > >> >> > address(es) is / are added. These links can have multiple addresses > >> >> > and hence have to be careful if any one of those is IPv4 then > >> >> > broadcast bit has to be set. > >> >> > >> >> You'd have to be careful and ignore IPv6 link local addresses. > >> >> Those are added automatically whenever IPv6 is enabled and their > >> >> presence does not mean the network is not IPv4 only. > >> >> > >> >> But I don't like such magic behavior. It would lead to DHCP sometimes > >> >> working and sometimes not in mixed v4/v6 environment depending on > >> >> whether DHCPv4 or SLAAC was faster. > >> >> > >> >> Could we perhaps add a flag when creating ipvlan interface stating > >> >> whether IPv4 broadcast should be always enabled? Or, rather, the other > >> >> way round - whether it should be disabled by default. Call it "nodhcp" > >> >> or so. > >> >> > >> >> Btw, speaking about IPv6 link local addresses, these actually do not > >> >> work with ipvlan correctly. I'm getting DAD failures if I have more > >> >> than one ipvlan interface, which is no wonder. This means that ipvlan > >> >> cannot work with IPv6 reliably by default (unless you take care of ll > >> >> address assignment and ensure all ipvlan interfaces get a different > >> >> one). > >> > > >> > ipvlan doesn't set dev_id. Once dev_id is set the kernel's IPv6LL > >> > address generation code will assign a different LL address to each > >> > ipvlan interface created from the same physical interface, despite that > >> > they have the same MAC address. > >> > > >> Yes, that was what my plan was but never got around fixing that > >> > >> > But of course you'd have to be careful to assign a *different* dev_id > >> > than any of that physical interface's non-ipvlan children too, and I > >> > have no idea how that would work since dev_id is currently done > >> > per-driver. eg, if you have a physical interface with dev_id=1 which > >> > you then create an ipvlan from, that ipvlan must not use dev_id=1 or it > >> > will be assigned the same IPv6LL address as the parent. > >> > > >> The description is very clear for dev_id (in netdevice.h). So the idea > >> of using the subsequent numbers after master's id should be possible. > >> After all these logical devices are going to share the same link. Most > >> physical drivers don't assign dev-id so the beginning is 0x0 (for the > >> physical driver) and from 0x1 can be assigned to the logical links. > >> The definition is not clear in terms of what is the beginning (0x0 or > >> 0x1) but from the code that generates the IPv6LL it's common that it's > >> 0x0 hence logical links on top of these links can use 0x1 onward. > >> However a check to see if the master-link has dev-id and staying clear > >> of that should be sufficient. > > > > My point was that if you have a parent with a non-zero dev_id, there can > > be other siblings of the parent that have a different dev_id and share > > the same MAC address. So creating an ipvlan with parent->dev_id + 1 > > doesn't work, because the parent may have a sibling with parent->dev_id > > + 1 and the same MAC address already. > > > May be I'm missing something but is there a scenario where sibling > (physical / port) will be sharing the same LL-address? The definition > / description in netdevice.h is - > > * @dev_id: Used to differentiate devices that share > * the same link layer address > > So I's assuming the layered / stacked devices (children) rather than > ports etc (siblings). What am I missing? I don't think that distinction matters since you can create an ipvlan interface on top of any other interface except a macvlan. So any driver that sets dev_id could be the parent of an ipvlan interface. That appears to include some CAN devices and s390's qeth driver at the moment. Dan