Portal Hopping

 

The Microsoft iSCSI Software Initiator implements a number of key features in the initiator to protect against loss of connectivity to an iSCSI target.  These include support for Microsoft MPIO, (MCS) multiple connections per session, portal hopping,  as well as advanced error recovery. 

The loss of connection to an iSCSI target portal could be due to one of the following reasons:

1. Connection drops unexpectedly without notification from the target which can result from transient network errors or other conditions

2. Unexpected connection loss without prior notification from the target.

3. Connection loss as  a result of an iSCSI target dropping connections through an async logout

If multiple portals are available for the target, portal hopping is designed to the try establishing a connection to alternate portals automatically

Configuring portal hopping:

 

 

 

 

 

 

This feature can be enabled or disabled via the Advanced setting of the "Logon to the Target" page in the Microsoft iSCSI GUI.

 

Steps:

Portal hopping operates by default without requiring user configuration.  When you're creating the connection to the iSCSI target from the initiator UI, just make sure  "default" in "Target Portal" list is used.    To disable this feature, specify a specific target portals instead.  With Portal Hopping disabled, the Microsoft Initiator will only try to attempt to recover the iSCSI session via the target portal used in the original iSCSI login.

There are situations where using Portal Hopping is not desirable.  For example, in a configuration that has multiple physical networks or multiple VLANs, it is possible that some of the target portals are not accessible to a given host.  In this situation, SendTargets responses sent by the iSCSI target will advertise some addresses which may not be accessible by the host. 

If the number of inaccessible target portals advertised in the SendTargets response is large, Portal Hopping may cause a  delay to recover the iSCSI session.  After the initial attempt to connect to the original target portal fails, the Microsoft Initiator attempts to connect to other target portals which are not accessible.  It may take a long time for the Microsoft Initiator to cycle through the list of inaccessible target portals before it makes another attempt to the original target portal.

Recommendation:

If multiple ports exist, it's better to use MPIO or MCS and use explicit addresses for both initiator & target to ensure alignment between the virtual connection and the physical link.  This offers a more deterministic approach to redundancy.   Portal hopping does offer a good solution to ensure continuous IO flow for single port environments and configurations that don't use MPIO or MCS.