no DHCP-assigned InitiatorName
I am writing this memo to the IETF IP Storage Working Group to voice my
concern over the apparent lack of IETF or industry standard for having a
DHCP server pass an InitiatorName to an iSCSI boot client.
This issue may be something that you are already aware of, and may be
something that you are already working to address.
(I am going to ignore the related issues of CHAP username and secret)
rfc4173 [http://tools.ietf.org/html/rfc4173 Bootstrapping Clients using
the Internet Small Computer System Interface (iSCSI) Protocol) defines
the protocol for passing boot target information to an iSCSI boot client
via DHCP options. Unfortunately, it does not define a mechanism for
passing an InitiatorName to be used by the iSCSI boot initiator. The
omission of this has led to differences in the InitiatorName in
different iSCSI boot implementations.
Many iSCSI target servers depend upon the iSCSI InitiatorName to control
visibility to target LUNs. The inability to control InitiatorName
through DHCP leads to interoperability issues as one tries to
dynamically move between systems with different iSCSI boot implementations.
I am not familiar with iSNS (Internet Storage Naming Service
http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName
probably plays a key role in identification.
I am familiar with several currently available implementations of iSCSI
initiators ... hardware, firmware, and software. see listing below.
The hardware and firmware implementations of iSCSI boot initiators
(QLogic, Intel, Broadcom, IBM) allow one to define static initiator and
target login information in EEPROM on the client. In addition, they all
support a DHCP assigned iSCSI boot target per RFC 4173.
The etherboot/gPXE implementation only supports assignment of iSCSI boot
parameters via DHCP.
Implementations generally construct the InitiatorName by trying to
include the DHCP option 12 hostname. They take a base iSCSI Qualified
Name prefix and concatenate the hostname supplied by the DHCP server.
You end up with:
iqn.1987-05.com.intel:<hostname>
iqn.2000-01.org.etherboot:<hostname>
iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname>
<hostname> represents the hostname provided in DHCP option 12.
<11.22.33.44.55.66> represents the MAC address of the initiator NIC.
This might work fine in a static data-center environment where dedicated
applications run on dedicated hardware. Even a mixed environment with
different vendors involved is generally not a problem as long as each
system is configured individually ... and as long as no system changes
are required.
However, data centers and data center configurations are not static.
They frequently have a need to move from one hardware configuration to
another. Common examples are a planned hardware upgrade of an existing
system and an emergency hardware replacement for a failed system. A more
extreme example would be an offsite disaster-recovery scenario.
Machine virtualization tools such as vmWare and Zen facilitate moving
images between systems, easing the transition between system hardware.
Data center virtualization systems such as Scalent automate assignment
of SAN-based applications to available servers in the server pool,
effectively enabling a data center to run any application on any
available physical or virtual machine.
Migrating iSCSI boot images from one system to another is problematic if
the iSCSI boot implementations differ between the old hardware and new
hardware. On many/most commercial iSCSI target servers the
visibility/mapping/zoning configuration would have to change because of
the differing iSCSI InitiatorName. This is a problem because it usually
requires coordination across organizational units.
Take the case where one has an application running on an IBM server
using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One
wishes to move this application to an HP server with an Intel NIC that
supports iSCSI boot. Both iSCSI initiators support DHCP assignment of
the iSCSI target. However, since the full InitiatorName is not specified
via DHCP, the SAN administrator must also make a change on the iSCSI SAN
storage controller in order to make the appropriate LUN(s) visible to
the new/different initiator name.
Vendor Extensions
Broadcom and IBM seem to have foreseen this oversight in rfc4713. From
available documentation it is unclear to me whether or not they have
adopted exactly the same mechanism as a workaround for assigning the
iSCSI boot initiator name. I am in the process of obtaining hardware so
that I can verify behavior.
Broadcom documentation indicates that they support a DHCP vendor
extension that allows one to fully specify the InitiatorName from the
DHCP server. Support for an option such as this would mean that
boot-from-iSCSI-SAN images could be moved between systems by only making
changes on the DHCP server. See
http://ftp.us.dell.com/network/Bcom_LAN_11.0_4.1_Manual_A01.exe
Draft IBM documentation at
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf
indicates that the initiator name can be set using DHCP vendor option
203 … but it isn’t very specific … and I have not been able to verify this.
I have also been told that the Microsoft WHQL (Windows Hardware Quality
Labs) requirements for iSCSI boot make reference to “DHCP option 203”. I
am trying to obtain these documents.
Conclusion
There needs to be a standard IETF mechanism, perhaps an extension to
rfc4713, that defines what InitiatorName is to be used when iSCSI booting.
I am interested in participating in the discussion and am willing to
help however I can.
Michael Howard
Scalent Systems
michael.howard@xxxxxxxxxxx
----
Internet Small Computer Systems Interface (iSCSI)
http://tools.ietf.org/html/rfc3720
Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery
http://tools.ietf.org/html/rfc3721
String Profile for Internet Small Computer
Systems Interface (iSCSI) Names
http://tools.ietf.org/html/rfc3722
Internet Storage Naming Service (iSNS)
http://tools.ietf.org/html/rfc4171
Bootstrapping Clients using the Internet
Small Computer System Interface (iSCSI) Protocol
http://tools.ietf.org/html/rfc4173
----
QLogic
* hardware iSCSI HBAs
* proprietary drivers for Win + Linux
* http://qlogic.com/Products/SAN_products_iSCSI.aspx
* supports DHCP assignment of target parameters
Intel
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >= win2k3
* http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15864
* iqn.1987-05.com.intel:<hostname>
Broadcom
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >= win2k3
* http://www.broadcom.com/collateral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf
* iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
* Vendor extension DHCP option 43 suboption 203
IBM
* iSCSI NIC firmware in selected blades/servers
* works in conjunction with MSFT initiator under >= win2k3
* http://www.alphaworks.ibm.com/tech/sancommander
* ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf
* vendor extension option 203
emBoot
* software PXE/UNDI implementation
* proprietary windows initiator under XP & win2k with netBoot/i
* works with MSFT initiator under >= win2k3
* http://emboot.com/iscsiboot.htm
emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i
products to assign login information to their software initiator. emBoot
does not support DHCP assignment of iSCSI boot parameters. Therefore,
the discussion of DHCP assignment of iSCSI boot parameters is not
applicable to emBoot’s current products.
etherboot/gPXE
* open source PXE/UNDI/NIC driver implementation
* works with MSFT initiator under >= win2k3
* http://etherboot.org/wiki/index.php
* only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473.
THE END
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]
