Storage Networking

Protocol overview

NAS: NFS

• ONTAP serves NFSv3, NFSv4.0, and NFSv4.1; NFSv4.2 features (space-efficient reflinks) arrived in ONTAP 9.8+. NFSv3 is still the workhorse for Linux/VMware; NFSv4.1 adds sessions (stateful, better recovery) and is common in VMware vSphere.
• Export policies control who can mount what: each rule matches a client (by IP, netgroup, or DNS) and allows/disallows with a security flavor (sys, krb5, krb5i, krb5p, ntlm). The default export policy has a default rule that grants nothing until you edit it — a common first-mount surprise.
• Root squash maps client root (uid 0) to the anonymous user (65534) — enabled by default; needed for security on NFS.
• NFSv4 ID domain — Unix uid/gid ↔ Windows SID mapping must resolve via the SVM's NFSv4 domain config (defaultv4iddomain.com unless set to match your AD/Kerberos realm). A mismatch shows up as squashed/mismatched ownership.
• Exports are paths in the SVM namespace (e.g., /vol1 or a junction like /data).

# NFS service + export policy
vserver nfs show -vserver vs1
vserver export-policy show
vserver export-policy rule show -vserver vs1 -policy default
# Add: allow 10.1.2.0/24 to mount /vol1 with sys auth
vserver export-policy rule create -vserver vs1 -policy default -v4client 10.1.2.0/24 -protocol nfs -rorule sys -rwrule sys
# Test what a client would see (very useful for troubleshooting)
vserver export-policy check-access -vserver vs1 -client-ip 10.1.2.50 -volume vol1 -authentication-method sys

NAS: SMB/CIFS

• SMB 1.0 is disabled by default in ONTAP 9.x — good for security; legacy clients need explicit re-enabling (not recommended).
• A CIFS server is created per SVM, joined to Active Directory. Shares map to namespace paths; NTFS/SMB ACLs plus export-policy-like share ACLs both apply.
• Kerberos for authentication, SMB 3.x for encryption (SMB over QUIC appears in recent ONTAP releases for secure access over untrusted networks — verify version support before relying on it).
• Use vserver cifs share commands to manage shares and their access control (everyone vs. specific groups).

# SMB service + shares
vserver cifs show -vserver vs1
vserver cifs share show -vserver vs1
vserver cifs share create -vserver vs1 -share-name data -path /data -share-properties oplocks

Object: S3

• ONTAP 9.4+ includes a native S3 object-store server on FlexVols — buckets and objects, S3 API compatible (for the supported API surface).
• Use cases: backup targets (e.g., for other NetApp systems via SnapMirror S3), analytics, simple object storage in hybrid clouds.
• Configured per SVM; bucket access via access keys / IAM-style policies (limited).

# S3 object store server + bucket
vserver object-store-server create -vserver vs1 -object-store-server-name s3svm -root-user root -root-password MyP@ssw0rd
vserver object-store-server show
vserver object-store-server bucket create -vserver vs1 -bucket backups

SAN: FC, iSCSI, NVMe

• FC — the classic SAN path. The SVM exposes a WWNN/WWPN per LIF; the fabric is zoned (initiator WWPN ↔ target WWPN), and igroups (initiator groups) map hosts to LUNs with LUN IDs. LUN masking = igroup membership.
• FCoE — FC encapsulated over Ethernet (10/25GbE converged fabric). Less common in new designs.
• iSCSI — LUNs over TCP/IP. Each data LIF is an iSCSI target portal; hosts use IQNs; CHAP authenticates. Multipath via MC/S (multiple connections per session) or multiple LIFs.
• NVMe/FC (ONTAP 9.4+) and NVMe/TCP (ONTAP 9.10+) — NVMe namespaces instead of LUNs; lower latency, deeper queues. NVMe/FC needs FC-NVMe-capable switches. Verify platform support for NVMe/TCP in the ONTAP release you run.
• Block protocol note: a LUN is a file inside a volume (usually a dedicated volume). The volume must exist before the LUN; space can be thin.

# SAN objects
vserver fcp show -vserver vs1
vserver iscsi show -vserver vs1
iscsi initiator show
vserver iscsi connection show -vserver vs1
# LUN + igroup
lun create -vserver vs1 -volume lunvol -lun /vol/lunvol/lun0 -size 2t -ostype linux
igroup create -vserver vs1 -igroup host1 -protocol iscsi -initiator iqn.1994-05.com.example:host1
lun map -vserver vs1 -path /vol/lunvol/lun0 -igroup host1 -lun-id 0

LIFs and the network layer

• LIF (logical interface) = an IP address (or FC WWPN) on a node/port, with a role: data, mgmt, node-mgmt, cluster, intercluster. Data LIFs belong to SVMs; cluster LIFs form the interconnect.
• LIFs have a home node/port and fail over to a partner per failover policy — this is what makes LIF migration and nondisruptive node maintenance work.
• Underneath: ifgrps (port channels: mode multimode_lacp etc.) aggregate physical ports; VLANs tag traffic; routing per SVM via network route.

# Network state
network interface show
network interface show -fields home-node,home-port,status-oper
network port show -fields link,duplex,speed
network route show -vserver vs1
# Create a data LIF
network interface create -vserver vs1 -lif data1 -role data -data-protocol nfs -home-node node1 -home-port e0c -address 10.0.0.5 -netmask 255.255.255.0
# Test connectivity to a LIF from the cluster
network ping-lif -vserver vs1 -lif data1

Exam traps to know

• Export policies control NFS mounts; igroups control SAN LUN access; share ACLs + NTFS ACLs control SMB access. Don't mix them up.
• NFSv3 is stateless; NFSv4.x is stateful (sessions/locks).
• LUNs live in volumes — you can't create a LUN without a volume.
• Data LIFs belong to SVMs; a LIF's failover is about network availability, not storage takeover.
• SMB needs the SVM joined to AD (or workgroup for simple setups); Kerberos issues usually show up as auth failures, not share-not-found.
• iSCSI + FC use igroups (initiator WWPN/IQN → LUN mapping). NVMe uses subsystems/namespaces — same concept, different vocabulary.

Next: Data protection →