Bugzilla – Bug 339
peth0: received packet with own address as source address
Last modified: 2012-06-19 09:10:08 CDT
I am seeing the message "peth0: received packet with own address as source address" on several machines, most of which have one only NIC and bridged networking for the guests. I am not sure what the impact is, but it could be a problem with networking.
I posted the question to the xen-devel lists, and Arnd Schmitter responded: From: Arnd Schmitter <arnd_xen@yahoo.de> To: David F Barrera <dfbp@us.ibm.com> Cc: xen-devel <xen-devel@lists.xensource.com> Subject: Re: [Xen-devel] peth1: received packet with own address as source address Date: Mon, 17 Oct 2005 20:50:31 +0200 (13:50 CDT) David F Barrera wrote: > I am seeing a series of messages (below): > > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > peth1: received packet with own address as source address > 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
Has anyone been able to determine whether this is a bug or not? I don't see any apparent effect on my machines, but my machines have very simple network setups.
This is believed to have been caused by the machine's routing tables getting into a state where they claim to be going through peth0 rather than eth0. If this happened with two Xen machines on the network, then one would complain about packets coming from the other. This problem is believed fixed with changeset 7436:18eb059ae471.
I don't see the message in any "xm dmesg" and "dmesg". So I am closing the bug.
I doubt that it is fixed with 7436 because I've installed 9726 (compiled from xen-3.0-testing-src.tgz some days ago) and now I see the same thing in my syslog / dmesg output: peth0: received packet with own address as source address peth0: received packet with own address as source address ... But I'm neither a Xenist nor can I guarantee that this is the same problem, so I do not dare to reopen this bug. Let me know if someone needs additional info. Unfortunately this is not really reproducable: I've only got 13 messages of that sort in my syslog over the last days. BTW 'ifconfig' shows "HWaddr FE:FF:FF:FF:FF:FF" for peth0, vif0.0 and xenbr0. I don't know whether this is normal.
I am running Xen via the Fedora Core 5 kernels. Unfortunately I don't know how to deterine what version of Xen I'm running, but 'xm dmesg' say Xen version 3.0-unstable (brewbuilder@build.redhat.com) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) Tue Aug 8 15:25:20 EDT 2006 These are messages that come out of the xen0's 'dmesg', (IE: not the 'xm dmesg'), and unless there is something wrong in the default scripts from RedHat it isn't a network config problem (IE: the XenU's and Xen0's on this LAN are all unique addresses). I do have two Xen servers if that might be the source of the problem. The other LAN I administrate Xen machines on also has more than one Xen server, and each of them are issuing similar warnings. I wish this bug were re-opened or at least further investigated. Is the problem that peth0 and all the vif?.0 interfaces all have the same HW address of FE:FF:FF:FF:FF:FF and thus also have one of the IPv6 addresses on each of these interfaces being fe80::fcff:ffff:feff:ffff/64 ? Should the default scripts that are setting up these interfaces discontinue setting up IPv6 addresses on these interfaces?
The message is due to unwanted ipv6 router solicitations, and can be safely ignored. There was some discussion on the mailing lists about a fix for this, but I'm not sure it's made kernel.org yet.
(In reply to comment #7) > The message is due to unwanted ipv6 router solicitations, and can be safely > ignored. There was some discussion on the mailing lists about a fix for this, > but I'm not sure it's made kernel.org yet. Doesn't it make more sense to fix this in the supplied scripts that set up the virtual ethernet interfaces, rather than in the kernel? If an interface didn't have an IPv6 address, it wouldn't send out router solicitations... Or is this related to an enhancement to the tools to make it easier to indicate not to set up the default IPv6 address when the interface is being brought up (IE: we need more than a global setting).
This says unstable, but I get it on 3.0-testing also. Is there a way to make it not happen, other than to ignore it? It fills up dmesg and syslog, making it hard to troubleshoot other problems. There are no dom-Us active, just the dom0.
If none of your interfaces have ipv6 addresses assigned it shouldn't be a problem.
None of them have ipv6 interfaces, I don't even have ipv6 support in the kernel. However, the eth0 nic that xen is using is still broadcasting it, and the cisco switch complains about it as well: 2006 Sep 07 00:43:53 PDT -07:00 %SYS-4-P2_WARN: 1/Host fe:ff:ff:ff:ff:ff is flapping between port 2/30 and port 2/44 Our network engineers sure don't like me doing things that create messages like that :) Thanks, Moses
I also see these messages in dmesg when ipv6 is disabled running Debian testing's xen.
This seems to be caused by having two dom0 machines on the same network. Both have HWaddr FE:FF:FF:FF:FF:FF for peth0.
Created attachment 535 [details] diff of network-bridge script taken against: http://xenbits.xensource.com/xen-3.0.5-testing.hg?raw-file/b9f579e2d6a7/tools/examples/network-bridge
Created attachment 536 [details] Full file
I ran into this issue when placing two Dom0's on the same network. I have attached a replacement for the network-bridge script that fixes this issue. The solution is to assign a unique MAC to the vif/peth devices, for every dom0 on your network. I also anticipated that a single dom0 with two physical NICs plugged into the same switch would encounter this error, and thus based the MAC off a combination of a unique identifier, and the eth number. Files: context.diff was created using: diff -c network-bridge network-bridge-new > context.diff network-bridge-new is the full file
I've had the same problem -- two dom0s on the same network -- and the patch by cyrus works very well. Thanks!
I had the same problem - although there is only one dom0 with one NIC in my network. This patch fixed it, thanks!
This might be a problem of hardware. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/165052
Its quite tough to understand these codes. There is need to improve in presentation.... http://scrabbleicious.com
The presentation and layout of the site is really good. I would like to show this way of presentation to my friends...http://www.gta4cheat.org
I appreciate your thought.. http://www.gta4cheat.org (In reply to comment #3) > This is believed to have been caused by the machine's routing tables getting > into a state where they claim to be going through peth0 rather than eth0. If > this happened with two Xen machines on the network, then one would complain > about packets coming from the other. > > This problem is believed fixed with changeset 7436:18eb059ae471.
(In reply to comment #20) > Its quite tough to understand these codes. There is need to improve in > presentation.... you are right. What type of bug this can be? Any answer? http://www.anagrammer.com/scrabble/
It is very hard to understand these coded but I am doing my best and hope that it will work out... http://www.jakpoderwacdziewczyne.net/