Xen devel - Apr 2006 - peth0 received packet on own address

I''ve been looking into an issue were in the message file I see: 
Apr 28 11:43:10 kdell kernel: peth0: received packet with  own address
as source address

Trying to match the time stamp in the message file to a packet trace
captured by ethereal, I found that the offending packets are of the type
ICMPv6 Multicast Listener Report Message v2, ICMPv6 Neighbor
Solicitation, or ICMPv6 Router Solicitation packets.  It looks like
these packets are sent every time a network interface is brought up.  In
this case it is when peth0 is brought up from the network-bridge script
since the MAC address is fe:ff:ff:ff:ff:ff.  When a peth0 comes up, all
other machines with a peth0 up and running will receive the packets and
log the messages.

Is this an issue of concern?  

Thanks,
Kirk

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I''ve been looking into an issue were in the message file I see: 
> Apr 28 11:43:10 kdell kernel: peth0: received packet with  
> own address as source address
> 
> Trying to match the time stamp in the message file to a 
> packet trace captured by ethereal, I found that the offending 
> packets are of the type
> ICMPv6 Multicast Listener Report Message v2, ICMPv6 Neighbor 
> Solicitation, or ICMPv6 Router Solicitation packets.  It 
> looks like these packets are sent every time a network 
> interface is brought up.  In this case it is when peth0 is 
> brought up from the network-bridge script since the MAC 
> address is fe:ff:ff:ff:ff:ff.  When a peth0 comes up, all 
> other machines with a peth0 up and running will receive the 
> packets and log the messages.
> 
> Is this an issue of concern?  
It''s not of particular concern, but it would be nice to make them stop.

Is it the ''ip link set dev X up'' line that causes the packet
to be sent?
Does anyone know how to make them stop?

Thanks,
Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Pratt wrote:
>>I''ve been looking into an issue were in the message file I see:
>>Apr 28 11:43:10 kdell kernel: peth0: received packet with  
>>own address as source address
>>
>>Trying to match the time stamp in the message file to a 
>>packet trace captured by ethereal, I found that the offending 
>>packets are of the type
>>ICMPv6 Multicast Listener Report Message v2, ICMPv6 Neighbor 
>>Solicitation, or ICMPv6 Router Solicitation packets.  It 
>>looks like these packets are sent every time a network 
>>interface is brought up.  In this case it is when peth0 is 
>>brought up from the network-bridge script since the MAC 
>>address is fe:ff:ff:ff:ff:ff.  When a peth0 comes up, all 
>>other machines with a peth0 up and running will receive the 
>>packets and log the messages.
>>
>>Is this an issue of concern?  
> 
> 
> It''s not of particular concern, but it would be nice to make them
stop.
> 
> Is it the ''ip link set dev X up'' line that causes the
packet to be sent?
> Does anyone know how to make them stop?
Not compiling in support for MLDv2, etc in the kernel
can make that stop, but distro kernels I believe turn that
on by default. But those broadcasts aren''t the problem,
the fact is that the physical address needs to be unique
across the network. Someone might conceivably want to run
advanced routing functions on a guest domain, or on
multiple systems in the network, in which case it needs
to send out those packets.

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?

We also need to ensure that the MAC is unique on the subnet,
if this isn''t a case of a guest domain having accidentally
a duplicate MAC.

I haven''t caught up with the changes in the unstable kernel
in the last few weeks, looking into it..

thanks,
Nivedita

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Nivedita Singhvi wrote:
> Ian Pratt wrote:
> 
>>> I''ve been looking into an issue were in the message file I
see: Apr
>>> 28 11:43:10 kdell kernel: peth0: received packet with  own address
as
>>> source address
>>>
>>> Trying to match the time stamp in the message file to a packet
trace
>>> captured by ethereal, I found that the offending packets are of the
type
>>> ICMPv6 Multicast Listener Report Message v2, ICMPv6 Neighbor 
>>> Solicitation, or ICMPv6 Router Solicitation packets.  It looks like
[snip]
> Not compiling in support for MLDv2, etc in the kernel
I should have also mentioned, although this is somewhat
tangential to main issue - that if you are not using
IPv6, and the default for your distro happens to be on,
you might want to turn it off per interface by configuring
it in the network interface configuration file..

This is distro-specific, but for example, in FC* you''d
place a NETWORKING_IPV6=no in ifcfg-ethN, for instance.

thanks,
Nivedita


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 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?
 
Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>  I''ve been looking into an issue were in the message file I
see:
>> Apr 28 11:43:10 kdell kernel: peth0: received packet with  
>> own address as source address
>> 
>> Trying to match the time stamp in the message file to a 
>> packet trace captured by ethereal, I found that the offending 
>> packets are of the type
>> ICMPv6 Multicast Listener Report Message v2, ICMPv6 Neighbor 
>> Solicitation, or ICMPv6 Router Solicitation packets.  It 
>> looks like these packets are sent every time a network 
>> interface is brought up.  In this case it is when peth0 is 
>> brought up from the network- bridge script since the MAC 
>> address is fe:ff:ff:ff:ff:ff.  When a peth0 comes up, all 
>> other machines with a peth0 up and running will receive the 
>> packets and log the messages.
>> 
>> Is this an issue of concern?  
> 
> It''s not of particular concern, but it would be nice to make them
stop.
> 
> Is it the ''ip link set dev X up'' line that causes the
packet to be
sent?

Yes, it is the ''ip link set ${pdev} up'' line.
> Does anyone know how to make them stop?
> 
> Thanks,
> Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

thanks,
Nivedita


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> >> Trying to match the time stamp in the message file to a 
> packet trace 
> >> captured by ethereal, I found that the offending packets 
> are of the 
> >> type
> >> ICMPv6 Multicast Listener Report Message v2, ICMPv6 Neighbor 
> >> Solicitation, or ICMPv6 Router Solicitation packets.  It 
> looks like 
> >> these packets are sent every time a network interface is 
> brought up.  
> > Is it the ''ip link set dev X up'' line that causes
the packet to be
> sent?
> 
> Yes, it is the ''ip link set ${pdev} up'' line.
Does anyone know if there''s some parameter that can be given to the
''ip
link set'' command to cause it not to send the ipv6 router solicitation?

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel