From: Dan Williams <dcbw@redhat•com>
To: Mahesh Bandewar <maheshb@google•com>
Cc: Jiri Benc <jbenc@redhat•com>, linux-netdev <netdev@vger•kernel.org>
Subject: Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address
Date: Mon, 30 Mar 2015 12:44:39 -0500 [thread overview]
Message-ID: <1427737479.1913.20.camel@redhat.com> (raw)
In-Reply-To: <CAF2d9jj08R=60na9yeCdsensccYrd-an-7SUk0FuHiD7sN5K+A@mail.gmail.com>
On Mon, 2015-03-30 at 09:54 -0700, Mahesh Bandewar wrote:
> On Mon, Mar 30, 2015 at 7:37 AM, Dan Williams <dcbw@redhat•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.
Dan
next prev parent reply other threads:[~2015-03-30 17:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 22:41 [PATCH 1/2] ipvlan: don't loose broadcast MAC when setting MAC filters Dan Williams
2015-03-26 22:43 ` [PATCH 2/2] ipvlan: always allow the broadcast MAC address Dan Williams
2015-03-27 17:46 ` Jiri Benc
2015-03-28 0:52 ` Mahesh Bandewar
2015-03-28 5:56 ` Mahesh Bandewar
2015-03-28 18:32 ` Jiri Benc
2015-03-30 14:37 ` Dan Williams
2015-03-30 16:54 ` Mahesh Bandewar
2015-03-30 17:44 ` Dan Williams [this message]
2015-03-30 17:56 ` Mahesh Bandewar
2015-03-30 18:13 ` Dan Williams
2015-03-30 18:32 ` Mahesh Bandewar
2015-03-27 17:45 ` [PATCH 1/2] ipvlan: don't loose broadcast MAC when setting MAC filters Jiri Benc
2015-03-30 20:28 ` Mahesh Bandewar
2015-03-30 21:01 ` Dan Williams
2015-03-30 21:11 ` Mahesh Bandewar
2015-03-31 3:05 ` Dan Williams
2015-03-31 4:22 ` [PATCH] ipvlan: fix up broadcast MAC filtering for ARP and DHCP Dan Williams
2015-04-01 20:07 ` Dan Williams
2015-04-01 20:24 ` Mahesh Bandewar
2015-04-01 20:55 ` Dan Williams
2015-04-02 1:30 ` Mahesh Bandewar
2015-04-02 14:40 ` Dan Williams
2015-04-03 1:39 ` Mahesh Bandewar
2015-04-06 17:17 ` Dan Williams
2015-04-07 18:32 ` Mahesh Bandewar
2015-04-07 19:45 ` Dan Williams
2015-04-09 15:51 ` Dan Williams
2015-04-09 16:01 ` Eric Dumazet
2015-04-09 16:33 ` Mahesh Bandewar
2015-04-09 22:18 ` Dan Williams
2015-04-08 9:37 ` David Laight
2015-04-08 14:12 ` Dan Williams
2015-04-09 1:08 ` Mahesh Bandewar
2015-04-02 18:16 ` David Miller
2015-04-02 18:39 ` Dan Williams
2015-04-02 18:46 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1427737479.1913.20.camel@redhat.com \
--to=dcbw@redhat$(echo .)com \
--cc=jbenc@redhat$(echo .)com \
--cc=maheshb@google$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox