Bug 509789
Summary: | got "received packet with own address as source address" in dom0 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | wmg <wezhang> | ||||||
Component: | xen | Assignee: | Paolo Bonzini <pbonzini> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 5.3 | CC: | clalance, drjones, dwu, leiwang, llim, minovotn, mrezanin, pbonzini, qwan, sbradley, xen-maint | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | xen-3.0.3-119.el5 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-01-13 22:17:38 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 514499 | ||||||||
Attachments: |
|
Description
wmg
2009-07-06 08:28:32 UTC
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. *** |