| Author |
Message |
Valeriy Glushkov
Guest
|
 Posted:
Mon Sep 05, 2005 3:42 pm Post subject:
An issue with the MS iSCSI initiator's ISID values |
|
|
Hi All,
There is an issue with the MS initiator that it uses 2 different ISID values
in its iSCSI sessions.
(the values are 0x400001370000 and 0x400001370001).
It seems for me the values are chosen randomly or so.
According to the iSCSI specs an initiator may use any ISID values it wants,
ever connecting to the same target several times if the target allows this.
But this leads to the problem with session reinstatement when the initiator
machine is rebooted or the connection is broken.
If the initiator uses the same ISID value, the target (I tested this with
the RDS StarWind 2.6.4) sees the old session from the initiator name/ISID is
present and closes it, allowing the new session to be established.
But in the case the MS initiator chooses to use the other ISID value, the
target takes it for the other iSCSI initiator entity (as the name+ISID pair
is different) and rejects the connection if the target device allows only 1
session per time.
The question is:
Why the MS initiator behaves so strange with ISID values and HOW to make it
to use the same ISID all the time?
Thank you in advance.
--
Best regards,
Valeriy Glushkov |
|
| Back to top |
|
 |
Valeriy Glushkov
Guest
|
| Posted:
Wed Sep 07, 2005 4:17 pm Post subject:
RE: An issue with the MS iSCSI initiator's ISID values |
|
|
I wonder if anybody from the MS iSCSI initiator support team knows the answer
to my question... ;)
"Valeriy Glushkov" wrote:
| Quote: | Hi All,
There is an issue with the MS initiator that it uses 2 different ISID values
in its iSCSI sessions.
(the values are 0x400001370000 and 0x400001370001).
It seems for me the values are chosen randomly or so.
According to the iSCSI specs an initiator may use any ISID values it wants,
ever connecting to the same target several times if the target allows this.
But this leads to the problem with session reinstatement when the initiator
machine is rebooted or the connection is broken.
If the initiator uses the same ISID value, the target (I tested this with
the RDS StarWind 2.6.4) sees the old session from the initiator name/ISID is
present and closes it, allowing the new session to be established.
But in the case the MS initiator chooses to use the other ISID value, the
target takes it for the other iSCSI initiator entity (as the name+ISID pair
is different) and rejects the connection if the target device allows only 1
session per time.
The question is:
Why the MS initiator behaves so strange with ISID values and HOW to make it
to use the same ISID all the time?
Thank you in advance.
--
Best regards,
Valeriy Glushkov |
|
|
| Back to top |
|
|
Alan Warwick [MSFT]
Guest
|
| Posted:
Wed Sep 07, 2005 4:17 pm Post subject:
Re: An issue with the MS iSCSI initiator's ISID values |
|
|
I am going to assume you are using 2.0 which handles ISIDs differently from
1.0.
When using a persistent login the ISID is assigned when the persistent login
is created and that ISID is always reused.
When doing a non persistent login the initiator service will select the next
available ISID in an attempt to reuse the ISIDs as much as possible. For
example if you login to target A you will get an ISID ending in 0. If you
stay logged in and login a second session to A then you will get an ISID
ending in 1. However if you login to A, logout of A and then login to A
again you will get an ISID ending in 0.
In any case the 1.0 behavior that picks a different ISID for each login does
not violate the spec but does cause issues for targets that do not expect
that behavior.
--
--------------------------------------------------------------------------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
"Valeriy Glushkov" <gvvua@NOSPAMua.fm> wrote in message
news:u6nQEbgsFHA.1252@TK2MSFTNGP09.phx.gbl...
| Quote: | Hi All,
There is an issue with the MS initiator that it uses 2 different ISID
values
in its iSCSI sessions.
(the values are 0x400001370000 and 0x400001370001).
It seems for me the values are chosen randomly or so.
According to the iSCSI specs an initiator may use any ISID values it
wants,
ever connecting to the same target several times if the target allows
this.
But this leads to the problem with session reinstatement when the
initiator
machine is rebooted or the connection is broken.
If the initiator uses the same ISID value, the target (I tested this with
the RDS StarWind 2.6.4) sees the old session from the initiator name/ISID
is
present and closes it, allowing the new session to be established.
But in the case the MS initiator chooses to use the other ISID value, the
target takes it for the other iSCSI initiator entity (as the name+ISID
pair
is different) and rejects the connection if the target device allows only
1
session per time.
The question is:
Why the MS initiator behaves so strange with ISID values and HOW to make
it
to use the same ISID all the time?
Thank you in advance.
--
Best regards,
Valeriy Glushkov
|
|
|
| Back to top |
|
|
Valeriy Glushkov
Guest
|
| Posted:
Thu Sep 08, 2005 8:16 am Post subject:
Re: An issue with the MS iSCSI initiator's ISID values |
|
|
Hi Alan,
Thank you for the answer.
I saw the issue with MS iSCSI initiator 1.06 and 2.0.
| Quote: | When using a persistent login the ISID is assigned when the persistent
login
is created and that ISID is always reused.
|
The problem is ISID can change ever for persistent logins.
I created a persistent session, it used ISID value 0x400001370000.
After that the machine was rebooted, and the initiator tried to reconnect
using the ISID 0x400001370001.
In the case when the old TCP/IP connection was not closed properly for some
reason, the target is unable to do session reinstatement in the right way
because of the different ISIDs...
| Quote: | When doing a non persistent login the initiator service will select the
next
available ISID in an attempt to reuse the ISIDs as much as possible. For
example if you login to target A you will get an ISID ending in 0. If you
stay logged in and login a second session to A then you will get an ISID
ending in 1. However if you login to A, logout of A and then login to A
again you will get an ISID ending in 0.
|
Can you tell me why the initiator need to use different ISIDs except of the
MPIO scenarios?
IIRC according to the iSCSI specs, an iSCSI session must have an unique I_T
nexus value that is constructed from:
- InitiatorName + ISID
- TargetName + TargetPortalGroupTag
The only situation where you need to use different ISIDs is to connect to
the same target via the same target portal group more than one time (MPIO).
In all other scenarios there is no need changing the default ISID...
| Quote: | In any case the 1.0 behavior that picks a different ISID for each login
does
not violate the spec but does cause issues for targets that do not expect
that behavior.
|
Yes, this definitely cause issues for some targets, especially when the
initiator version 2.0 does it the same way. ((
Do you agree with me that in session reinstatement scenarios an initiator
must use the same ISID it used for the old session?
If yes, are there any chances that the issue will be fixed in the next
versions of the MS initiator?
Thank you in advance.
--
Best regards,
Valeriy Glushkov
"Alan Warwick [MSFT]" <alanwar@online.microsoft.com> wrote in message
news:ONHPrt7sFHA.1204@TK2MSFTNGP15.phx.gbl...
| Quote: | I am going to assume you are using 2.0 which handles ISIDs differently
from
1.0.
When using a persistent login the ISID is assigned when the persistent
login
is created and that ISID is always reused.
When doing a non persistent login the initiator service will select the
next
available ISID in an attempt to reuse the ISIDs as much as possible. For
example if you login to target A you will get an ISID ending in 0. If you
stay logged in and login a second session to A then you will get an ISID
ending in 1. However if you login to A, logout of A and then login to A
again you will get an ISID ending in 0.
In any case the 1.0 behavior that picks a different ISID for each login
does
not violate the spec but does cause issues for targets that do not expect
that behavior.
--
--------------------------------------------------------------------------
------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Valeriy Glushkov" <gvvua@NOSPAMua.fm> wrote in message
news:u6nQEbgsFHA.1252@TK2MSFTNGP09.phx.gbl...
Hi All,
There is an issue with the MS initiator that it uses 2 different ISID
values
in its iSCSI sessions.
(the values are 0x400001370000 and 0x400001370001).
It seems for me the values are chosen randomly or so.
According to the iSCSI specs an initiator may use any ISID values it
wants,
ever connecting to the same target several times if the target allows
this.
But this leads to the problem with session reinstatement when the
initiator
machine is rebooted or the connection is broken.
If the initiator uses the same ISID value, the target (I tested this
with
the RDS StarWind 2.6.4) sees the old session from the initiator
name/ISID
is
present and closes it, allowing the new session to be established.
But in the case the MS initiator chooses to use the other ISID value,
the
target takes it for the other iSCSI initiator entity (as the name+ISID
pair
is different) and rejects the connection if the target device allows
only
1
session per time.
The question is:
Why the MS initiator behaves so strange with ISID values and HOW to make
it
to use the same ISID all the time?
Thank you in advance.
--
Best regards,
Valeriy Glushkov
|
|
|
| Back to top |
|
|
valery
Guest
|
| Posted:
Mon Sep 19, 2005 4:11 pm Post subject:
Re: An issue with the MS iSCSI initiator's ISID values |
|
|
Hi Alan,
Have you missed the posting or have no time to answer to it?
Could you please clarify the issue with ISIDs?
Thank you in advance.
Regards,
Valeriy Glushkov
-------
Valeriy Glushkov Sep 8, 9:54 am
Hi Alan,
Thank you for the answer.
I saw the issue with MS iSCSI initiator 1.06 and 2.0.
| Quote: | When using a persistent login the ISID is assigned when the persistent
login
is created and that ISID is always reused.
|
The problem is ISID can change ever for persistent logins.
I created a persistent session, it used ISID value 0x400001370000.
After that the machine was rebooted, and the initiator tried to
reconnect
using the ISID 0x400001370001.
In the case when the old TCP/IP connection was not closed properly for
some
reason, the target is unable to do session reinstatement in the right
way
because of the different ISIDs...
| Quote: | When doing a non persistent login the initiator service will select the
next
available ISID in an attempt to reuse the ISIDs as much as possible. For
example if you login to target A you will get an ISID ending in 0. If you
stay logged in and login a second session to A then you will get an ISID
ending in 1. However if you login to A, logout of A and then login to A
again you will get an ISID ending in 0.
|
Can you tell me why the initiator need to use different ISIDs except of
the
MPIO scenarios?
IIRC according to the iSCSI specs, an iSCSI session must have an unique
I_T
nexus value that is constructed from:
- InitiatorName + ISID
- TargetName + TargetPortalGroupTag
The only situation where you need to use different ISIDs is to connect
to
the same target via the same target portal group more than one time
(MPIO).
In all other scenarios there is no need changing the default ISID...
| Quote: | In any case the 1.0 behavior that picks a different ISID for each login
does
not violate the spec but does cause issues for targets that do not expect
that behavior.
|
Yes, this definitely cause issues for some targets, especially when the
initiator version 2.0 does it the same way. ((
Do you agree with me that in session reinstatement scenarios an
initiator
must use the same ISID it used for the old session?
If yes, are there any chances that the issue will be fixed in the next
versions of the MS initiator?
Thank you in advance.
--
Best regards,
Valeriy Glushkov |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in