Defzone configuration

Today I came across a case where the administrator had a bit of an incorrect interpretation of the term “defzone“. Brocade uses defzone in case when no normal zoning configuration is active. A defzone (default zone) is a hidden “dummy” zoning configuration with no members(*). No WWN’s, aliases or port-ID’s ever will be added to a “defzone”.

The defzone has two states: “NoAccess” or “AllAccess“. As soon as the normal zone is disabled with “cfgdisable XYZ” the policy of defzone will kick in. . You can’t see this in a Defined- or Effective configuration. If the configuration is set to “NoAccess” the empty(*), and hidden, dummy zone configuration will become active and no device will be able to see or “talk” to another device. All frames that are sent are simply discarded at the ingress port on the switch with a zone-conflict reason.

If the defzone configuration is set to “AllAccess” and the normal zoning configuration is disabled then this dummy config will not be enabled, or rather the “d_efault_CFG” will be deleted, hence all devices will be able to see and talk to every other device in the fabric. (This is something you definitely NOT want)

In a Open-Systems environment you REALLY need to set “NoAccess” just in case somebody makes an error or a bug might disable zoning in any form or shape. In Ficon thing are a bit more regulated since the IOCP configuration will already determine who’s talking to who and zOS will take care of that.

To determine if you have NoAccess or AllAccess enabled use the “defzone –show“command.

Sydney_ILAB_DCX-4S_LS42:FID42:admin> defzone –show
Default Zone Access Mode
committed – No Access
transaction – No Transaction

if you change this with “defzone –AllAccess” you will see the below:

Sydney_ILAB_DCX-4S_LS42:FID42:admin> defzone –allaccess
You are about to set the Default Zone access mode to All Access
Do you want to set the Default Zone access mode to All Access ? (yes, y, no, n): [no] y

Sydney_ILAB_DCX-4S_LS42:FID42:admin> defzone –show
Default Zone Access Mode
committed – No Access
transaction – All Access

You see that no real change has been committed yet but the transaction is set. This then needs to be distributed through the entire fabric. Since “defzone” is no regular zone you don’t need to assign names or use the “cfgenable” command, it uses the above mentioned, reserved name. You do need to use the “cfgsave” command to distribute it to all switches in the fabric.

Sydney_ILAB_DCX-4S_LS42:FID42:admin> cfgsave
You are about to save the Defined zoning configuration. This
action will only save the changes on Defined configuration.
Do you want to save the Defined zoning configuration only?  (yes, y, no, n): [no] y
Updating flash …

After the distribution completes the “defzone –show” command shows the new configuration has been commited and the transaction lock has been cleared.

Sydney_ILAB_DCX-4S_LS42:FID42:admin> defzone –show
Default Zone Access Mode
committed – All Access
transaction – No Transaction

If you forget to save the new setting with “cfgsave” the switch will still hold a transaction lock and if you then make a normal zone-change on another switch this will fail on the “cfgsave” command since the other switch will receive a reject on the ACA (Acquire Change Authorization) request. You then need to clear either one of the locks with the “cfgtransabort” command on the respective switch and then commit the zone change with the “cfgsave” command again.

The way to determine if zoning is active or not is easily done with the “switchshow” command.

Sydney_ILAB_DCX-4S_LS128:FID128:admin> switchshow
switchName:    Sydney_ILAB_DCX-4S_LS128 <<<<<
switchType:    77.3
switchState:    Online
switchMode:    Native
switchRole:    Principal
switchDomain:    143
switchId:    fffc8f
switchWwn:    10:00:00:05:1e:52:af:00
zoning:        ON (Brocade)    <<<<<<<<<

ydney_ILAB_DCX-4S_LS42:FID42:admin> switchshow
switchName:    Sydney_ILAB_DCX-4S_LS42 <<<<<
switchType:    77.3
switchState:    Online
switchMode:    Native
switchRole:    Principal
switchDomain:    106
switchId:    fffc6a
switchWwn:    10:00:00:05:1e:52:af:03
zoning:        OFF             <<<<<<<

or with “cfgshow

Effective configuration:
cfg:    Brocade
<snip>

 

As you can see above the zoning configuration is independent of virtual fabric/switch settings. Each virtual fabric has its own zoning database and therefore also a separate “defzone” configuration.
Make sure these are ALL set to “NoAccess”.

(*) The NoAccess configuration is actually a reserved config name called “d_efault_Cfg” with a “d_efault_Zone” who has a single dummy WWN member (00:00:00:00:00:00:00:01).

Hope this explains the “defzone” terminology a bit.

Regards,

Erwin van Londen

Print Friendly, PDF & Email

Subscribe to our newsletter to receive updates on products, services and general information around Linux, Storage and Cybersecurity.

The Cybersecurity option is an OPT-OUT selection due to the importance of the category. Modify your choice if needed.

Select list(s):

4 responses on “Defzone configuration

  1. jaymike

    Good tip to share. I’ve seen this burn customers before too who were trying to merge fabrics. Merges failing due to zoning “conflict” even though one side was already cleared with cfgclear. If that defzone is set to NoAccess, that hidden dummy cfg can prevent the fabrics from merging.

    1. Erwin van Londen Post author

      Indeed. Next to normal zone-differences this is one of the issues some customers run into. Easy to overlook. Logs don’t always show this. They just mention zoning conflict.

  2. kasperottesen

    Can this be changed non-disruptively if you have zoning on and have an active zone configuration?

    1. Erwin van Londen Post author

      Hi Kasper,

      Yes, basically you can view it as a separate zone config without any members and is only activated depending on AllAccess or NoAccess.