From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address Date: Wed, 12 Feb 2014 20:27:52 -0800 Message-ID: References: <1392071391-13215-1-git-send-email-mcgrof@do-not-panic.com> <1392071391-13215-3-git-send-email-mcgrof@do-not-panic.com> <1392108205.22033.16.camel@dagon.hellion.org.uk> <1392203708.13563.50.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDnuJ-0001LA-C2 for xen-devel@lists.xenproject.org; Thu, 13 Feb 2014 04:28:15 +0000 Received: by mail-lb0-f178.google.com with SMTP id u14so7749420lbd.37 for ; Wed, 12 Feb 2014 20:28:13 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , kvm@vger.kernel.org, "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Paul Durrant , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Wed, Feb 12, 2014 at 2:05 PM, Luis R. Rodriguez wrote: > We have to be careful for sure, I'll try to test all cases including > kvm, but architecturally as I see it so far these things are simply > exchanging over data through their respective backend channels, I know > ipv6 interfaces are unused and I'm going to dig further to see why at > least one ipv4 interfaces is needed. I cannot fathom why either of > these interfaces would be required. I'll do a bit more digging. > > The TAP interface requirements may be different, I haven't yet dug into that. I have a test patch that now works that restricts xen-netback from getting any IPv4 and IPv6 addresses, and disables multicast. With this set in place the xen-frontend still gets IPv4 and IPv6 addresses and Multicast still works. This was tested under a shared physical environment, I'll have to test NAT next, and also see if we can enable this as an option for KVM for their TAP 'backend' interfaces. Luis