All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: netdev@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address
Date: Tue, 11 Feb 2014 08:43:25 +0000	[thread overview]
Message-ID: <1392108205.22033.16.camel__37097.1394856044$1392108305$gmane$org@dagon.hellion.org.uk> (raw)
In-Reply-To: <1392071391-13215-3-git-send-email-mcgrof@do-not-panic.com>

On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Although the xen-netback interfaces do not participate in the
> link as a typical Ethernet device interfaces for them are
> still required under the current archtitecture. IPv6 addresses
> do not need to be created or assigned on the xen-netback interfaces
> however, even if the frontend devices do need them, so clear the
> multicast flag to ensure the net core does not initiate IPv6
> Stateless Address Autoconfiguration.

How does disabling SAA flow from the absence of multicast? Surely these
should be controlled logically independently even if there is some
notional linkage. Can SAA not be disabled directly?

>  Clearing the multicast
> flag is required given that the net_device is using the
> ether_setup() helper.
> 
> There's also no good reason why the special MAC address of
> FE:FF:FF:FF:FF:FF is being used other than to avoid issues
> with STP,

With your change there is a random probability on reboot that the bridge
will end up with a randomly generated MAC address instead of a static
MAC address (usually that of the physical NIC on the bridge), since the
bridge tends to inherit the lowest MAC of any port.

Since IP configuration is done on the bridge this will break DHCP,
whether it is using static or dynamic mappings from MAC to IP address,
and the host will randomly change IP address on reboot.

So Nack for that reason.

>  since using this can create an issue if a user
> decides to enable multicast on the backend interfaces

Please explain what this issue is.

Also how can a user enable multicast on the b/e? AFAIK only Solaris ever
implemented the m/c bits of the Xen PV network protocol (not that I
wouldn't welcome attempts to add it to other platforms)

Ian.

  reply	other threads:[~2014-02-11  8:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 22:29 [RFC 0/2] xen-backend interfaces and IFF_MULTICAST Luis R. Rodriguez
2014-02-10 22:29 ` [RFC 1/2] ipv6: disable autoconfiguration and DAD on non-multicast links Luis R. Rodriguez
2014-02-10 22:29 ` Luis R. Rodriguez
2014-02-10 22:29 ` [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address Luis R. Rodriguez
2014-02-10 22:29 ` Luis R. Rodriguez
2014-02-11  8:43   ` Ian Campbell [this message]
2014-02-11  8:43   ` Ian Campbell
2014-02-11 21:53     ` Luis R. Rodriguez
2014-02-11 21:53     ` Luis R. Rodriguez
2014-02-12 11:15       ` Ian Campbell
2014-02-12 17:17         ` Bill Fink
2014-02-12 19:52           ` Luis R. Rodriguez
2014-02-12 19:52           ` Luis R. Rodriguez
2014-02-12 17:17         ` Bill Fink
2014-02-12 22:05         ` Luis R. Rodriguez
2014-02-13  4:27           ` Luis R. Rodriguez
2014-02-13  4:27           ` Luis R. Rodriguez
2014-02-13  4:35             ` Luis R. Rodriguez
2014-02-13  4:35             ` Luis R. Rodriguez
2014-02-13 11:35           ` Ian Campbell
2014-02-13 11:35           ` Ian Campbell
2014-02-12 22:05         ` Luis R. Rodriguez
2014-02-12 11:15       ` Ian Campbell
2014-02-12 12:19       ` Wei Liu
2014-02-12 12:19       ` Wei Liu

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='1392108205.22033.16.camel__37097.1394856044$1392108305$gmane$org@dagon.hellion.org.uk' \
    --to=ian.campbell@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=netdev@vger.kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.