Bug 467969 - not all iscsi portals are being logged into unless I sleep 10 after eth1 comes up
not all iscsi portals are being logged into unless I sleep 10 after eth1 come...
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts (Show other bugs)
5.4
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: initscripts Maintenance Team
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-21 19:19 EDT by Arwin Tugade
Modified: 2008-10-22 12:44 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-22 12:44:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Arwin Tugade 2008-10-21 19:19:10 EDT
Description of problem:

I must do a sleep of roughly 10 seconds before letting the iscsi login to all portals, because only 4 out of 8 targets are logged into.  The first 4 targets that are logged into are the ones setup for eth0, the next 4 get a connection timed out unless I sleep for 10 seconds or so.  This became a problem after patching recently and getting the updated initscript package.  

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


How reproducible:
EMC-CX320
Configure eth0 and eth1 for the 8 iscsi targets
I also have a 4 port nic with 2 bonds setup, bond0 - balance-alb (public interface) and bond1 - 802.3ad (cluster interconnect)

Steps to Reproduce:
1. Update your host with this set of packages
Oct 16 11:28:19 Updated: krb5-libs - 1.6.1-25.el5_2.1.x86_64
Oct 16 11:28:20 Updated: initscripts - 8.45.19.1.EL-1.x86_64
Oct 16 11:28:21 Updated: nss - 3.12.1.1-1.el5.x86_64
Oct 16 11:28:21 Updated: cups-libs - 1:1.2.4-11.18.el5_2.2.x86_64
Oct 16 11:28:21 Updated: OpenIPMI-libs - 2.0.6-6.el5_2.2.x86_64
Oct 16 11:28:22 Updated: krb5-libs - 1.6.1-25.el5_2.1.i386
Oct 16 11:28:28 Updated: nss - 3.12.1.1-1.el5.i386
Oct 16 11:28:28 Updated: pam_krb5 - 2.2.14-1.el5_2.1.x86_64
Oct 16 11:28:28 Updated: nss-tools - 3.12.1.1-1.el5.x86_64
Oct 16 11:28:29 Updated: OpenIPMI - 2.0.6-6.el5_2.2.x86_64
Oct 16 11:28:30 Updated: cups - 1:1.2.4-11.18.el5_2.2.x86_64
Oct 16 11:28:30 Updated: dhcpv6-client - 1.0.10-4.el5_2.3.x86_64
Oct 16 11:28:30 Updated: krb5-workstation - 1.6.1-25.el5_2.1.x86_64
Oct 16 11:28:30 Updated: pam_krb5 - 2.2.14-1.el5_2.1.i386
Oct 16 11:28:31 Updated: kernel-headers - 2.6.18-92.1.13.el5.x86_64
Oct 16 11:28:32 Updated: tzdata - 2008f-3.el5.noarch
Oct 16 11:28:49 Installed: kernel - 2.6.18-92.1.13.el5.x86_64

2.  Reboot
3.  Check connectivity status on EMC Navisphere, 4 of 8 will be logged in
  
Actual results:
4 out of 8 initiators logged in

Expected results:
8 out of 8 initiators logged in

Additional info:
Comment 1 Bill Nottingham 2008-10-21 19:50:07 EDT
Are you using static IPs?  What sort of switching infrastructure do you have (is STP enabled?)
Comment 2 Arwin Tugade 2008-10-22 11:17:12 EDT
Yes, using static IPs.

I believe spanning tree is enabled even though the network admin says portfast should be enabled.  Reason being, when I pull one of the interfaces out of the bond and reconnect it, I have to wait roughly 30 seconds before I can start talking on that interface.

Arwin
Comment 3 Bill Nottingham 2008-10-22 12:44:45 EDT
Given that, there's very little you can do outside of setting NETWORKDELAY in /etc/sysconfig/network - there's no programmatic way for the init scripts to know that the switch is actually passing traffic.

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