Whenever you’ve encountered an output of a nameserver entry you may have come across the phenomenon that the fabric has no clue what the attached device is. For a FC switch an attached device (or N-port in technical terms) is not more than a source or destination where frames originate from or can be sent to. As soon as smarter functions are required it may be helpful (or required) to be able to obtain more information from that device.

You may have heard about peer zoning and smart-zoning depending from which vendor you use the equipment. I wrote an article about peer zoning before (see here)so iI’ll leave that for now.

With Cisco’s Smart Zoning you’re able to create zoned where an initiator is only to “talk” to target and targets only to initiators. This provides the ability for you to create a smart-zone with only one target and multiple initiators without having the risk of initiators running into issues when other initiators in that same zone start behaving erroneous. If for instance one HBA is causing troubles and is sending multiple State Change Notifications normally every N-port (who actually registered and subscribed to receive these) will also receive these after which these N-ports will need to start making new inquiries to see if anything has changed in the fabric. This may cause a strain on the switch CPU’s as well as far reaching fabric issues when multiple switches in that fabric are involved.

So ROT (Rule of Thumb) #1: Have only the paths configured and active that are an absolute requirement.

Who is doing what in a fabric?

N-ports can have one of three functions. Initiator, Target or both. The function that is actually active depends on what the N-port is configure to do. An HBA is normally set to be an initiator but, if the OS and drivers permit, can also be a target. Solaris is a good example who provided this functionality back in the SUN-days. (as in SUN the company, not the day of the week. :-)) Arrays are normally set to target mode but when arrays are visualized behind other array they start functioning as initiators. The same is true for arrays that provide replication functionality and the primary array port will be in initiator mode whilst the secondary array is set to target mode.

Some arrays allow port to function in some sort of hybrid mode where the same port can be used to provision LUNs to host as well as function as replication initiators. In that way both functions will be active.

The nameserver as the yellowpages.

When a N-port is in the process of participating in the fabric  at some stage will ask for a list of remote N-ports is can talk to. It does this via a special command to the name-server called a GNN_FT (Get Node Name with FC4 type code). In a Open Systems environment this will always be 0x08 (FCP/SCSI). The nameserver will then provide a list of WWN’s to which that N-port is allowed to “talk” to who also have regsitered with the nameserver and their ability to provide FCP/SCSI functionality . At that moment the HBA does not have a list of fabric-addresses (these 32 bit addresses consisting of domain, port and area ID) so it is not able yet to send a PLOGI to those devices in order to announce itself and start communicating. For that to accomplish it sends another command called a GID_PN for each of the WWN’s it had obtained earlier.

The fabric nameserver then provides the 32-bit address of that N-port. It does not know if that remote N-port is a initiator or target so frome there on it has two options. Either it requests the nameserver for the supported FC4 feature (Target/Initiator) on the FCID it has in order to be able to establish if the remote port has a target function or not, or it may simply send a PLOGI to that remote N-port and if it gets a Reject the reject code will show a reason code in the lines of “not supported”.

Registration

So how does a nameserver get the information from the devices attached to the switches.

When an N-port is registering with the name server is does this via a PLOGI. The PLOGI informs the name-server of the WWN, FCID, plus a number of service parameters belonging to the class of service the N-port is supporting.  Additional information may be provided in the form of a RFT_ID Register FC4 types (Ficon, FCP, IPFC etc) and RFF_ID (FC4 Features ie Target/Initiator/Both in  FCP or SB-4 structures in a Ficon environment)

Examples of how these values get represented in the Broade and Cisco nameserver is shown below.

No FC4 feature support:

N 01eb40; 3;50:06:0e:80:12:3a:f0:05;50:06:0e:80:12:3a:f0:05; 0x00000003
SCR: Fabric-Detected Nx-Port-Detected
FC4s: FCP
Fabric Port Name: 20:52:c4:f5:7c:66:ac:54
Permanent Port Name: 50:06:0e:80:12:3a:f0:05
Device type: Physical Unknown(initiator/target)
Port Index: 82
Share Area: Yes
Redirect: No
Partial: No
LSAN: No
Slow Drain Device: No
Device link speed: 8G
Connected through AG: No
Real device behind AG: No
FCoE: No

Only target support in an FCP(SCSI) environment.

N 01eb00; 3;50:06:0e:80:12:3a:f0:14;50:06:0e:80:12:3a:f0:14; 0x00000003
SCR: Fabric-Detected Nx-Port-Detected
FC4s: FCP
Fabric Port Name: 20:53:c4:f5:7c:66:ac:54
Permanent Port Name: 50:06:0e:80:12:3a:f0:14
Device type: Physical Target
Port Index: 83
Share Area: Yes
Redirect: No
Partial: No
LSAN: No
Slow Drain Device: No
Device link speed: 16G
Connected through AG: No
Real device behind AG: No
FCoE: No
FC4 Features [FCP]: Target

Only initiator support on an array.

the below N-port is from a Hitachi array where its function is either a Replication Initiator or an initiator to virtualize an external array. It provides no target functionality.

N 01ea80; 3;50:06:0e:80:07:c3:70:03;50:06:0e:80:07:c3:70:03; 0x00000003
SCR: Fabric-Detected Nx-Port-Detected
FC4s: FCP
Fabric Port Name: 20:55:c4:f5:7c:66:ac:54
Permanent Port Name: 50:06:0e:80:07:c3:70:03
Device type: Physical Initiator
Port Index: 85
Share Area: Yes
Redirect: No
Partial: No
LSAN: No
Slow Drain Device: No
Device link speed: 8G
Connected through AG: No
Real device behind AG: No
FCoE: No
FC4 Features [FCP]: Initiator

 

The display of the same values in a Cisco environment is somewhat different although the information itself is basically the same.

`show fcns database vsan 1-4093`

VSAN XYZ1:
————————————————————————–
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
————————————————————————–

<snip>

0x640800 N 50:06:0b:00:00:c2:8e:12 (HP) ipfc scsi-fcp:init
[xxxxxxxxxxxxxxxxxx]
0x640900 N 20:00:00:11:0a:04:40:6c
0x640940 N 50:00:09:79:78:03:d4:cb (EMC) scsi-fcp:target 253
[xxxxxxxxxxxxxxxxxx]
0x641300 N 50:06:0b:00:00:c2:8e:1a (HP) ipfc scsi-fcp:init
[xxxxxxxxxxxxxxxxxx]
0x641400 N 50:06:0b:00:00:c2:82:02 (HP) ipfc scsi-fcp:init
[xxxxxxxxxxxxxxxxxx]
etc etc

 

The standard

As some of the Fibre Channel functions and features are optional in the official standard, not all vendors are opting to develop code for these functions and provide all functionality although recent equipment is getting better at it.

Still many vendors leave a lot to wish for in the FC world where new functionality is only slowly adopted and significantly play second fiddle to everything that is possible compared to the Ethernet/TCPIP world.

Hope this brings some clarity in how information is pushed and pulled into and from the fabrics.

Regards,

Erwin