Andrew Theurer wrote:
Arnd Schmitter wrote:
David F Barrera wrote:
On Mon, 2005-10-17 at 20:50 +0200, Arnd Schmitter wrote:
David F Barrera wrote:
peth1: received packet with own address as source address
Is this something that I should care about? I don't see an obvious
impact to the machine.
This means normaly two things: Packets you send out are returning or
there is another PC with the same address.
The Linuxkernel drops this packets as he think its a knd of address
spoofing.
If all networking is working fine you will only have a minimal
impact on performance. But it could indicate that something with
your network configuration is wrong
Arnd, thanks for your response. My network configuration appears to be
OK; it is simple, one NIC and its IP address, and everything seems to be
working well. Also, there are no two machines with the same address. So,
I am wondering if this is a problem with Xen. I have opened up a
bugzilla report, as I would like to have a definitive answer as to
whether this is a bug or a network configuration issue.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339
Only one NIC and peth1 ??
Take a look at your ifconfig output. Maybe there are two
Virtual-Interfaces witch the same MAC.
Unless the network-bridge script has changed the generated mac for eth0
(which gets renamed to peth0), all systems probably have the same mac
for peth0 & xen-br0: fe:ff:ff:ff:ff:ff. I have tried using unique macs
(for just peth0, vif0.0, and xen-br0, other vifs still have fe:ff...),
and these messages disappear. So, why would the mac for a veth0 or
xen-br0 get sent to another system? Not sure, since they should not
have an ip address, and should not respond to an arp request. I do
notice that peth0 has 'noarp' but xen-br0 does not. Perhaps adding
noarp to xen-br0 will fix this.
This is what I thought it was, until Anthony said he was seeing
it even without guest domains, and without xend starting. I'd
thought the network rename was in vif-bridge, but misremembered,
it's in network-bridge, so it really doesn't need xend to run to
run into the problem.
The MAC address is expected to be unique in a network, so it is
a problem if it's not.
The non-public MAC should not be going out, and if someone could just
say which the "same MAC address" reported in the message is, that
would confirm it. But xen-br0 shouldn't need a noarp(?) (checking...)
thanks,
Nivedita
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|