This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] peth0 received packet on own address

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] peth0 received packet on own address
From: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Mon, 01 May 2006 08:26:14 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Kirk Allan <kallan@xxxxxxxxxx>
Delivery-date: Mon, 01 May 2006 08:26:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D4BA4F3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D4BA4F3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
Ian Pratt wrote:
We shouldn't be doing all of those things (peth0) on the guest OSs - we had gone to some pains to make sure the MAC was unique across the system - have we regressed in that due to the -xen kernel or some other reason?

It's the internal vifX.X interfaces that have the fe:ff:... addresses.
There really is no business for any of these interfaces to be sourcing
packets at all.

Is there an option to the 'ip' tool when bringing the interface up to
prevent the ipv6 router solicitation?

The ip tool mostly configures the settings on the
card, and most of these are network protocol functions
which merely get initiated once the interface comes
up - they are mostly controlled by sysctl kernel
parameters. So, for instance, setting

/proc/sys/net/ipv6/conf/$interface/autoconf = 0

will turn off most of that. However, the /proc
entry for the device is only created when we
register the device, and the MLD and routing
functions get initiated only when we designate
the interface state as UP.  Somewhere in between
performing those two steps, we should turn off
those sysctl vars.

Will test that today..


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>