Comments on: Securing COMSTAR and VMware iSCSI connections

By: Mike La Spina

Mike La Spina — Thu, 14 Apr 2011 23:55:48 +0000

Thanks for the note, not sure what I was thinking that day but its definetly not in the clear.

By: Rickard Nobel

Rickard Nobel — Thu, 14 Apr 2011 18:36:52 +0000

Thanks for a good article about iSCSI. However this part: “The CHAP secret must be between 12 and 255 characters long. The secret is sent from the initiator to the target in clear text” – is not really correct. The CHAP secret is not sent in clear text, that is the main feature of CHAP. It might not be the strongest authentication around, but CHAP uses a challenge technique which makes every login different. Since it is not resiliant to offline dictionary attacks if the traffic is sniffed it is still very recommended to use a separate iSCSI network.

By: gavinramm

gavinramm — Fri, 15 Oct 2010 21:53:41 +0000

Great post, very helpfull now my nexentastor box is complete. cheers

By: noon

noon — Mon, 21 Sep 2009 17:04:28 +0000

Hi everyone this is a good article but i have a problem. I have an opensolaris who share in nfs and iscsi for two esx server. And the performance in iscsi are very low (nearly 30mo/s copare nfs 70 mb/s). Have you the same problem or i miss something. When i try iscsi on windows initiator i have 100 mo/s. My opensolaris is an snv122 with zfs upgrad v 18 and i enabled the write cache

By: Virtualization Short Take #28 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

Wed, 19 Aug 2009 00:49:04 +0000

[...] Virtual Fibre Channel (vFC) Interfaces vPC (Virtual Port Channel) and the Nexus Platform Securing COMSTAR and VMware iSCSI Connections HA in Cisco UCS Menlo [...]

By: Mike La Spina

Mike La Spina — Tue, 18 Aug 2009 17:15:26 +0000

Hi Roman,

So, itadm can restrict access by target portal groups – thus by target ip interfaces?

Not exactly, target portal groups define what ip addresses will participate in an i_t nexus session. It controls data flow. For example if a series of write command descriptors for one lu occur over the TCP transports on two ip addresses within a tpg group the iSCSI protocol will make sure they are re-assembled correctly for a single i_t nexus. Access is fundamentally controlled by authentication, for example using chap or ipsec.

You can of course can direct traffic using tgp groups which seems to be what your defining.

Here is and example of the steps.

1 Define two tpg’s
itadm create-tgp tpg1 172.1.1.10
itadm create-tgp tpg2 172.1.2.10

2 Define targets and assign a tpg to each
itadm create-target -n iqn.1986-03.com.sun:02:ss1.1 -t tpg1 target1
itadm create-target -n iqn.1986-03.com.sun:02:ss1.2 -t tpg2 target2

3 Define the remote initiators to the storage head
itadm create-initiator iqn.1991-05.com.microsoft.win1 win1
itadm create-initiator iqn.1991-05.com.microsoft.win2 win2

4 Define a target group so you may assign common lu’s if required. (Any lu views you map to the tg will be commonly visible to initiators of the tg.)
stmfadm create-tg target-group1
stmfadm create-tg target-group2

5 Add the targets to the target groups
stmfadm add-tg-member -g target-group1 iqn.1986-03.com.sun:02:ss1.1
stmfadm add-tg-member -g target-group2 iqn.1986-03.com.sun:02:ss1.2

6 Create two host groups to control lu mappings
stmfadm create-hg win1
stmfadm create-hg win2

7 Add the required initiators to the respective host group
stmfadm add-hg-member -g win1 iqn.iqn.1991-05.com.microsoft.win1
stmfadm add-hg-member -g win2 iqn.iqn.1991-05.com.microsoft.win2

8 Create your lu and lu views and map the exclusive one to the host group and any common ones to the target host group
stmfadm create-lu /dev/zvol/rdsk/rp1/boot-win1
stmfadm add-view -h win1 -n 0 600144F01EB3862C0000494B55CD0001
stmfadm create-lu /dev/zvol/rdsk/rp1/boot-win2
stmfadm add-view -h win2 -n 0 600144F01EB3862C0000494786CD0001
stmfadm create-lu /dev/zvol/rdsk/rp1/shared-vol0
stmfadm add-view -t target-group1 -n 1 600144F01EB3862C0000494444D0001
stmfadm add-view -t target-group2 -n 1 600144F01EB3862C0000494444D0001

Hope that helps.

Regards,

Mike

By: Roman

Roman — Sun, 16 Aug 2009 18:29:58 +0000

So, itadm can restrict access by target portal groups – thus by target ip interfaces?
And stmfadm can restrict access to targets only by initiator names, grouping them into hg and tg?

What would be the steps in stmfadm and itadm for the following:
a. 2 interfaces on target server: 172.1.1.10 and 172.1.2.10
b. 2 luns created as raw volumes
c. 2 win should access the volumes using different interfaces on the target
d. win servers should see only 1 “own” volume

Thank you,
Roman

By: Mike La Spina

Mike La Spina — Sun, 26 Jul 2009 00:48:44 +0000

Hi Roman,

Portal groups are not really designed to provide any form of initiator authentication. They act as a control function to designate what interfaces on the target side will be active participants. The iscsit state engine is aware of sessions across the group and handles scsi command ordering and other attributes.

For example if we have 2 x 10Gbe and 2 x 1Gbe interfaces on the storage host we could define a portal group named Prod-tpg for the 10Gbe interfaces and Test-tpg for the 1Gbe interfaces and then define iSCSI targets to each by way of a tpg membership.

Regards,

Mike

By: Roman

Roman — Sat, 25 Jul 2009 23:12:17 +0000

Hello Mike,

Comstar plus iscsi authentication is an interesting topic.
There is also tpg option for itadm. Do you know how it works?

itadm create-tpg tpg-name IP-address[:port] [IP-address[:port]] [...]

–
Roman