Bug 753994 - Eth1 (intel I350) can't be actived via network restart under RHEL5.4-64bit(Xen)
Summary: Eth1 (intel I350) can't be actived via network restart under RHEL5.4-64bit(Xen)
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen
Version: 5.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: 5.4
Assignee: Xen Maintainance List
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-15 03:42 UTC by zou.chris
Modified: 2011-12-19 07:35 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-19 07:35:56 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description zou.chris 2011-11-15 03:42:31 UTC
Description of problem:
Eth1 (intel I350) can't be actived via network restart under RHEL5.4-64bit(Xen)

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Power on SUT with eth0&eth1 connected client(IP:192.2.1.2) via switch, load the BIOS optimized default.
2. Install OS RHEL5.4 64bit(Xen) via USB DVD-ROM. 
3. Disable firewall and install NIC driver igb-3.1.16.
4. Asign Statical IP for eth0(192.2.1.20)&eth1(192.2.1.30).
5. Typein "#service network restart" in Terminal,and then SUT Ping client(IP:192.2.1.2) normally.
6. Plug out NIC cable of eth0, SUT can't Ping client(IP:192.2.1.2).
7. With NIC cable only plug in eth1, typein "#service network restart" in Terminal again, SUT can't Ping client(IP:192.2.1.2).--->fail
8. Plug in NIC cable of eth0, SUT Ping client(IP:192.2.1.2) normally.
9. Plug out NIC cable of eth0, with NIC cable only plug in eth1, restart SUT.
10. Eth1 Ping client(IP:192.2.1.2) normally.
11.Plug out NIC cable of eth1 and plug in NIC cable of eth0, eth0 can't Ping client(IP:192.2.1.2).--->fall
12.Typein "#service network restart" in Terminal,and then eth0 Ping client(IP:192.2.1.2) normally.
  
Actual results:

Expected results:

Additional info:
1. Verified with another MLB with intel 82576,the issue can be reproduced
2. The issue does not happened on RHEL6.1-64bit.
3. When perform "ifup eth0" or "service network restart", the issue also exist.
4. When reboot OK, it will be OK.

Comment 1 zou.chris 2011-11-21 06:30:20 UTC
1. If unconnect the cable of eth0, only active eth1 via #neat-->deactive eth0-->server can ping client OK
2. unconnect the cable of eth0, only connect eth1 cable, #service network restart -->the two nic can be both actived-->client can't be ping via eth1,
if deactive eth0 then -->client can be ping via eth1
3.If unpopulated calble of eth1, #service network restart -->The both NIC can be actived-->client can be ping via eth0 
4. If unpopulated calble of eth1,deactived the both NIC via #neat -->active eth1 -->active eth0-->the client cannot be ping.-->if deactive eth1, the client
can be ping.
5.It seems the order of actived NICs impact the NIC ping to the client.

Comment 2 zou.chris 2011-11-21 06:31:15 UTC
We change intel 82599 10G NIC, the order of actived NICs issue still exist.

Comment 3 Miroslav Rezanina 2011-11-22 06:09:30 UTC
Hi,
can you please provide more information on your configuration:
- content of /etc/sysconfig/network-scripts/ifcfg-*
- content of /etc/xen/xend-config.sxp

Problem is, that xen uses it's own network handling scripts. If you use network service or ifup command to handle networking, you can break xen configuration that leads to ping malfunction. 

Can you also try to do "service xend restart" after messing with network and check if ping works?

Comment 7 Miroslav Rezanina 2011-12-19 07:35:56 UTC
Closing this bz as we have not received requested information. This bz is probably not a bug, just wrong usage of networking under the xen. However, without data we are not ablet to confirm this.


Note You need to log in before you can comment on or make changes to this bug.