cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
630
Views
0
Helpful
9
Replies

MDS9509 iSCSI problem when upgrading to 3.1(2a)

richardca
Level 1
Level 1

Hi,

Hopefully someone can help, or at least point me in the direction as to where to look to fix this problem. On our site we have a couple of 9509 switches with the DS-X9308-SMIP IPS module, which we use to connect to some exposed LUN's on a HP EVA5000 disk array via a Proxy Initiator, and ACL's on the switch. The clients are on v2.0-754 of open-iscsi on SLES 10.1 machines.

Now we are seeing a strange problem, when we upgraded the SAN-OS on the switches from 2.1(2e) to 3.1(2a) (and I have verified the problem still exists with v. 3.1(3), which is does) in that the iSCSI clients, can still see their disks (via sendtargets), however when they attempt to login to them, you get the following message in dmesg/syslog

scsi4 : iSCSI Initiator over TCP/IP

4:0:0:0: scsi scan: consider passing scsi_mod.dev_flags=COMPAQ:HSV110 (C)COMPAQ:0x240 or 0x1000240

and no device file is created (I have tried passing the option suggested via -v, and in the iscsid.conf file, however it doesn't fix the problem) whereas when the switch is running on 2.1(2e) with the same configuration, it all works, and this appears in syslog:

scsi6 : iSCSI Initiator over TCP/IP

Vendor: COMPAQ Model: HSV110 (C)COMPAQ Rev: 2001

Type: Direct-Access ANSI SCSI revision: 04

SCSI device sdb: 104857600 512-byte hdwr sectors (53687 MB)

sdb: Write Protect is off

sdb: Mode Sense: 97 00 10 08

SCSI device sdb: drive cache: write through w/ FUA

SCSI device sdb: 104857600 512-byte hdwr sectors (53687 MB)

sdb: Write Protect is off

sdb: Mode Sense: 97 00 10 08

SCSI device sdb: drive cache: write through w/ FUA

sdb: sdb1

sd 6:0:0:0: Attached scsi disk sdb

sd 6:0:0:0: Attached scsi generic sg5 type 0

Luckily we have 2 switches, so we have 1 working configuration to leave for production, and one we have to try and troubleshoot this issue. However we would like to update the SAN-OS at some point, and get some failover setup incase of fabric issues.

So has anyone else seen this problem, and know how to fix it? I have gone through the online Cisco documentation, and I could not find anything which helped, hence this post.

Any help would be much appreciated.

9 Replies 9

inch
Level 3
Level 3

G'day,

What debugs have you pulled from the switch?

Hi,

I've bumped the logging for ips upto 7, and I still cannot see anything, other than that I don't know what I should be looking at.

On Friday, I tried to get this to work with a Windows iSCSI initiator (SCSI driver version 6.0.6000.16386) and I saw exactly the same thing, you can see the targets, and on a v 2.1 (2e) switch you can login and access the iSCSI disk however connecting to the disk via a v. 3.1(3) switch, you can login, however you cannot access/see the disk from the OS.

So considering this doesn't work for Linux or Windows, I don't think its an OS problem.

Can you suggest which logs I should be looking at to troubleshoot this?

sh iscsi init

sh iscsi init config

sh iscsi ses det

debug ips iscsi msgs

debug ips iscsi config-detail

OK, thanks for your help. I will run those commands on both switches and report back what I find

Hi,

I have now ran those commands, and it all looks OK to me (still) I have attached the outputs so people can see if they can work out, whats going wrong.

One additional thing to note which I missed off my original message, was that we are using IVR to handle communication between the proxy initiator and the disk arrays, I don't think this should matter, but I guess its worth mentioning.

Anyhow, heres the outputs of the debug commands

Rich

Hi Richard,

I checked out the output and it looks ok. Can you sent the output of the 2.x setup?

and a sh iscsi virt

Only 2 PDU commands and responses.

These are probably a SCSI Report LUNs and/or a SCSI Inquiry. Perhaps the storage is sending a SCSI check condition, eg. lun masking is blocking the host. You should really get an ethereal trace on the ethernet to see what those PDUs are in detail.

Initiator x.x.164.14 (suse-test)

Initiator name iqn.1996-04.de.suse:01.c48fdfc3cec6

Session #1 (index 6)

Target iqn.1986-03.com.x.x:disk.ress.lun0

VSAN 255, ISID 00023d000000, TSIH 4097, Status active, no reservation

Type Normal, ExpCmdSN 3, MaxCmdSN 130, Barrier 0

MaxBurstSize 262144, MaxConn 1, DataPDUInOrder Yes

DataSeqInOrder Yes, InitialR2T No, ImmediateData Yes

Registered LUN 0, Mapped LUN 1

Stats:

PDU: Command: 2, Response: 2 <<<<<<<<

I will have a look into that, and see if I can track anything down

OK, here's the output from the working switch.

Some of the configuration is slightly different, namely the proxy initiator pWWN's, however they are configured identically on the EVA. I have also only included the initiator/target information for the test LUN's, to keep the size managable.

Rich

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: