Message-ID: <CAF2d9jgisQpzfCqVfmwqBmHwvceHBfRoV3X+PycyHzCkOSerXQ@mail.gmail.com>
Date:	Mon, 30 Mar 2015 11:32:59 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Jiri Benc <jbenc@...hat.com>, linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address

On Mon, Mar 30, 2015 at 11:13 AM, Dan Williams <dcbw@...hat.com> wrote:
> On Mon, 2015-03-30 at 10:56 -0700, Mahesh Bandewar wrote:
>> On Mon, Mar 30, 2015 at 10:44 AM, Dan Williams <dcbw@...hat.com> wrote:
>> > On Mon, 2015-03-30 at 09:54 -0700, Mahesh Bandewar wrote:
>> >> On Mon, Mar 30, 2015 at 7:37 AM, Dan Williams <dcbw@...hat.com> 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.
>
Yes, that is true (forgot about it!), which means the dev-id has to be
unique in the physical drivers (not just masters') hierarchy.

I think it becomes little complicated. When IPvlan get instantiated,
traverse the dev-layers
using the adj_list linkage and find the lowest device and then
traverse the hierarchy to find a base-dev-id. Then use that base for
all logical link creation. Would this work?

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