FC Zoning and FC Discovery process

The short answer

If you’re familiar with FC Zoning as well as the FC protocol and don’t require a detailed explanation, the short answer is; “You no longer have a choice.  As of today, all of the FC/FCoE switches supported by EMC provide hardware enforcement for both “WWPN” and “Domain, Port” based zones”.  For the sake of completeness, there are some situations where hardware enforcement is effectively disabled but as long as your fan-in and fan-out ratios remain below 1:64 or 64:1 and/or you’re not using NPIV, you won’t need to worry about this.

Read on if you’d like a bit more detail.

The long answer…

As I started writing this section it quickly became apparent that I would need to provide an introduction to zoning and this leads to a discussion about FC Login, discovery, etc.  So I’ll start with the basics first and then get a bit more detailed as I go.  To start with, let’s assume a configuration similar to the following.

 

Starting from the left, the configuration consists of:

1)      A Host containing a single HBA/CNA port that has a WWPN (World Wide Port Name) of 10:00:00:00:00:00:00:00 and was assigned an FCID (Fibre Channel IDentifier) of 030100 during the Fabric login process.

2)      A FC Fabric containing two FC switches:

• FC/FCoE Switch Domain 3; and
• FC/FCoE Switch Domain 4

3)      A Storage array containing a port that has a WWPN of 50:00:09:71:20:30:40:50 and was assigned an FCID of 040200 during the Fabric login process.

A few points to take note of:

• This configuration could be all FC, all FCoE or a combination of both.
• The HBA/CNA and Storage Array ports both have a WWPN that is assigned to the port in some vendor specific way AND an FCID that is assigned to each port by the switch during Fabric Login.
• The middle byte of the FCIDs that I have shown correspond to the physical interface and this is not always the case (especially in Cisco environments)
• I will only be talking about Open Systems hosts in this post.  Apologies to FICON users, you’ll have to wait for FC-SB-5 to be finished before any of this applies to you.

What is a zone, zone set, configuration, etc

A zone is a collection of WWPNs, FCIDs or both that have been associated with one another for the purpose of allowing them to freely access one another.  Zones have to be added to a zone set or configuration and then activated onto a fabric in order for the access defined in the zone to become effective.  For example in the diagram below, I’ve updated the example topology so that it now shows a single zone named “TEST” that is a part of the Zone set/configuration “Test CFG” and contains two WWPN members.

A couple of important points to note:

1)      For all practical purposes, the zone set “Test CFG” could have been activated on any switch in the Fabric.  This is because when a zone set is activated it is pushed to every switch in the fabric simultaneously.

2)      As soon as the zone set has been activated, the zone members will be allowed to discover one another.  This is where the difference between hard zoning and soft zoning starts but before I dive into those details let’s talk about FC discovery first.

The FC Discovery process

In order for an HBA/CNA or storage port to use a fabric, it has to login, perform registration and then perform discovery.  This process is illustrated in the following diagram and explained in more detail in the text that follows.

 

Each time an FC port initializes, it must perform some kind of login process in order for it to be able to use the fabric.  In practice each HBA/CNA uses a slightly different login process but they all have certain things in common.  One example is the need to transmit FLOGI (Fabric Login) and receive an ACC (accept) from the fabric before attempting to do anything else.  I point this out because although in practice all of the HBA/CNA or storage port implementations that I am familiar with will perform the same basic steps, the order of steps 5, 7 and 9 may be slightly different and the exact commands used within each step may vary as well.

Step 0 (Not shown in diagram)

Assuming a port is initializing from the power off or loss of signal/sync state, speed negotiation and Link Initialization will be performed.  At the end of the Link Initialization process, the HBA/CNA or Storage port that is initializing will just be passing IDLE frames back and forth with the switch port it has been connected to and both ports will be considered to be in the ACTIVE state.

Step 1 (FLOGI)

FLOGI (Fabric Login) is the first frame transmitted by an end device that is attempting to attach to a switch.  The FLOGI contains many bits of information about this initializing end device (N_Port), but for the sake of the discussion on zoning, we only need to recognize that the initializing N_Port’s WWPN (World Wide Port Name) is included in the FLOGI.  As shown previously, this WWPN can be used in a zone to allow the initializing N_Port to access another N_Port.

Step 2 (FLOGI ACC)

Assuming the switch is functioning properly, is not too busy and there are no configuration parameters set on the switch that would prevent a particular N_Port from logging in, the switch will respond to the FLOGI with an FLOGI ACC.  The format of the FLOGI ACC is identical to the FLOGI request but the information contained within it will be specific to the responding switch/switch port.  Also, a VERY IMPORTANT piece of information that is relevant to zoning enforcement known as the FCID (Fibre Channel IDentifier) is provided to the N_Port in the FLOGI ACC.  Unlike the WWPN, this FCID will be present in every frame that will be transmitted by the N_Port and as you will see, the FCID effectively becomes the N_Port’s identity while logged into the fabric.  The relationship a WWPN has with the FCID it has been assigned by the fabric is one of the factors that allows for zoning to be enforced in hardware.

Step 3 (PLOGI NS)

One the FLOGI has been accepted by the switch, the N_Port will login with the Name Server.  Again, this has to be done in order for the N_Port to be able to register with and send queries to the Name Server.

Step 4 (PLOGI ACC)

Assuming the switch is functioning properly and is not too busy, it will respond to the PLOGI with PLOGI ACC.  The format of the PLOGI ACC is identical to the PLOGI request but the information contained within it will be specific to the responding switch/switch port.

Step 5 (Register with the Name Server)

Once the attaching N_Port is logged into the Name Server it may register with it.  There are many different registration commands that an N_Port could use but a typical one is RFT_ID or in plain English “Register the specified FC-4 Type for the provided FCID”.  In this case we will assume that all N_Ports involved either have or will register an FC-4 Type of “SCSI-FCP”.  Note, although it’s a bit out of scope for this post, I will mention that this isn’t usually the case.  Many N_Ports (especially targets) choose to register with the Name Server in multiple ways, the purpose for doing so is to ensure that no matter what Name Server query an initiator uses, the target will always be discoverable.

Step 6 (Name Server Accepts registrations)

Assuming the switch is functioning properly and is not too busy, it will accept the registrations.  If this fails, an attaching N_Port should retry.

Step 7 (SCR – State Change Registration)

The attaching N_Port will perform a full registration for RSCNs.  By doing so, the N_Port is requesting the switch to send it a Registered State Change Notification (RSCN) every time something in the fabric changes.  These changes currently include events like the addition and removal of a Domain (e.g., switch) as well as a zoning change being made to the fabric that impacts the device.

Step 8 (Fabric Controller accepts the State Change Registration)

Assuming the switch is functioning properly and is not too busy, it will accept the SCR

Step 9 (Query the Name Server)

At this point in the login process the attaching N_Port will query the Name Server in an attempt to discover what other devices are logged into the fabric and available for it to communicate with.  Since I stated that we would assume all N_Ports in the fabric would register an FC-4 type of SCSI-FCP (see step 5), we’ll assume that the attaching N_Port will use a Name Server query called GID_FT or in plain English “Get Port Identifiers for the devices that registered the specified FC-4 type” and will specify an FC-4 of SCSI-FCP.

And finally … information directly relevant to the topic of Hard Zoning versus soft zoning.

Step 10 (Name Server response to queries)

In response to the Name Server query, the switch will return a list of port identifiers (i.e., 030100 and 040200).  More specifically, the switch will only return the Port IDs for other FC devices that:

1. have registered an FC-4 of SCSI-FCP (since that is what we queried for); AND
2. share a common zone with the device that queried the Name Server.

For example, in the following diagram Host 1, Storage 1A and Storage 1B are all in the same Zone.  If any of these devices were to query the Name Server, they should only get 3 Port IDs back.  In the case of a switch that only supports “soft zoning”; zoning is enforced by allowing N_Ports to discover only those Port IDs that are associated with N_Ports that they have been granted access to (via zoning).  Port IDs associated with N_Ports that do not share a common zone with the querying N_Port will not be returned in Name Server responses.  

The downside of soft zoning is the switch does nothing to prevent a rogue host from transmitting frames directly to another N_Port’s Port ID.  To some this represents a serious security flaw and it’s hard to argue against this point.  However, in practice, this behavior is more of a problem when you had a malfunctioning adapter or an incorrectly programmed driver that would insist on communicating with another device even if access to that device was removed via a zoning change.
Step 11+ (End to End PLOGI) see diagram below

Once an N_Port discovers the other port IDs it can communicate with, it will perform an end to end PLOGI with them.  In practice only Hosts (Initiators) end up performing this PLOGI and they are usually smart enough to not PLOGI themselves.

When the initiator transmits the PLOGI, it will set the D_ID (Destination ID ) of the frame to be equal to one of the Port IDs returned from the Name Server and it will set the S_ID (Source ID) of the frame to be equal to its own Port ID (assigned in FLOGI ACC).

When the switch receives the end to end PLOGI, if it supports Hard zoning, it will check the D_ID of the frame and make sure that the specified S_ID is allowed to access (is zoned to have access) the specified D_ID.  If yes, the PLOGI is forwarded on to the destination if not, the PLOGI is dropped.  This is what is commonly referred to as Hard Zoning or Hardware enforced zoning.   Since the PLOGI is dropped, the login process never continues past this point.  I’ve heard but have not been able to confirm in the lab that some switch vendors implement hard zoning by trapping all PLOGIs from N_Ports at the fabric ingress port and forwarding them to the control plane of the switch.  The control plane then only forwards those PLOGI frames that should be allowed.