Subject: [Ips] detection of failed sessions to allow re-login

From: "Paul Hughes" <[email-masked]>
Date: Thu, 19 Apr 2007 17:13:49 -0600

I have a question about how a target can quickly detect session failures
so that a re-login can succeed.
 
Here's my scenario:
 
1) an initiator is booting from an iSCSI target
2) the initiator is using an iSCSI HBA to communicate with the iSCSI
target
3) the HBA BIOS creates the first session, discovers the boot LUN, and
reads the boot loader
4) the boot loader reads the kernel from the boot LUN
5) the kernel resets the iSCSI HBA while loading an HBA driver
6) the HBA driver attempts to create a new session
 
The problem I'm seeing is that the target is failing the login for the
new session because the target thinks the first session created by the
HBA BIOS is still valid (not in failed state).  The HBA reset was not
detected by the target soon enough for the target to know that the first
session is now in the failed state when the initiator attempts to login
and create the second session using the same InitiatorName, ISID,
TargetName, and TargetPortalGroupTag as the first session (with TSIH=0).
The target does not see a link down event because a switch is connected
between the HBA and the target port.  The target eventually detects that
the first session is failed when it sends a NOP-Out PDU and receives a
transport failure.  Unfortunately, this occurs too late and the boot
fails.
 
In my case the target is sending NOP-Out PDUs every 60 seconds.  I can
change that to 5 seconds, but I don't think that will fix every case.
Is there a better way for the target to determine that the first session
has failed so that a re-login will succeed on the first try?
 
Thanks,
Paul

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Sandars, Ken" <[email-masked]>
Date: Thu, 19 Apr 2007 17:56:00 -0700

Hi Paul,
 
That's a target problem, most likely a bug. The second login with TSIH=0
tells the target to perform session reinstatement. That's jargon for
"silently nuke the first session".
 
The target may be failing the login because it's internal cleanup
requires more time (I/O requests from the previous session are jammed
for instance). Your scenario suggests this is not likely.
 
HTH,
Ken

________________________________

From: Paul Hughes [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 09:14
To: [email-masked]
Subject: [Ips] detection of failed sessions to allow re-login

Here's my scenario:

 
 
Thanks,
Paul

---

From: "Paul Hughes" <[email-masked]>
Date: Thu, 19 Apr 2007 19:36:32 -0600

Isn't session re-instatement possible only for sessions that are in the
failed state (no active connections)?  That was my understanding of
Section 5.3.5 of RFC 3720.
 
How can the target know that the session is in the failed state if it
hasn't detected that the only connection was dropped?
 
Thanks,
Paul

From: Sandars, Ken [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 6:56 PM
To: Paul Hughes; [email-masked]
Subject: RE: [Ips] detection of failed sessions to allow re-login

Hi Paul,

 
HTH,
Ken

 
Here's my scenario:

 
 
Thanks,
Paul

---

From: "Sandars, Ken" <[email-masked]>
Date: Thu, 19 Apr 2007 19:36:08 -0700

Hi Paul,
 
The full clause states the "initiator session state MUST be FAILED". The
initiator's perspective is different to the target's in this scenario.
The initiator has no session state (it's just been powered on), but the
target is not aware the HBA has been reset.
 
The target catches up with the initiator's view by detecting the TSIH=0,
which means the initiator denies all knowledge of any previous session
state. This is one of the specific scenarios that session reinstatement
was invented to resolve.
 
Cheers
Ken

From: Paul Hughes [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 11:37
To: Sandars, Ken; [email-masked]
Subject: RE: [Ips] detection of failed sessions to allow re-login

 
Thanks,
Paul

Hi Paul,

 
HTH,
Ken

 
Here's my scenario:

 
 
Thanks,
Paul

---

From: Julian Satran <[email-masked]>
Date: Fri, 20 Apr 2007 09:33:20 +0300

Paul,

"Paul Hughes" <[email-masked]> wrote on 20/04/2007 02:13:49:

> I have a question about how a target can quickly detect session 
> failures so that a re-login can succeed.
> 
> Here's my scenario:
> 
target
> 3) the HBA BIOS creates the first session, discovers the boot LUN, 
> and reads the boot loader
> The problem I'm seeing is that the target is failing the login for 
> the new session because the target thinks the first session created 
> by the HBA BIOS is still valid (not in failed state).  The HBA reset
> was not detected by the target soon enough for the target to know 
> that the first session is now in the failed state when the initiator
> attempts to login and create the second session using the same 
> InitiatorName, ISID, TargetName, and TargetPortalGroupTag as the 
> first session (with TSIH=0).  The target does not see a link down 
> event because a switch is connected between the HBA and the target 
> port.  The target eventually detects that the first session is 
> failed when it sends a NOP-Out PDU and receives a transport failure.
> Unfortunately, this occurs too late and the boot fails.
> 
> In my case the target is sending NOP-Out PDUs every 60 seconds.  I 
> can change that to 5 seconds, but I don't think that will fix every 
> case.  Is there a better way for the target to determine that the 
> first session has failed so that a re-login will succeed on the first 
try?

The target (if well integrated) has enough early warning that the old 
session/connection is gone (after all it established a new TCP 
connection!). But even if layering or "smart" HBAs stands in your way 3720 
states clearly that a login with the same identifying elements as an 
existing connection (including CID) should clear the connection (implicit 
logout). If the connection is the only connection of the session the 
result is equivalent to establishing a new session (except for some corner 
cases in which BIOS might have made some reservations which are then 
inherited by new connection).

So your boot should work whether the target interprets the login as a 
session clearing (somewhat different to what the 3270 text) or a 
connection clearing (that is what 3270 says).

If it doesn't work the target implementation is wrong.

Julo

---

From: "Paul Hughes" <[email-masked]>
Date: Fri, 20 Apr 2007 08:59:21 -0600

Thanks Ken, that clears up my confusion.
 
Paul

From: Sandars, Ken [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 8:36 PM
To: Paul Hughes; [email-masked]
Subject: RE: [Ips] detection of failed sessions to allow re-login

Hi Paul,

 
Cheers
Ken

 
 
Thanks,
Paul

Hi Paul,

 
HTH,
Ken

 
Here's my scenario:

 
 
Thanks,
Paul