also seeing this with 5.4 kernel:


[root@dhcp-66-70-83 ~]# dmesg | tail
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
printk: 8 messages suppressed.
peth1: received packet with  own address as source address
[root@dhcp-66-70-83 ~]# uname -r
2.6.18-156.el5xen
[root@dhcp-66-70-83 ~]# arch
x86_64
[root@dhcp-66-70-83 ~]#

with  xen 3.1.2-156.el5 and kernel 2.6.18-92.el5xen also seeing this:

[root@dhcp-66-70-83 ~]# xm dmesg | grep version
 Xen version 3.1.2-156.el5 (mockbuild) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Mon Jun 29 18:15:35 EDT 2009
(XEN) Processor #0 6:15 APIC version 20
(XEN) Processor #1 6:15 APIC version 20
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[root@dhcp-66-70-83 ~]# uname -r
2.6.18-92.el5xen
[root@dhcp-66-70-83 ~]# dmesg | tail
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
printk: 8 messages suppressed.
peth1: received packet with  own address as source address

Probably a kernel-xen problem, so changing components.

Chris Lalancette

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339 suggests this:

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

This patch is nowhere near being in shape for RHEL, but explains the idea:

http://bugzilla.xensource.com/bugzilla/attachment.cgi?id=535

(In reply to comment #4)
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339 suggests this:
> 
> > 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.
> 
> This patch is nowhere near being in shape for RHEL, but explains the idea:
> 
> http://bugzilla.xensource.com/bugzilla/attachment.cgi?id=535    

Did you took Paolo's advice and is it working fine for you by now? If it's done by setting up a MAC address in network-bridge script it would be a part of xen component so please could you try with -107.el5virttest25 RPMs available from:

http://people.redhat.com/mrezanin/xen/

Thanks,
Michal

looks like this is the solution,

but I don't have a test environment for now,
I think it's safe to push that patch

(In reply to comment #8)
> looks like this is the solution,
> 
> but I don't have a test environment for now,
> I think it's safe to push that patch    

I'd love to but testing this first is necessary. Unfortunately I'm not seeing those messages any longer using the latest version of Xen package.

Michal

Michal,

to see the messages you need a particular network configuration as explained in the xensource bugreport.  Anyway, the patch is just a proof of concept: users cannot be expected to change the contents of /etc/xen/network-bridge, hence my comment that "the patch is nowhere near being in shape for RHEL".

Paolo,

thanks for your reply  but I'm not seeing the link for xensource bugreport and also I cannot find it since I've tried now with no luck.

Could you give me the link please?

Thanks,
Michal

Michal, see comment #4.

(In reply to comment #12)
> Michal, see comment #4.    

Oh, I overlooked this bugzilla was on xensource :( Sorry.

Michal

Hi,
what's your network configuration to be able to reproduce it? In fact I did read the bugzilla on xensource but I was unable to find their configuration with the steps to reproduce it.

Thanks,
Michal

You can try connecting two machines with a cross cable.

(In reply to comment #15)
> You can try connecting two machines with a cross cable.    

You mean 2 physical (host) machines using the cross table ? Any other and better setup that doesn't require 2 machines is available and one machine is good for that ?

Michal

One idea could be to use the address of eth0, but with bit 1 of the first octet set to 1.  For example, if eth0's address is 00:22:64:B5:2D:B5, you can use 02:22:64:B5:2D:B5 for peth0.

Created attachment 448004 [details]
patch

This is a patch that should work for this.

However, I don't think this can be deployed by default.

I think we should make a new network script network-bridge-multi and write a kbase article suggesting it in case this error shows up.  This is because the dummy fe:ff:ff:ff:ff:ff address is present in a lot of Xen books and tutorials, and even in the RHEL Virtualization Guide.

This way, people who aren't bothered by the message will see no change.

Created attachment 448014 [details]
complete version of the patch

QE reproduced this with xen-3.0.3-117.el5, verified the fix with xen-3.0.3-119.el5.

We haven't seen the error messages in RHEL for a long time, anyone want to reproduce this can have a try with the following steps:
1. connect two xen hosts (Host A and Host B) with cross cable and configure the network of them (static ip is just ok)
2. from Host A:

$ /etc/init.d/xend stop
$ export netdev=eth0
$ /etc/init.d/xend start
$ ifconfig xenbr0 arp

3. then you will see the error messages "received packet with own address as source address" on host B with 'dmesg' just after enable arp on xenbr0. (Need to reboot Host A and issue the commands if you want to see it again)

Verified with xen-3.0.3-119.el5:
1. use 'network-bridge-mac' as the network-script in xend-config.sxp
2. reboot hosts
3. ifconfig, check the macaddr for peth0, xenbr0 and vif0.0, them are changed  to mac which generated from eth0's mac (bit 1 of the first octet set to 1)
4. try the reproduce approach above, didn't see any error message.

$ ifconfig

eth0      Link encap:Ethernet  HWaddr 00:23:7D:53:AB:D1  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::223:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:7704 (7.5 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:67389 (65.8 KiB)  TX bytes:67389 (65.8 KiB)

peth0     Link encap:Ethernet  HWaddr 02:23:7D:53:AB:D1  
          inet6 addr: fe80::23:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:7868 (7.6 KiB)
          Interrupt:17 Memory:d8800000-d8810000 

vif0.0    Link encap:Ethernet  HWaddr 02:23:7D:53:AB:D1  
          inet6 addr: fe80::23:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:29 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:7704 (7.5 KiB)  TX bytes:0 (0.0 b)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:6864 (6.7 KiB)

xenbr0    Link encap:Ethernet  HWaddr 02:23:7D:53:AB:D1  
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:29 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:7298 (7.1 KiB)  TX bytes:0 (0.0 b)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0031.html

*** Bug 319121 has been marked as a duplicate of this bug. ***