Brocade FC Zoning with CLI: Aliases, Zones and Configs

Zoning is the access-control mechanism of a Fibre Channel SAN: it decides which initiators (servers/HBAs) can talk to which targets (storage ports) inside the fabric. Brocade Fabric OS implements zoning through three levels — aliases, zones, and configurations — and while the Web Tools GUI is convenient, the CLI is what you use in scripts, audits and emergency changes. This guide covers the complete alias-zone-config workflow with the commands from the Fabric OS reference, plus the verification and troubleshooting steps that turn a zoning change into a safe, repeatable procedure.

Why Three Levels?

• Alias: a friendly name for one or more WWNs or ports, e.g. array1 for a storage port. Aliases make zones readable and reduce typing.
• Zone: a set of members that may communicate. Best practice is single-initiator zoning: one host alias plus the storage aliases it needs.
• Configuration: a named set of zones. Only one configuration is enabled (effective) at a time; cfgEnable makes it active.

The three levels exist because a fabric has three different questions to answer at three different times. Aliases answer “which physical objects am I talking about?” and are the only layer that should change when a cable is moved or a storage port is replaced. Zones answer “who is allowed to talk to whom?” and are the security boundary. Configurations answer “which version of that policy is live right now?” and are the unit you schedule, test and roll back. Collapsing the layers — hard-coded WWNs inside zones, for example — works until the first HBA replacement, and then nobody can tell which of two hundred hex strings is stale.

Before You Start: Prerequisites and Sanity Checks

Zoning is not a local setting. It lives in the fabric and is enforced by every switch that participates in it, so the first step of any zoning change is to capture the current state. Do this before you type a single aliCreate, and paste the output into your change record.

switch:admin> version
switch:admin> fabricshow
switch:admin> switchshow
switch:admin> cfgshow
switch:admin> cfgactvshow

version tells you the Fabric OS release (command names and options differ slightly across 7.x, 8.x and 9.x, and peer zoning only exists from 8.1 onward). fabricshow proves that every switch sees the same fabric and the same principal switch; if the switches disagree, fix the ISLs before touching zoning, because a zoning change on one side of a broken fabric does nothing. switchshow lists port states and the WWN or NPort ID of each logged-in device, which is where you should copy your alias members from rather than from an old spreadsheet. cfgactvshow prints the effective configuration — the one currently being enforced.

Export a backup of the zoning database before every change. cfgUpload writes only the zoning database, while configUpload with -vf uploads the fabric-wide (virtual fabric) configuration including zoning; both are dramatically faster to restore than rebuilding zones from memory.

switch:admin> cfgUpload "admin", "10.0.0.20", "/home/admin/zoning_backup.cfg"
switch:admin> configupload -vf -p scp

Create Aliases

Members can be given by domain,port (D,I) pairs or by WWN:

switch:admin> aliCreate "array1", "2,32; 2,33; 2,34"
switch:admin> aliCreate "host1", "21:00:00:20:37:0c:66:23"

Zoning is enforced per device port, and WWN-based members survive cable moves; alias names are case-sensitive. One alias may contain any mix of WWN and D,I members, and a single member may appear in several aliases, so you can model both “one storage array” and “one controller port” at the same time.

Managing Aliases: Add, Remove and Delete

Aliases are edited incrementally. Adding a port to an existing alias does not require you to retype the whole list, and the change takes effect the next time the configuration that uses it is enabled.

switch:admin> aliShow
switch:admin> aliShow "array1"
switch:admin> aliAdd "array1", "2,35"
switch:admin> aliRemove "array1", "2,33"
switch:admin> aliDelete "array1"

aliShow without arguments lists every alias with its members; with an alias name it prints just that one. aliAdd and aliRemove modify an alias in place. aliDelete deletes an alias outright and will fail if the alias is still a member of any zone — remove it from every zone first, or Fabric OS refuses the deletion. That refusal is a feature, not an obstacle: it prevents you from leaving a zone with a dangling member that silently stops working.

Practical naming rules that pay off years later: prefix by function (host_, stor_, tape_), include the site or fabric, and always include the array and port number (stor_v3700_a1). Never name an alias after a server slot that will change, and never reuse an alias name for a different WWN after a rebuild — create a new alias and swap the zone membership so that the history stays readable in cfgShow output.

Create Zones

switch:admin> zoneCreate "zone_host1_array1", "host1;array1"
switch:admin> zoneCreate "zone_host2_array1", "host2;array1"

Each zone pairs one initiator with its storage — if a host needs two arrays, list both aliases in the same zone or create two zones. The number of members per zone, zones per configuration and configurations per switch is bounded by the Fabric OS limits documented per platform; on modern switches those limits are large, but a zoning database with thousands of single-initiator zones does slow down cfgEnable and fabric merges, which is exactly why peer zoning exists.

Editing and Deleting Zones

switch:admin> zoneAdd "zone_host2_array1", "array2"
switch:admin> zoneRemove "zone_host2_array1", "array1"
switch:admin> zoneDelete "zone_host2_array1"
switch:admin> zoneShow
switch:admin> zoneShow "zone_host2_array1"

zoneAdd and zoneRemove change membership; zoneDelete removes the zone entirely. A zone being deleted must not be part of the enabled configuration — remove it from the configuration with cfgRemove first. Note that editing a zone that is already part of the enabled configuration does not change traffic until you re-run cfgEnable: the defined configuration and the effective configuration are separate objects until you activate them.

On fabrics with hundreds of hosts, consider peer zoning (Fabric OS 8.1 and later). A peer zone keeps the single-initiator model but is expressed as one target plus its peers, which reduces the number of zones, shortens cfgEnable time and cuts the size of the zoning database that must merge across ISLs:

switch:admin> zoneCreate --peerzone "peer_stor_a1", "stor_a1", "host1; host2; host3"

Build and Enable the Configuration

switch:admin> cfgCreate "prod_fabric", "zone_host1_array1;zone_host2_array1"
switch:admin> cfgEnable "prod_fabric"
switch:admin> cfgSave

cfgEnable replaces the effective zoning and can briefly disrupt traffic in the affected zones, so run it in a maintenance window. cfgSave commits the defined configuration to flash so it survives a reboot; without it the changes are lost when the switch reloads. Fabric-wide, zoning changes propagate automatically to all switches in the fabric.

Configurations are edited with the same add/remove/delete pattern as zones. cfgDisable removes all zoning enforcement — every port can suddenly reach every other port — so it is a diagnostic tool, not a step in a normal change. If an activation seems to hang or a transaction is left half-finished, cfgTransShow displays any open zone transaction and cfgTransAbort discards it.

switch:admin> cfgShow
switch:admin> cfgAdd "prod_fabric", "zone_host3_array1"
switch:admin> cfgRemove "prod_fabric", "zone_host2_array1"
switch:admin> cfgEnable "prod_fabric"
switch:admin> cfgSave
switch:admin> cfgTransShow
switch:admin> cfgDisable

Verification and Management Commands

switch:admin> cfgShow
switch:admin> cfgActvShow
switch:admin> zoneShow "zone_host1_array1"
switch:admin> aliShow
switch:admin> nsZoneMember "host1"
switch:admin> nsAllShow
switch:admin> nsShow -t

cfgactvshow displays the effective configuration currently enforced, which is what you compare against cfgshow when troubleshooting an unexpected denial of access. If a new host cannot see the storage, check that its WWN is in the zone, the zone is in the enabled configuration, and the HBA logged in (switchshow). For the broader SAN context see our FC vs iSCSI comparison and the Brocade SAN switch CLI commands cheatsheet.

Troubleshooting: A Host That Cannot See the Array

Work outward from the physical layer, because the most common zoning “problem” is not a zoning problem at all. Use this order:

switch:admin> switchShow
switch:admin> nsShow -t
switch:admin> cfgActvShow
switch:admin> zoneShow "zone_host1_array1"
switch:admin> fabricShow
switch:admin> errDump
switch:admin> portErrShow

1. Is the port online? switchShow must show Online for the host port and Online (or Online (Trunking)) for the storage port. A port in No_Light, No_Sync or Login state cannot be zoned into existence — fix optics, cabling or the HBA first.
2. Is the device in the name server? nsShow -t lists each logged-in WWN and the port it logged in on. If the initiator is missing, the problem is the HBA, not zoning.
3. Is the member in the effective configuration? Compare cfgShow (defined database) with cfgActvShow (what is enforced). A zone that exists and is populated but was never added to the enabled configuration looks perfect in cfgShow and blocks traffic.
4. Did a fabric merge change the outcome? When two switches with different defined configurations join over an ISL, Fabric OS merges them or reports a conflict. errDump shows zone merge errors, and fabricShow confirms all switches share one fabric; a partly merged fabric can leave one host zoned correctly on its local switch and blocked upstream.
5. Is the storage port presenting a LUN to an allowed initiator? Zoning only permits the conversation; the array's own host mapping must still include the host WWN. If zoning is clean and the name server is clean, log into the array and check the host/LUN mapping.

Two further traps are worth remembering. First, WWNs are case-insensitive for matching but the Fabric OS CLI prints them in lower case — copying a WWN from a vendor GUI in upper case is harmless, but copying a truncated one is not. Second, aliases that mix D,I members with WWN members break whenever the domain ID changes, which happens after a switch replacement or a fabric reconfiguration; WWN members are the safe default for anything in production.

Best Practices for Production Fabrics

• Single-initiator zones only; never put two servers in one zone unless you are deliberately building a cluster-readable LUN design.
• Aliases carry the meaning; zones and configurations only reference aliases. No raw WWNs inside zones.
• Always run cfgSave after cfgEnable, and export the zoning database with cfgUpload before and after the change.
• Keep one configuration per purpose (prod_fabric, backup_fabric, migration_fabric) instead of editing the single enabled configuration in place; switching configurations with cfgEnable is far easier to reverse.
• Activate during a maintenance window, and pre-agree the rollback command (cfgEnable <old_config>) with the storage and application teams.
• On large fabrics use peer zoning and case-sensitive, function-prefixed alias names so that cfgShow output stays readable at 3 a.m.

原文链接：https://techdocs.broadcom.com/us/en/fibre-channel-networking/fabric-os/fabric-os-commands/9-2-x/Fabric-OS-Commands/aliCreate.html