how to match ioscan output with switch information

[Kurz]

Hi,

I am about to find out how to match the information I get from the ioscan output with the SAN information, starting from the HBAs down to the LUN level appearing as devices in HP/UX 11.11.

The FibreChannel.pdf document tells me that the HW path looks like

[FC-HBA].[Domain].[Area].[Port].[Bus].[Target].[Lun]

We now have an EVA and McData switches. I already found that, unlike with the Brocade switches, to get the Domain part of the HW address, you have to substract a fixed integer, which you find in the config parms of the switch and which defaults to 16.

For Brocade switches, FibreChannel.pdf says that you substract 16 and then you have the fibre channel slot number. For McData switches, I also see area ids < 16, so there must be more to this.

Any ideas how the area id in the HW part of the ioscan output for fc components and LUNs can be derived from the switch and port parameters?

Another question: As far as I have read, domain ids can change dynamically whenever a new switch is added to the fabric. This is because domain ids are really just "preferred domain ids". I suppose then the hosts would stop seeing the disks? So should we rather change the setting on our MacData switch to "insistent" next the the domain id config parm?

thx,

M. Kurz

[Stephen Kebbell]

Hi,

should not be too difficult.

Example from an ioscan:
disk 50 3/0/2/1/0.2.140.0.0.0.2 sdisk CLAIMED DEVICE HITACHI DF600F
/dev/dsk/c18t0d2 /dev/rdsk/c18t0d2

The device above is on LUN on a Storage Device which is attached to a SAN Switch with Domain ID 2, Port 140. It is presented with Host LUN 2 (check on the Storage System to find out which device this is).

For the port, it's on a Brocade 48000 Director, I have never heard of this add or subtract 16 business.
The switchshow output shows:

140 1 28 id 2G Online F-Port 50:06:0e:80:00:43:8b:e2

So Port 140 is Port Number 28 on Slot 1. The Port Numbering for the 48000 is a bit weird, but I have a printout of the port numbers from the 48000 User Guide stuck inside the Director's rack so I can easily find what port/cable that is. Not sure about McData, but it should also be a fairly logical layout.

Domain ID COULD change dynamically, if you just add switches without any preconfiguring. If you set a preferred Domain ID, the switch should keep that ID in the fabric as long as no other switch has it. If you make sure that every switch has a unique Domain ID then you should never run into problems like that. If the Domain ID did change, then HP-UX would recognise the new path as a new device. You could switch to Insistent Domain IDs, which would mean the switch would insist on having that preconfigured ID. If another switch in the same fabric has that ID, then either it would change (if is not insistent), or the fabric would segment. I don't know for sure as I have never tried IDID. Our SAN has almost 1000 ports, and we've never had any problems of switches dynamically getting new Domain IDs.

Regards,
Stephen

[Torsten.]

There are special rules and offsets for M-Series switches.

Post your ioscan -fn!

[Kurz]

Hi Stephen,

with our old Brocade/VA7100 environment the
numbers are as clear and easy-to-read as in your example. This seems to be a specific McData Problem.

[Kurz]

Thanks for your help so far!

Some additional information:
We have Sphereon 4500 and 4700 switches.

server1 connected to McData switches with domain ids 3 and 5:
& /usr/sbin/ioscan -kfn | grep fc | grep 0\/9
fc 1 0/9/0/0 td CLAIMED INTERFACE HP Tachyon XL2 Fibre Channel Mass Storage Adapter
fcp 0 0/9/0/0.99 fcp CLAIMED INTERFACE FCP Domain
ext_bus 5 0/9/0/0.99.12.19.0 fcparray NO_HW INTERFACE FCP Array Interface
ext_bus 6 0/9/0/0.99.12.255.1 fcpdev CLAIMED INTERFACE FCP Device Interface
ext_bus 7 0/9/0/0.99.14.19.0 fcparray CLAIMED INTERFACE FCP Array Interface
ext_bus 8 0/9/0/0.99.14.255.1 fcpdev CLAIMED INTERFACE FCP Device Interface
ext_bus 9 0/9/0/0.99.16.19.0 fcparray CLAIMED INTERFACE FCP Array Interface
ext_bus 10 0/9/0/0.99.16.255.1 fcpdev CLAIMED INTERFACE FCP Device Interface
ext_bus 20 0/9/0/0.99.17.19.0 fcparray CLAIMED INTERFACE FCP Array Interface
ext_bus 21 0/9/0/0.99.17.255.1 fcpdev CLAIMED INTERFACE FCP Device Interface
fcp 1 0/9/0/0.101 fcp CLAIMED INTERFACE FCP Domain
ext_bus 22 0/9/0/0.101.18.19.0 fcparray CLAIMED INTERFACE FCP Array Interface
ext_bus 23 0/9/0/0.101.18.255.1 fcpdev CLAIMED INTERFACE FCP Device Interface
ext_bus 24 0/9/0/0.101.19.19.0 fcparray CLAIMED INTERFACE FCP Array Interface
ext_bus 25 0/9/0/0.101.19.255.1 fcpdev CLAIMED INTERFACE FCP Device Interface

for server2 connected to McData switches with domain ids 4 and 6
I see 100 and 102 respectively. There is a config switch for the
domain Id base which defaults to 96. So domain id presents no further
problems.

The server is directly connected to the switch with port 2 of the switch
with domain id 5 (101). What do the numbers 12-19 mean?

thanks for your help so far,

M. Kurz

[Torsten.]

For your example:

0/9/0/0.101.19.19.0

101 ... Domain ID + 96 (5)

19 ... Port - 4 (15)

19 ... always there

(device addressing follows)

[Kurz]

Hi Torsten,

thanks a lot.

I can backup

"19 ... always there"

from the McDATA documentation:

san_plan.pdf (CD):
The assignment of the N_Port IDs depends on the OS version of the switch:

--------------
Node port (N_Port) ID assignment

E/OSc 8.0:
N_Port ID assigned based on
port number plus offset of four.
Device attached to port nn
obtains N_Port ID of
dd(nn+4)xx, where dd is the
switch domain ID and xx is
hexadecimal 13.

E/OSn 6.0:
N_Port ID assigned based on
port number. Device attached to
Port nn obtains N_Port ID of
ddnnxx, where dd is the switch
domain ID and xx is
hexadecimal 13.

E/OSi 4.6:
N_Port ID assigned based on
port number. Device attached to
Port nn obtains N_Port ID of
ddnnxx, where dd is the switch
domain ID (always 01) and
xx is hexadecimal 13.
--------------

So you're right, 19 is always there, because 19 = 0x13.

The 4700 Sphereon already has E/OS 9.00, BTW. Not sure if that makes a difference.

Still, the middle byte (area) is not clear to me.

I'm not sure what you mean by
"19 ... Port - 4 (15)".

thanks,

M. Kurz

[Bernd Reize]

the middle byte corresponds to the switch port to which the storagearray is connected to. (-4 offset due to eos)

In your above ioscan example your storagesystem is connected to ports 8,10,12,13,14,15

[Kurz]

Hi,

I know now how the area id is filled. Both controllers of the storage system (EVA) are connected to a switch.

The area id is simply the port id of the port where the controller is attached.

I did not see this right away because some ports have names configured and some haven't. Thus, the Product - Port List is useless and you have to look at each port individually - I rather checked the cables.

I don't see any -4 offset, at least I checked for 101.18 and 101.19 manually.

An EVA LUN looks like this in ioscan output:

disk 50 0/9/0/0.101.18.19.0.4.1 sdisk CLAIMED DEVICE HP HSV200

where
0/9/0/0 = HBA
101 = 96 + McDATA switch id
18 = slot where EVA is attached
(physical slot as labeled)
19 = fixed for McDATA
0.4.1 = 0*128 + 4*8 + 1 = LUN 33

thanks for your help.

Any further input is very much appreciated.

M. Kurz