Simultaneously using iSLB and iSCSI initiators

There is an interesting pitfall I discovered today while configuring iSLB and iSCSI initiators simultaneously.

Take the following iSLB configuration:

Host is WIN1, IP address 10.0.0.1, iqn.initiator-win1
iSLB portal is 10.0.1.1


islb initiator name iqn.initiator-win1
vsan 20
vsan 30
target pwwn 21:00:00:04:cf:9c:d4:c7 vsan 20 no-zone sec-pwwn 22:00:00:04:cf:9c:d4:c7 sec-vsan 30 iqn-name iqn.target.j1a1b1
! [J1A1] [J1B1]

interface GigabitEthernet2/1.101
ip address 10.0.1.1 255.255.255.0
no shutdown

interface iscsi2/1
switchport proxy-initiator nWWN 21:00:00:00:00:00:00:05 pWWN 21:00:00:00:55:55:55:55
no shutdown

Alot has been omitted just to keep things less confusing, for example I have left out the zoning configuration. The host connects to 10.0.1.1 and can discover target iqn.target.j1a1b1 without a problem. The host is in VSAN 20 and 30, this is done using the initiator configuration. There is a proxy-initiator configured for this portal so the host will show up as pWWN 21:00:00:00:55:55:55:55 and need to be zoned accordingly. This works fine. You can have a proxy-initiator configuration and still have an initiator configuration where you can set things like VSAN membership.

So now you configure the same host in an iSCSI configuration (simultaneously). The host has two IP addresses on its iSCSI NIC, one you used for iSLB and now a secondary address you use for iSCSI:

Host is WIN1, IP address 10.0.10.1, iqn.initiator-win1
iSCSI portal is 10.0.2.1
interface iSCSI 2/2 is in VSAN 20
target iqn.target-disk-j2a1 is in VSAN 20

The configuration is as follows:


iscsi virtual-target name iqn.target-disk-j2a1
pWWN 21:00:00:04:cf:9c:d4:bf
advertise interface GigabitEthernet2/2.102
initiator ip address 10.0.10.1 permit

interface GigabitEthernet2/2.102
ip address 10.0.2.1 255.255.255.0
no shutdown

interface iscsi2/2
switchport initiator id ip-address
no shutdown

So you try to connect using IP addreess 10.0.10.1 and connect to portal 10.0.2.1 but you do not see any storage (assume the zoning configuration is correct). This portal is in transparent mode. So the initiator will be seen coming from it’s own IP address and a pWWN will be created automatically. The iSCSI portal has been configured to use ip-address for ID. What ends up happening is that the initiator does not see its storage. If you look at “show iscsi initiators” you will see its in fact getting caught up as an iSLB initiator. In order to resolve this you have to make its own initiator configuration by IP address for iSCSI:

iscsi initiator ip-address 10.0.10.1
vsan 20

I would not think it should work this way, but it does. I would have thought since we connect to the iSCSI portal which is set to use ip-address for ID it would not try to match against a initiator configuration done by IQN. And since the iSCSI interface is in VSAN 20, then you would think the initiator would be in VSAN 20 and see the storage which is in VSAN 20.

So be careful if you are configuring multiple initiators on a host and using multiple portals. Once you configure the IQN name its going to match any IP address coming from that host, since hosts only have one IQN name. This is sort of a catch-all glob, and even though you would not normally have to, you must configure a specific initiator to prevent the session from matching the wrong initiator configuration.

Hope this makes sense, happy labbing!

This entry was posted in CCIE Storage, iSCSI / iSLB and tagged , , , . Bookmark the permalink.

Leave a Reply