Interview examples use a two-node ONTAP HA pair and one test host. Be clear about host OS and ONTAP version: supported path count, host utilities and settings come from the NetApp Interoperability Matrix and SAN Host Configuration.
Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.
1. Explain the end-to-end path from host to an ONTAP LUN.
- A host initiator is identified by an iSCSI IQN or FC WWPN. It establishes a session or fabric path to ONTAP target LIFs. An ONTAP igroup contains the permitted initiators; a LUN mapping associates the LUN with the igroup and a LUN ID. The host then discovers the device and multipath groups paths to its unique device identity.
- Example: host linux01 has two iSCSI NICs on separate networks, IQN iqn.1993-08.org.debian:01:linux01, four target paths across an HA pair, and one mapped LUN. Confirm the actual supported topology before promising four paths. Zoning and host path management differ for FC.
vserver iscsi show
network interface show
igroup show
lun mapping showName every authorization boundary between the host initiator and the presented device.
2. What is the difference between an igroup and FC zoning?
- FC zoning controls which WWPNs can communicate within a fabric. An igroup controls which host initiators ONTAP permits to see a mapped LUN. Both are required layers in a typical FC design; zoning alone does not grant LUN access, and an igroup alone cannot create a fabric path.
- Use WWPN zoning for ONTAP. Discuss single-initiator zones and separate fabrics based on the validated design, then explain how you would compare HBA login, target LIF WWPN, active zoneset, igroup membership and mapping to find a missing path.
Distinguish fabric visibility from LUN authorization.
3. Why is multipathing necessary and what is ALUA?
- Multiple physical/fabric paths permit host I/O to continue after a NIC, HBA, switch, cable, target port or node path fails. ALUA reports path states so the host can prefer optimized access to the LUN owner while retaining alternate paths according to the supported host stack. Do not treat seeing many devices as proof that multipath works.
- Validate the host multipath package or native driver, unique LUN serial, path states, path count and failover behavior for the supported OS/ONTAP combination. SAN LIFs and NAS LIFs have different availability patterns; do not assume a SAN LIF migrates like a NAS client LIF.
Show one host observation before and after taking down a single test path in an approved window.
4. Explain Selective LUN Map (SLM) and reporting nodes.
- SLM reduces the number of paths the host sees by reporting the mapped LUN through the node that owns its volume and its HA partner by default in typical ONTAP configurations. The reporting-nodes list can change for migrations and specific supported designs; adding every cluster node is not a generic cure for a missing path.
- In a host issue, check the mapping and reporting nodes, then compare the physical topology and path visibility. If moving a LUN or volume, follow the ONTAP host path update procedure and validate both before and after the move.
lun mapping show
lun mapping show -fields reporting-nodesExplain why an optimized and a non-optimized path can both be valid.
5. Compare iSCSI and FC operations.
- iSCSI carries SCSI over IP and depends on IP addresses, VLAN/routing, target portals, initiator IQNs and optionally CHAP. FC uses a dedicated fabric, target and initiator WWPNs, login and zoning. Both present block LUNs through igroup mappings and require supported host multipath.
- For iSCSI, prove network reachability and sessions before blaming LUN mapping. For FC, prove HBA link, switch fabric login and zoning before changing ONTAP. Treat MTU consistency, authentication, switch redundancy and host driver/utility versions as part of the design.
Give a first check at the transport layer for each protocol.
6. What is the safe sequence for provisioning and decommissioning a LUN?
- Provision: validate support matrix and capacity; create correct SVM target LIFs; establish dual paths; create volume and LUN with correct host OS type; create the host-specific igroup; map the LUN; rescan host; confirm serial, size and multipath; then format on the intended host.
- Decommission: obtain application approval, stop I/O, unmount or remove datastore and host references, verify the device is unused on every host, remove the mapping, wait for host path removal, then remove the LUN under a documented retention plan. A mistaken delete or format can destroy data, so never identify a LUN by size alone.
The host sees exactly the intended serial before format and no host retains a path before deletion.
7. How do snapshots and DR affect SAN data?
- A storage snapshot of an active LUN may be crash consistent; applications such as databases may require coordinated quiescing, host integration or application backups for a usable recovery. SnapMirror can replicate its containing volume, but write ordering across multiple volumes needs an application-consistent design.
- In a DR interview, explain how you identify the last complete recovery point, prevent split writes, activate the destination, map LUNs to DR host igroups, rescan safely and test the application before failback. Never present both source and destination writable copies to the same host without an explicit clustered application design.
State how you will prove a restored application, not just a visible block device.