Brocade FOS 9.x and Cisco MDS NX-OS 9.x · 8 basic, 8 intermediate, 8 advanced and 8 scenario questions · examples are educational
Use each answer as a reasoning pattern: identify the object and scope, collect evidence, choose a controlled action and define the acceptance test. A strong answer says which command answers which question and when the command is insufficient. The named hosts, ports, counters and faults below are fictional; adapt actual syntax and capabilities to the platform/release.
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.
01Basic 1. What does an FC SAN switch do, and how is it different from NAS?
An FC switch forwards Fibre Channel frames and provides fabric services between initiators and targets. In the SCSI/FCP examples, the host accesses a block device presented by storage. NAS instead provides a file protocol such as NFS or SMB over its supported network path. An FC switch does not create a filesystem, map a LUN or determine a user’s file permissions. During an interview, separate the FC fabric, array presentation, host device/multipath layer and application so a missing file is not automatically called a switch fault.
02Basic 2. Explain WWPN, WWNN and FCID with an example.
A WWPN identifies a particular FC port, a WWNN identifies the node-level entity, and an FCID is an address assigned within the fabric. For example, app01 HBA A has its own port WWPN even if another HBA belongs to the same host. Zone the intended port WWPN; do not select a similar node WWN from a login listing. A cable move or fabric event can change an FCID while the port WWPN remains the intended identity. Verify actual endpoint ownership instead of inferring it from the address format.
03Basic 3. What are F, E and trunking E ports?
An F port provides a fabric attachment for an endpoint N port, such as an HBA or ordinary target. An E port joins fabric switches. On MDS, a trunking E link can carry supported VSAN contexts and appears as TE. Brocade trunking has its own hardware/feature requirements and is not the same configuration as MDS VSAN trunking. Before changing a port’s mode, identify the connected peer and workload; applying an endpoint F-port template to an ISL is a connectivity change, not a cosmetic label.
04Basic 4. Why are two switches not automatically two independent fabrics?
Two switches connected by an ISL normally participate in one intended fabric. Independent A/B fabrics keep separate FC paths so one fabric failure does not remove all access. Two VSANs or logical switches on a chassis separate logical contexts but still share that chassis and possibly power, adapters or modules. Prove independence with a physical/logical dependency diagram and actual host multipath evidence. A second green switch does not show that the host has a usable alternate path to its mapped device.
05Basic 5. What does FLOGI prove, and what remains to be tested?
FLOGI demonstrates that an endpoint obtained fabric login/addressing on a particular connection/context. Directory registration then helps identify known ports and capabilities. Neither proves the initiator is permitted to communicate with its target, has a target session, or is presented the expected LUN. Continue through effective zoning, target-side initiator login, mapping and host discovery. On MDS, distinguish a local FLOGI entry from a remote endpoint known through FCNS.
show flogi database interface fc1/1
show fcns database vsan 1006Basic 6. How do zoning and LUN masking differ?
Zoning controls FC port communication in the fabric. Masking/mapping controls which LUN a target presents to a particular host/initiator group. A host can reach a target yet see no LUN because its initiator is absent from the correct igroup or no mapping exists. Conversely, a correct mapping cannot repair a missing fabric path. Verify the exact initiator, target and persistent device identity at each layer; do not expand the default zone or map every LUN to bypass an unexplained stage.
07Basic 7. Why is single-initiator zoning used?
A conventional zone with one initiator and its approved target port or ports limits unnecessary initiator-to-initiator visibility and makes troubleshooting scope clearer. It does not itself restrict which LUN that target presents, so mapping still matters. The detailed examples use two single-initiator/single-target zones for two required target LIFs. An approved multi-target design can also be valid when its array guidance and host path limits are met. Do not interpret single initiator as single path or single controller.
08Basic 8. What is multipathing, and must every path be optimized?
Multipathing represents multiple storage paths to the same device and manages availability according to the supported host/array design. With ALUA, valid paths can have different optimized/nonoptimized states, so demanding that every path be optimized is incorrect. First verify the persistent device identity, expected usable path count and supported states for that OS and array. Then test actual application service and the planned failover behavior. A visible block device with one surviving path may be available but still degraded.
09Intermediate 1. On Brocade, how do cfgsave and cfgenable differ?
cfgsave preserves the defined zoning database. cfgenable validates and enables the selected complete configuration as effective policy. A saved zone can therefore remain ineffective until the correct configuration is enabled. Before changing an established fabric, inspect its defined/effective views and transaction ownership, add to the real complete configuration, then review/enable and test. A new configuration with only your host’s zone can omit everyone else’s existing access.
cfgshow
cfgactvshow
cfgtransshow --opentrans10Intermediate 2. On Cisco, explain full, active and pending zoning.
The full database contains configured zone-set objects. The active view is the policy actually enforcing access in that VSAN. Enhanced zoning also uses a pending transaction that must be reviewed and committed; requesting activation does not replace that commit. Compare all applicable views before declaring a new host authorized. Preserve the existing complete zone set and use the correct basic/enhanced branch. Persistence and peer full-database distribution are additional questions, not synonyms for activation.
show zone status vsan 10
show zoneset active vsan 10
show zoneset vsan 10
show zone pending-diff vsan 1011Intermediate 3. How do you abort Cisco enhanced zoning safely?
First identify the pending transaction, its owner and whether it is still uncommitted. Inspect the difference and coordinate with that owner. The documented abort form is no zone commit vsan 10 in configuration mode. It discards the owned pending transaction; it is not a reversal of an already committed policy. After a committed error, build a reviewed corrective transaction from the saved baseline and verify application service. Force-clearing someone else’s lock can destroy legitimate work and is not a standard first response.
12Intermediate 4. Compare Cisco device-alias and fcalias.
A device alias is a fabric-level pWWN naming service used by supported applications/consumers. An fcalias belongs to zoning in a specified VSAN and can represent zone members. Device-alias transactions, distribution and basic/enhanced consumer behavior need independent inspection. In particular, device-alias enhanced mode is not enhanced zoning. Renaming or repointing a shared alias can affect multiple consumers, so check every reference and actual WWPN before committing a seemingly local change.
show device-alias status
show device-alias database
show zone status vsan 1013Intermediate 5. Why can an ONTAP target link show several WWPNs?
NPIV allows multiple logical port identities to register through one supported physical connection. ONTAP FC LIFs have target WWPNs distinct from the physical port identity, and the zoning example must use the intended LIF WWPNs. Multiple identities are therefore not automatically duplicate devices or a cabling fault. Correlate the LIF list, current node/port and fabric directory. On Cisco, also follow NetApp’s restrictions for multiple LIFs sharing one physical port.
# ONTAP admin:
vserver fcp interface show -vserver svm_lab14Intermediate 6. A CRC count is 100. Is the link faulty now?
The single lifetime count does not establish a current fault. Capture the timestamp, traffic and counters, then measure again. If the count stays 100 through relevant traffic, it might be historical; if it reaches 145 in ten minutes, the delta is an active observation to investigate. Correlate receive direction, peer transmitter, optics/fiber, resets and diagnostic thresholds. Preserve the baseline before clearing anything and verify a correction under comparable load, rather than reporting success from counters reset to zero.
15Intermediate 7. How do you add a host without dropping existing zones?
Capture effective/active policy and the full candidate database first, including correct FID or VSAN and current transaction owner. Verify observed HBA and target identities, add the new zone membership to the existing complete configuration, and compare every required old zone before activation. Use the proper vendor/mode save and commit workflow. Afterward test the new host and existing consumers and export accepted configuration. Do not activate a newly created empty or partial configuration because its name matches the change ticket.
16Intermediate 8. What must a prechange backup contain?
It needs a protected off-switch configuration with correct switch/context identity, plus effective/full zoning, aliases, port membership and operational endpoint/path evidence. VF deployments also require the correct topology/chassis scopes; Brocade’s -vf and -all exports are complementary. On MDS, retain the approved running/startup and zone/alias states. A diagnostic support bundle is useful evidence but is not the same deliverable as a scoped configuration backup. Confirm actual remote files and recovery ownership rather than relying only on a transfer message.
17Advanced 1. Explain ISL, Brocade trunking and MDS FC port channels.
An ISL links switches inside an intended fabric. Brocade trunking groups eligible ISLs under its supported hardware, feature and configuration requirements. MDS FC port channels provide a logical bundle using FC channel behavior; they do not use an Ethernet LACP configuration template. Each design needs matching peers, qualifying member settings, measured aggregate demand and member-failure headroom. Several links do not guarantee one flow’s throughput scales linearly. Inspect actual membership and client behavior instead of equating cable count with useful redundancy.
18Advanced 2. Why can a VSAN be allowed on a trunk but not usable?
Allowed membership is only one condition. The VSAN must also exist, be active, negotiate correctly and avoid isolation at both ends. Inspect allowed/active/up/isolated state, peer configuration, domain and zoning/security compatibility. A command that replaces an allowed list can remove an existing production VSAN, whereas an approved add operation extends membership. After a correction, verify remote FCNS registrations and host paths. An online physical TE link alone is insufficient acceptance for every VSAN carried by that link.
show interface trunk vsan 10
show interface fc1/47
show trunk protocol19Advanced 3. How does Brocade Peer Zoning affect communication?
A peer zone assigns principal and nonprincipal member roles. The intended principal-to-peer pairs can communicate; peer-to-peer and principal-to-principal pairs are not authorized by that peer zone. However, another effective zone can still authorize the same devices, so the combined policy must be reviewed. Storage-centered examples often put a target in the principal role and hosts as peers, subject to feature and alias compatibility. Rehearse the actual application communication pattern instead of assuming the feature automatically makes a broad existing fabric isolated.
20Advanced 4. Is Cisco Smart Zoning the same as enhanced zoning?
No. Enhanced zoning concerns transaction/session and fabric database behavior. Smart Zoning uses device roles to reduce unnecessary communication permissions/resource use in supported designs. Device-alias enhanced mode is a third independent concept. Verify registered roles, special application communication requirements and platform/release support before converting an existing policy. Evaluate resulting permitted pairs and existing service, not just the presence of a feature label. Broad production conversion is a separate migration from adding one new host zone.
21Advanced 5. Compare NPIV, Brocade Access Gateway and Cisco NPV.
NPIV permits multiple virtual N_Port identities through a supported physical attachment. Access Gateway and NPV are vendor-specific edge architectures that forward endpoint logins toward an upstream fabric/core using supported mappings and NPIV. They have their own platform limits, uplink roles and failover behavior. Converting a full fabric switch into an edge mode can be disruptive and can alter or erase configuration; Cisco NPV enablement includes configuration erase and reboot behavior. Plan conversion as a migration with backup and console recovery, never as a login troubleshooting toggle.
22Advanced 6. What does setcontext change on Brocade?
setcontext selects an existing logical switch/FID for the current CLI session. It does not create a fabric, assign a new domain or move a physical port. Inspect lscfg --show and the prompt to confirm that a zone or port command targets the intended logical switch. Actual VF enablement and physical port movement are different, potentially disruptive operations. A context mistake can make correct syntax modify the wrong workload, so include FID and port ownership in every change record.
fosconfig --show
lscfg --show
# Select only an intended existing context:
setcontext 20
switchshow23Advanced 7. How would you justify a nondisruptive firmware upgrade?
Start with exact platform, modules/features and current build, then verify a supported target route and required intermediate releases. Check component activation and known caveats, not only the base software image. Prove alternate host paths, director HA where applicable, configuration backups and console recovery. Use the vendor preflight/workflow and keep real client monitoring. Some BIOS/EPLD or model-specific cases require disruption even when a software route supports ISSU. Accept one fabric’s restored service before maintaining the other; an installer success is only part of acceptance.
24Advanced 8. Why does credit starvation not identify the root cause?
It shows a flow-control waiting condition observed at a port. Downstream pressure can propagate upstream, so the counter’s location need not be the slow receiver. Correlate traffic direction, interval counters, discard/timeouts, endpoint queues and application timing. Separate oversubscription from a host/target that cannot drain traffic and from optical corruption. Additional bandwidth may help aggregate oversubscription but not an endpoint bottleneck. Changes to quarantine, fencing or congestion features require a reviewed supported policy and postchecks for both affected and shared traffic.
25Scenario 1. The port is online and both WWPNs are listed, but no LUN appears. What next?
First confirm both identities are in the intended same fabric/VSAN/FID and the exact pair is in effective zoning. A local login or FCNS listing is not a target session. Check target-side initiator login, correct igroup membership and LUN mapping/reporting. Then inspect supported host discovery and multipath state using persistent device identity. For an existing working session with only one missing new LUN, target presentation and host discovery become particularly important. Make one scoped correction and validate actual application I/O; do not initialize an unknown disk.
26Scenario 2. Existing hosts lose access after a zone activation. What do you do?
Stop further changes and verify surviving host access through the other fabric. Preserve the active/effective configuration, candidate database, changed membership and event timeline. Compare the activated complete set with the prechange baseline: an incomplete replacement may have omitted existing zones. Reapply only a reviewed complete corrective policy through the correct transaction/mode, checking for concurrent legitimate changes since the backup. Validate old and new consumers and persistent configuration. Fabric-wide default-zone changes, database clearing or blind full restores can create a second incident.
27Scenario 3. A server HBA is replaced. Which layers need review?
Record the old/new port WWPN and verify the replacement’s compatibility, driver/firmware and actual fabric login. Update only authorized zoning/alias references and target host-group membership as required; a readable host name may still resolve to the old WWPN. Account for both fabrics and shared alias consumers. Verify supported device/path identity and application I/O before retiring old access. Sequence the replacement through the approved resilience plan so the other usable path remains available. Do not authorize every discovered HBA to compensate for uncertain inventory.
28Scenario 4. The same HBA is moved to another switch port. Must the WWPN zone change?
With pure WWPN membership and the same actual endpoint identity, a physical port move does not inherently require changing that zone. But verify the new port belongs to the correct fabric/VSAN/FID, supports the required role/speed/NPIV and is permitted by any relevant security policy. Domain/index or physical-port membership would have different implications. Confirm the actual login, effective permissions and host paths after the move. A cable moved from Fabric A into B is a topology error, not a reason to merge the two fabrics.
29Scenario 5. Application I/O works after an upgrade, but only two of four expected paths remain.
Availability and restored resilience are separate acceptance tests. Confirm the expected count for the supported topology and mapped device; do not accept a reduction merely because a transaction succeeds. Identify the missing initiator-target pairs and trace physical links, membership, remote directory, effective zones, target sessions and host path state. Check post-upgrade module/ISL/channel/component status. Keep the maintenance open and hold work on the other fabric until the missing required paths are restored or an explicit exception is accepted by the responsible owners.
30Scenario 6. Several hosts slow down together, while most ports show few CRC errors.
Correlate the application timestamps and shared traffic routes before replacing optics. Inspect ISL utilization, credit waiting, discards/timeouts and receiver behavior over matching intervals. A slow-draining endpoint or oversubscribed shared link can affect multiple otherwise healthy hosts. Compare unaffected paths and target/HBA/OS queue or latency events. Collect Brocade MAPS/FPI or MDS supported congestion/OBFL evidence without erasing counters. Correct the identified bottleneck and compare performance under similar load; an idle after-hours sample is not proof of unchanged peak behavior.
31Scenario 7. Fabric A has a fault, but tonight’s approved plan also upgrades B. Do you proceed?
Reassess the actual service risk and pause dependent maintenance. The original plan assumed usable alternate access; a fault on A may invalidate that assumption. Establish which hosts/LUNs still have supported usable paths and whether redundancy/capacity is restored. Resolve A or obtain an explicitly revised service-impact/recovery plan from the responsible owners before working on B. Record the changed conditions and evidence. A calendar approval does not transform an unavailable alternate path into a safe one.
32Scenario 8. How would you automate SAN switch health checks without hiding failures?
Use a vendor/model/context-aware inventory and read-only collection commands. Separate reachability/authentication/collection failures from a healthy result: no output is unknown or failed, not zero errors. Timestamp records, retain switch/FID/VSAN/port/WWPN identity and compare interval counters rather than only lifetime values. Protect credentials, verify SSH host identities and restrict collection privileges. Escalate specific missing expected objects and new faults. Keep configuration changes, counter clears and port toggles out of the collector; validate parsing against the actual firmware/output format before scheduling it.
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.
- NetApp: FC zoning and target LIF identities
- NetApp: dual fabrics, host paths and Cisco restrictions
- Broadcom: FOS 9.2 administration
- Broadcom: FOS 9.2 command reference
- Broadcom: Access Gateway
- Broadcom: MAPS monitoring
- Cisco: zoning and Smart Zoning
- Cisco: device-alias behavior
- Cisco: FC port channels
- Cisco: NPV/NPIV
- Cisco: firmware upgrade restrictions