Recently I have found myself with a small issue.
Using Brocade Web Tool – Zone Administration is quite easy to figure out which zones are in active configuration, and which are not. But how to quickly find it using only CLI via FabricOS?
Well there are couple of ways to do so. If you have specific zone you wish to check you can go with the command zone –validate {zone_name}, example output:

switch> zone --validate Z_linux002_storage001_FA8fB
Defined configuration:
 zone:  Z_linux002_storage001_FA8fB
                A_storage001_FA8fb; a_linux002_hba_a

Effective configuration:
 zone:  Z_linux002_storage001_FA8fB
                50:00:09:72:08:28:55:3d
                21:00:00:1b:32:8c:71:c6

As you can see this zone is listed in both Defined and Effective configuration.
OK, that was easy – but what if you wish to go through all your zones and validate which ones are active and which ones are not. Of course you can go with commands like zoneshow, or cfgshow
But what if you have quite big fabric, with more than 100+ aliases/zones etc? Interpreting the output might be quite time-consuming.
The quick trick I’m using is:

$ ssh -l admin switch cfgshow | grep "zone" | sort | uniq -c
admin@switch's password:
      1  zone:  zone_storage3257_FA7bA_RTPUS
      2  zone:  zone_storage3791_10aA_fdsa
      2  zone:  zone_storage3791_10agfda
      2  zone:  zone_storage3791_efs
      2  zone:  zone_storage3791_vfda
      2  zone:  zone_storage3791_grw
      2  zone:  zone_storage3791_fdsbaa
      2  zone:  zone_storage3791_vfaf

 
The whole “trick” is based on the way in which cfgshow output is built. It first lists all configurations, later on it lists all zones and aliases. At the end it list Effective/Active Configuration with all activated zones, as a consequence if the same zone: <zone_name> is listed twice, it means it is both in defined and active configuration. If it listed once, it means that either it is not activated, or possibly, activated, but in the meantime deleted from the configuration without executing cfgenable. In above example you can noticed that zone zone_storage3257_FA7bA_RTPUS is only mentioned once, now that is a good candidate for zone –validate command.

Fibre Channel is a request-response protocol – it’s not a broadcast protocol. Because of that we need some kind of Services that allow device in network to request for certain amount of information, and the service responds back with that information. There are couple of Generic Services used to manage a Fabric Channel network. All of them have unique Well-Known Address (FFFFFx). Let me go through some common Well-Known Addresses (and of course the Fabric Services they represents)

• FFFFFE – Fabric Login Server – Used when a node is connected to a fabric. Before a node can communicate with other nodes in the fabric, it has to have assigned 24-bit Fabric Address (check out my entry about Fibre Channel addressing). In few words – this Service is used to exchange service parameters with the new host and request 24-bit address. I will explain that a little bit more later in this entry.
• FFFFFD – Fabric Controller – This services provides a state change notifications to registered notes. Host is sending state change registration frame to Fabric Controller, to receive RSCN (Registered State Change Notifications). Those are used to notify device that view of the device has changed (for example some device left a fabric, or a new one joined).
• FFFFFC – Directory Server (Name Server) – Once a device receives RSCN (registered state change notification) usually device query the Name server (FFFFC) to find out what has changed in the Fabric view. Also – when a new devices joins the Fabric it has to register itself using FC_CT (Fibre Channel Common Transport) protocol.
• and many more, there are at least 7 other Fabric Services, such as Management Server, Clock Synchronization Server, Security Server, Alias Server, Time Server, or Broadcast Server (used for example for IP over Fibre Channel)

Fabric Login

1. FLOGI. When a device is connected to the Fabric, it does not know its 24-bit address yet – so until the Fabric Login is executed, the temporary Address is 000000. And that is the address put in the “Source _ID” field in the FC frame header. A device initialize a Fabric Login (FLOGI) with FFFFFE (Fabric Login Server) to exchange service parameters with the fabic. It starts with sending FLOGI, and as a response it gets FLOGI ACC – in witch the Fabric Login Server provides the 24-bit FC address to the FC node. FLOGI ACC gives more details to the host, such as Buffer-tobuffer credits for the device and switch ports.
2. PLOGI. Once the device got a 24-bit address it contacts FFFFFC Name Server sending PLOGI (Port Login) and receives PLOGI ACC. Port login is used to establish a session between two devices and it is necessary before any upper level communication can take place. In this phase the switch will write the information of the device to Name Server – like WW(p)N, WW(n)N, what Class of Service does it support, what Protocol is used in FC-4 layer (usually SCSI or IP) and so on
3. Once the host has logged in to the Fabric it communicate that to FFFFFD Fabric Controller sending SCR (Satate Change Registration) in order to receive future RSCNs (registered state change notifications). SCR usually have one of four values:
   1. SCR = 0 – Register to receive none RSCNs.
   2. SCR = 1 – Register to receive all RSCN requests issued by the fabric controller for event/issues detects in the fabric
   3. SCR = 2 – Register to receive all RSCN requests issued for events that affects me (N_Port)
   4. SCR = 3 – Register to receive all issued RSCNs. For example with SCR=3 device will receive an RSCN when new port is detected in Fabric, where-as for SCR=1, or SCR=2 this RSCN would not be received.

In SAN environment, every port has to go through initialization process. During that process every port is categorized under specific type. Depends if the port is a device port – it can become N_Port or NL_Port. If it’s a switch port – it usually becomes either U_Port, F_Port or E_Port. Let me go through port types with short explanation.

Port Types

Device Ports

• N_Port – Node Port – a Fabric device directly attached. Such device can be either an initiator or a target. In storage world targets are storage arrays, and initiators are hosts/servers.
• NL_Port – Node Loop Port – a device attached to a loop. The device has an arbitrated loop code, and switched fabric code in its code base. As a consequence, once the device finishes the arbitrated loop initialization it starts sending out FLOGI (fabric logins). This process I will explain more carefully in futures post. But in few words – it need to do that to get 24bit fabric address and be able to exist in Switched Fabric environment.

Switch Ports

• U_Port – Universal Port. U_Port means that the Port does not have a topology assigned yet, it is basically waiting to become another port type. Normally when nothing is attached to a port it is a U_Port.
• FL_Port – Fabric Loop Port. A switch port becomes FL_Port only when it is directly connected to NL_Port on the device side.
• G_Port – Generic Port. It is a state through-out Port Initialization before a port can become either a F_Port or E_Port. If a port stayed as a G_Port there is probably some issue during Port Initialization
• F_Port – Fabric Port. It means that the port is connected to a  Full Fabric device – so to a N_Port. In other words F_Port means that this port is directly connected to either a initiator or target.
• E_Port – Expansion Port. This kind of port is used for inter-switch links (ISL). It is the connection between two switches.

Port Initialization Process

Port Initialization Process

(Click on the diagram to see it in better resolution.)

1. Port Initialization Process becomes from the U_Port (called a State1).
2. If the port can detect that something is connected (something is sending a signal to the port), it goes through the first transaction.
3. During the Transaction1 port is transmitting at least 12 Primitive Sequences LIP(F7) – as a try for  arbitrated loop initialization sequence.
4. If the port receives at least 3 consecutive pritimite sequences,  the port is going through the arbitrated loop initialization, becoming a FL_Port (State2)
5. If the attached device is not a loop, the initialization continues into the G_Port stage (state3).
6. If the attached device is a initiator or a target – the port state is changing from G_Port to F_Port (state5). And it is waiting for the Fabric Login to be received.
7. If the attached device is another switch, then the port changes its state from G_Port to E_Port (state4)

Of course this is just a high overview of the initialization process.