cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Field Notice 70545
2127
Views
18
Helpful
8
Replies
visitor68
Enthusiast

CNA LUN Discovery

How does an CNA actually discover a LUN/storage array entity? There are very detailed explanatins about how a CNA logs into the fabric using FIP FLOGI and FDISC and how the ENode is assigned an FPMA that consists of an FC-MAP and an FC_ID, but the explanation stops there.

So, how does the CNA see the FC array? Does it have something to do with the way the CNA is configured? Never configured one...

8 REPLIES 8
mfrase
Beginner

LUN discovery is done by SCSI, reports LUNs is one of many commands done in the SCSI stack.   T10,org is organization that handles the SCSI command and device structures in the standards.

Frase:

Thank you. But I want to know when it is that the CNA learns of the LUN. What mechanism is used and when is that mechanism executed?

So, imagine I plug an FCoE array (or FC into the FC ports) into an FCoE switch - how do the CNAs connected to that FCoE switch learn of the newly connected device?

Because first of all the adapter must log into the FC fabric, meaning you have to allow it access by registering him unless you have an auto registration system as some do.  After registered no matter the method you then have to put that WWN he is using and associate it to a zone or group.  He can then see what's in that zone when he scans.  When booting from SAN or if you dont want him to see all LUNs in that zone, you then apply the masking so he sees what you want him to see.  Particularly important for BOOT from SAN when each guy can ONLY see his boot LUN, and also all boot luns must be LUN 0 to make a broad statement and not address the instances where they dont have to be, 0 is best practices for booting volume.  IT's not magic, it does scan and find on it's own, but only what you allow him to scan and only once allowed into that fabric.

As part of the protocol instructions in the internal FC component on the CNA (same as on a standard FC HBA)

if SAN booting function is enabled in CNA bios has the base instructions to register with the name server and query the nameserver for storage devices, if storage devices are zoned to the CNA then the CNA will plogi and scan for SCSI LUNs on the storage array.  This is all required by the adaptor SAN boot logic to allow the user to select the lun he wishes to use to load image to.  If SAN boot bios is not enabled on the CNA then the CNA will use it's logic to flogi and keep FCID routing tables to all storage zoned to it, the scsi report luns query comes from the SCSI instructions within the O/S loaded on host for the CNA does not care about luns at this point. The CNA has the ability to register functions to the nameserver and respond to other standards based rmanagement commands, hence you see lots of fcs data in the switches for management of whats connected.

Hi, I'm not sure I totally understand....the lack of good sentence structure also made it a bit difficult to understand. I am assuming English is not your first language.

I do appreciate your help....thank you.

Ex,

CNA = FCoE

HBA = FC (native)

Just to add to Mike's comments, a CNA communicates with an FC array very similar to the same way any traditional HBA would.  The only differents is an other layer of encapsulation which plunks the standard FC frame within an FCoE header so it rides on ethernet rather than an FC link. 

There's no change in FC operation.  That's the beauty of FCoE.  The native FC frame remains unmodified so it can operate just has it always has. 

So your quesiton about "how does a CNA see a storage array" is more of a FC protocol operation question than anything else.  So for know let's look beyond the FCoE protocol and assume that's all setup correctly such that my Host can connect to an FC array.  We're also going to assume the Zoning and LUN Masking have been correctly configured. Zoning which is done on the SAN switches provides "what can other targets or initiators I can see", like an ACL for the Host.  Masking, which is done on the array provides "Now that I can see the target, what do I have access to?".

Imagine our topology looks like:

UCS Blade CNA=====[FCoE]====UCS Fabric Interconnect------[Native FC]------SAN Switch----[Native FC]-----SAN Array

The UCS Blade with the CNA will appear as separate Ethernet and FC HBA adaptors to the host operating System.  So as far as the host is concerned, it's going to speak to the Array using good old native FC.

As the FC protocol dicates, there are a set of stages or processes that are performed.  At a high level they look like:

1. The Initiator Sends our an FLOGI (Fabric Login Request) - think of this as a broadcast. This would hit the SAN Switch where FC fabric services are running.

2. If the FLOGI response is LS_RJT, the initiator resends FLOGI (till the max retry count expires).

3. If the FLOGI response is ACCEPT, that indicates that the initiator  has a link to a fabric/target. Initiator issues a PLOGI (Port Login  Request).

4. If the PLOGI response is LS_RJT, the initiator resends PLOGI (till the max retry count expires). This would hit the array.

5. If the PLOGI response is ACCEPT, this indicates that the initiator  is now permitted to talk to the process (or service) that is being  hosted on this port. So the initiator sends out a PRLI (Process Login  Request).

6. If the PRLI response is LS_RJT, the initiator resends PRLI (till the max retry count expires). This is processed by the array's storage processors.

7. If the PRLI response is ACCEPT, that indicates that the initiator  is successfully connected to the target, and now SCSI FCP operations can  be performed. This is like the full feature phase where the initiator  can issue SCSI commands, send and receive data, and receive SCSI command  response & status issued by the target device.

**At this stage it the Host can perform a scan of available LUNs called a SCSI REPORT, and the Target will present back the appropriate LUNs that have been correclty masked on the array.

Once the initiator is done, it can gracefully perform a logout as follows:

8. The initiator sends a PRLO (Process Logout Request) to the target.

9. If the PRLO response is LS_RJT, the initiator retries the Logout.

10. If the PRLO response is ACCEPT, the initiator sends our LOGO (Port logout Request).

11. If the LOGO response is LS_RJT, the initiator retries the Logout.

12. If the LOGO response is ACCEPT, the session ends.

[Courtesy: http://sansimplified.com/blog/2011/03/01/fibre-channelfc-login-and-scsi-fcp-porcess-login/]

**All the commands in upper case are the actual SCSI commands.  Full reference available here:

http://en.wikipedia.org/wiki/SCSI_command

If we're still missing the mark to your question, let us know and we'll keep at it until you're satisfied!

Cheers,

Robert

Robert, youve given some good info. Appreciate it.

I am pretty well versed on FCoE actually. But not a sinle explanation of FLOGI, PLOGI or PRLI I have read on the Internet answers my question. They give you mechanics of how somethign works, but never an understanding of WHY you are performing these logins. The FLOGI is self explanatory: the FC entity, whether an HBA or the HBA component of a CNA, has to log into the FC fabric. When it logs in, it typically receives a 48-bit FPMA (fabric provided MAC address); the higher order 24 bits are referred to as the FC-MAP and the second 24 bits comprise the FCID or sometimes referred to as the N_Port ID.

During the FIP VLAN discovery and FCF solicitation functions, (both of which are FCoE constructs and don't need to existt in native FC), the E_Node MAC address (which I believe is the factory-set BIA) is used as the source MAC address, while the destination address is the All-FCF-MACs address. FIP VLAN discovery is tagged with a VLAN 1 tag until the FIP process is informed of the FCoE VLAN being used in the FCOE fabric.

The state of affairs after the FLOGI is complete is that the fabric switch will create a table that binds the WWPN to the FCID for a particular N_Port and that each E_Node will create a database of available FCFs, along with their priority numbers.

Now, this is where I get fuzzy. I BELIEVE (not sure) that another result of the FLOGI process is that each E_Node's N_Ports will be aware of the EXISTENCE of and the CAPABILITIES of other N_Ports that are logged into the fabric.

Let's get this part cleared up before we go further.

Thanks

The answer is HERE: Finally!

http://www.nlabooks.com/downloads/Node%20Port%20Initialization.pdf

Name Server registration by E_Node N_Ports, Name Server query/Port Discovery and PLOGI....

Create
Recognize Your Peers
Content for Community-Ad