FC SAN switch foundations: hardware, fabrics, logins and storage access

01Understand what the switch transports and identifies

An FC SAN carries storage traffic between an initiator and a target. In these examples the host HBA is the initiator and an ONTAP FC LIF is the target. An FC switch provides fabric services and forwards FC frames; it does not create a LUN or grant that LUN to a host. Management Ethernet is a separate access plane, so a working SSH connection says little about FC data access.

02Build two independent fabrics before discussing redundancy

Fabric A and Fabric B should have independent failure paths appropriate to the design, including switch connectivity, power and host/storage attachments. An ISL connects switches within one fabric. Connecting the A and B fabrics to each other changes that isolation and is not a shortcut for adding host redundancy. Two VSANs or two logical switches on one chassis can provide logical separation while still sharing that chassis failure.

1. Draw both host initiators, every switch hop, target LIF and physical controller port. Mark which components share power, adapters, blades or chassis.
2. Record supported host multipath settings and the path count expected for a mapped LUN. For this simple two-initiator/two-targets-per-fabric illustration, four paths may be expected; SLM, portsets, platform architecture and host limits can change that number.
3. Before maintenance on A, prove current usable access through B from the host and application. Restore and accept A before scheduling work on B.

03Prepare a port and identity worksheet

1. Replace every value with observed inventory before preparing a change. Verify WWPNs from both endpoint and switch, rather than guessing them from a label or serial number.
2. Add rack/U position, serial, model, installed software, license/port entitlement, cable ID, SFP type, peer port, owner and application.
3. Keep management addresses out of zoning membership. The switch management IP is not a storage target WWPN. Record actual topology context before any command that changes zoning.

04Install the switch and optical connections in order

1. Select the hardware installation manual for the exact model and rack kit. Confirm depth, weight, support rails, grounding and service clearance. Director-class installations require their own lifting and module procedures.
2. Check airflow direction against the cold/hot aisle plan. Confirm that the installed fans and power supplies match the model’s airflow requirements. Record how redundant power feeds are actually supplied.
3. Rack and ground the equipment using the model procedure. Connect management/console access and power, then inspect boot and component health before connecting production fabric links.
4. Verify the supported optical transceiver, wavelength, fiber type, connector, speed and maximum reach for each link. Inspect and clean connectors using the site’s optical procedure. Do not look into a live optical port.
5. Install the transceiver and fiber in the order required by the hardware guide, route within the bend-radius limits, label both ends, and connect only the approved endpoint. Leave planned production ISLs isolated until fabric compatibility and merge checks are complete.
6. Compare the physical worksheet with observed switch ports and endpoint WWPNs. Resolve crossed A/B cables or missing port entitlement before zoning.

05Trace login before searching for a LUN

Follow this order when a new host sees no storage: physical link, local login, correct fabric/VSAN/FID, target registration, effective zoning, target-side initiator login, LUN mapping and host multipath/device discovery. This avoids changing a working zoning database to compensate for an unconnected HBA or a missing storage mapping.

06Keep zoning, LUN masking and multipathing separate

Zoning limits which FC ports may communicate through the fabric. LUN masking/mapping controls which storage device the target presents to an authorized initiator group. Host multipathing manages multiple paths to the same device. All three need to agree. Broad zoning does not repair an incorrect igroup, and an additional LUN mapping does not make an absent optical link appear.

1. Use an approved single-initiator zoning design for the conventional examples. Include the required target LIFs from the appropriate fabric and supported reporting nodes, while respecting host path limits.
2. Zone the ONTAP FC LIF WWPNs observed from the storage CLI, rather than the physical adapter’s WWPN. On Cisco, follow NetApp’s restriction that separate LIFs on the same physical port belong in separate zones.
3. After fabric access works, verify exact host WWPN membership in the intended igroup and the correct LUN-to-igroup mapping. Compare the host’s persistent device identity before mounting or using a device.

07Translate the question, not the command name

The Brocade and Cisco procedures intentionally use separate configuration blocks. A Brocade configuration is not a Cisco zone set, and a Cisco device-alias transaction is not a Fabric OS alias. Read-only outputs can also have different scope: local login, fabric directory, logical fabric and effective zoning answer different questions.

08Correlate the switch with ONTAP and the host

1. Match an observed target LIF WWPN to its switch directory entry and physical uplink. Multiple target WWPNs on one physical uplink can be expected with NPIV.
2. Match the host initiator WWPN from its HBA and switch login with the target’s logged-in initiator list. A fabric directory entry is not itself proof of a target session.
3. Compare the mapped LUN and host multipath device using persistent identity, capacity and supported path states. Use the OS-specific host procedure for any rescan; do not issue an indiscriminate disruptive bus reset.

# ONTAP admin — read-only examples:
vserver fcp show -vserver svm_lab
vserver fcp interface show -vserver svm_lab
vserver fcp initiator show -vserver svm_lab
lun igroup show -vserver svm_lab
lun mapping show -vserver svm_lab
# Linux host — read-only:
multipath -ll
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
# Windows host — read-only:
mpclaim -s -d
Get-Disk

09Understand credits, congestion and throughput

Teaching calculation: six hosts each requiring 8 Gb/s of sustained traffic to remote targets create 48 Gb/s of aggregate demand before protocol overhead and failure headroom. A single nominal 32 Gb/s ISL cannot provide that total. Adding links can improve aggregate capacity, but it does not mean a single exchange will use every member simultaneously. Measure normal and failure-state demand.

10Use prechecks and postchecks for every change

1. Timestamp the evidence and retain both sides of each affected link. Back up the correct logical-fabric/VSAN scope.
2. Perform one planned change, review its result, then continue. Do not combine a zone activation, cable move, firmware jump and host driver change into an untraceable experiment.
3. If acceptance fails, stop additional changes, preserve outputs and apply the reviewed recovery decision. A full configuration restore or fabric-wide zone disable is not a routine reversal of one new zone.

11Follow the lab in a basic-to-advanced order

1. Start with the hardware and identity worksheet and inspect a healthy fabric without making changes. Explain every port and login in the worksheet.
2. Follow the vendor’s basics guide to prepare an isolated host-facing port and verify local registration.
3. Use the vendor’s zoning guide to add one approved host-to-target zone, activate through the correct mode, and validate the mapped test LUN.
4. Read the advanced guide before adding an ISL, logical fabric, NPV/Access Gateway topology or firmware upgrade. Each has different scope and failure behavior.
5. Use the troubleshooting guide to explain a missing login, wrong zone, CRC delta and lost path. Rehearse failures only in the approved lab.
6. Answer the interview scenarios by giving evidence, a decision and an acceptance test. Keep your observed results separate from this site’s fictional examples.