Fabric OS 9.2 reference syntax · native FC fabric in the correct FID · WWPN-based conventional and peer zones; check every fabric participant’s support
The example authorizes app01 HBA A to two ONTAP FC LIFs in Fabric A. CFG_FAB_A stands for the existing complete effective configuration. The example identities come from the shared SAN worksheet. All required existing zones must remain in the candidate configuration. Fabric B has a separate configuration and its own HBA/target identities.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Capture defined, effective and transaction state
- Confirm switch/FID, effective configuration name, complete defined database, actual default-zone policy and other open transactions.
- Retain an off-switch configuration backup plus defined/effective output. If FCS security policy applies, use its authorized primary FCS switch for zoning.
- Coordinate one change owner and verify exact endpoint WWPNs from host/target and fabric evidence. Do not commit or abort someone else’s transaction.
switchshow
fabricshow
cfgshow
cfgactvshow
cfgtransshow --opentrans
defzone --show
nsshowThe existing complete access policy, owner and correct fabric context are established.
02Explain alias, zone and configuration before editing
For the conventional examples, one initiator per zone limits unintended host-to-host reachability. The two-target requirement is shown as two single-initiator/single-target zones for clarity. An approved multi-target zone is also a design choice subject to array and host limits. WWPN membership follows endpoint identity when it is moved to another supported switch port; it does not prove the physical link exists.
| Object | Purpose | Example |
|---|---|---|
| Alias | A readable reference to approved port identity/membership | app01_hbaA |
| Conventional zone | A permitted communication group | Z_app01_n1_A |
| Defined configuration | Candidate grouping of zones retained in the database | CFG_FAB_A with old and new zones |
| Effective configuration | The currently enabled policy enforced by the fabric | Inspect with cfgactvshow |
The candidate policy can be described as exact permitted endpoint pairs.
03Create aliases from observed port WWPNs
- Search the current database for an existing alias before creating a new one. Stop if a familiar name identifies a different device.
- Use the actual host HBA port WWPN and ONTAP FC LIF WWPNs. A physical storage adapter identity is not a substitute for its logical target LIF.
- Inspect alias membership and compare it with the approved worksheet. Alias edits can affect every zone referencing that alias.
alicreate "app01_hbaA", "10:00:00:90:fa:aa:00:01"
alicreate "ontap_n1_fcA", "20:01:00:a0:98:aa:00:01"
alicreate "ontap_n2_fcA", "20:02:00:a0:98:aa:00:01"
alishowEach alias resolves only to its intended approved port identity.
04Create the zones and extend the existing configuration
Use cfgadd for the actual existing configuration. If you create a new configuration containing only these zones and enable it, the omitted production zones will not be part of the new effective policy. Reusing an attractive example name is unsafe unless its complete membership has been verified.
- Confirm both new zones have the intended membership and have been added to the correct configuration.
- Compare every existing required zone against the prechange record. Resolve unexpected deletions, changed aliases or another open transaction.
- Proceed to saving/activation only when the complete candidate policy and the change owner are clear.
zonecreate "Z_app01_n1_A", "app01_hbaA;ontap_n1_fcA"
zonecreate "Z_app01_n2_A", "app01_hbaA;ontap_n2_fcA"
cfgadd "CFG_FAB_A", "Z_app01_n1_A;Z_app01_n2_A"
cfgshowThe candidate includes all required existing zones and only the approved new access.
05Save and enable, then inspect the effective result
cfgsave preserves the defined database; it does not by itself apply pending changes to the effective policy. cfgenable validates and enables the selected complete configuration. Review confirmation prompts rather than scripting blind affirmative responses. Do not leave a saved-only change and assume the new host is authorized.
- Save the reviewed candidate and enable the correct complete configuration in the approved window.
- Inspect effective output for the new pair and required pre-existing zones. Reconcile defined/effective state and transaction ownership.
- Test both the new host and representative existing service. Retain a post-change configuration export and actual acceptance evidence.
cfgsave
cfgenable "CFG_FAB_A"
cfgactvshow
cfgshow
cfgtransshow --opentransThe intended complete policy is effective and storage/application access confirms the result.
06New isolated fabric branch: create the first configuration
This branch replaces cfgadd only when commissioning the initial isolated fabric. Confirm all intended zones are included, default-zone behavior is understood and there is no live configuration to preserve. Do not connect the switch to production to see whether it merges; complete the separate fabric-merge review first.
# Only if this is truly a new isolated fabric with no production configuration:
cfgcreate "CFG_FAB_A", "Z_app01_n1_A;Z_app01_n2_A"
cfgshow
cfgsave
cfgenable "CFG_FAB_A"
cfgactvshowThe initial effective policy intentionally contains every required lab endpoint pair.
07Verify target sessions, LUN mapping and host paths
- Verify the correct zone pair is effective in the correct fabric/FID and both endpoint identities remain registered.
- Confirm the target sees the intended initiator and presents the correct LUN through its igroup/mapping.
- Use the supported host discovery procedure and verify persistent device identity, expected usable paths and an application-native transaction. Test existing consumers before closure.
cfgactvshow
nodefind 10:00:00:90:fa:aa:00:01
porterrshow
# ONTAP admin:
vserver fcp initiator show -vserver svm_lab
lun igroup show -vserver svm_lab
lun mapping show -vserver svm_lab
# Linux host:
multipath -llThe intended host works through authorized paths and unaffected services retain their previous access.
08Advanced branch: design Peer Zoning roles explicitly
Peer Zoning distinguishes principal members and nonprincipal peer members. In the illustrative storage-centered design, the target LIF is principal and selected host initiators are peers. The permission matrix matters: principal-to-peer communication is allowed by this zone; peer-to-peer and principal-to-principal communication are not allowed by this zone. Another effective zone can still provide additional permission.
| Pair within this peer zone | Allowed by this zone? |
|---|---|
| Principal target ↔ nonprincipal host | Yes |
| Nonprincipal host ↔ nonprincipal host | No |
| Principal ↔ principal | No |
| Pair also covered by another effective zone | Evaluate the combined effective policy |
- Confirm every participating switch and director CP supports the selected feature and alias form. The FOS administration guide gives additional version/interoperability requirements.
- Use WWPN-based aliases consistently. Do not mix WWPN and domain/index membership through nested-looking alias choices, and do not assign an alias to both roles.
- Verify that the intended application needs only the selected communication pairs. Storage replication or specialized clustered endpoints can require a different design.
Roles, permitted pairs, isolation expectations and all participant requirements are reviewed before creation.
09Create an illustrative peer zone and review combined permissions
This example requires app02_hbaA to have been independently defined from its actual HBA WWPN. Use a separate approved branch/lab when comparing it with conventional zones. Leaving broad conventional zones effective can defeat the peer-isolation property you intended to test. Conversely, deleting old zones without a complete migration plan can remove necessary access.
- Verify target-to-host operation for each intended peer and confirm the combined active policy does not authorize unintended host-to-host access.
- Evaluate all overlapping effective zones, not only the new peer-zone object.
- Validate application and path behavior, then retain the actual before/after policy and migration decision.
# app02_hbaA must be a separately verified existing WWPN alias:
zonecreate --peerzone "PZ_ontap_n1_A" -principal "ontap_n1_fcA" -members "app01_hbaA;app02_hbaA"
cfgadd "CFG_FAB_A", "PZ_ontap_n1_A"
cfgshow
# After the complete policy and approved pending work are reviewed:
cfgsave
cfgenable "CFG_FAB_A"
cfgactvshowThe combined effective policy gives exactly the required communication, with accepted target and application service.
10Reverse a committed zone addition narrowly
First compare current policy with the saved prechange state and check whether another service now depends on the zone/alias. Removing membership and re-enabling the reviewed complete configuration is different from deleting all zone objects. Keep shared aliases until their references and intended cleanup are understood. Precommit transaction recovery is also different from reversal after activation.
# Conditional reversal: these new zones must no longer be required:
cfgremove "CFG_FAB_A", "Z_app01_n1_A;Z_app01_n2_A"
cfgshow
# Review complete policy and owned transaction before application:
cfgsave
cfgenable "CFG_FAB_A"
cfgactvshowOnly the approved access is removed, and every remaining consumer still passes its service check.
11Recognize destructive shortcuts and failed acceptance
If a new zone fails acceptance, stop adding unrelated changes. Identify whether the fault is registration, effective membership, target login, mapping or host discovery. Use the specific failing stage to choose the correction. Preserve the effective policy and client evidence for escalation rather than clearing the fabric to make the database smaller.
| Shortcut or symptom | Correct interpretation |
|---|---|
| cfgdisable | Returns behavior to default-zone policy; can remove or broaden fabric access |
| cfgclear | Deletes defined zoning objects through the transaction; not a normal troubleshooting reset |
| cfgsave only | Defined persistence does not prove effective activation |
| Enable a small new cfg | Can omit existing production zones |
| Force-abort another transaction | Can discard another owner’s work |
| Active zone looks right, LUN absent | Continue through target mapping and host discovery |
The operator can explain the exact active policy and recover from a scoped mistake without an unplanned fabric-wide reset.
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.