Networking basics for storage admins
Most “storage is slow” calls end up being network problems: a wrong VLAN, a half-broken LACP bundle, or one switch port with a different MTU. Storage admins who understand the network fix those in minutes instead of waiting on another team.
This page covers the networking you need before the ONTAP networking lessons: layers, the trip a packet takes from a client to a LIF, VLANs, link bundles and MTU.
Where this page fits
Deep dive in NetApp ONTAP Storage Administration · Phase 1, Architecture and foundation · Before this: Lesson 18, Qtrees and FlexGroup volumes · Next: Lesson 19, Ports, interface groups and VLANs
| Time | You need | By the end you can |
|---|---|---|
| 60 minutes | The practice shell 1.2, with host mode for the linux1 client | Trace a packet from client to storage, read ARP and route tables, test MTU end to end, and build a VLAN interface |
What it is, in one line
Storage networking basics are the few layers of networking that decide whether a client’s read reaches the right storage port quickly, or gets lost, split or dropped on the way.
In Simple Words
Sending a parcel across the city
When you post a parcel, the address on the box says which city and house (that’s the IP address). The courier at each hub only cares about the next hub, and the last van needs the exact house door (that’s the MAC address).
If the box is bigger than the van door, it doesn’t fit. Networks have the same rule, called MTU, and it causes more storage trouble than people expect.
Engineer's View
The layers a storage admin really uses
Layer 1 is the cable and the link light, layer 2 is Ethernet frames, MAC addresses, VLAN tags and switches, and layer 3 is IP addresses, subnets and routers. Layer 4 is TCP or UDP ports: NFS uses TCP 2049, SMB uses TCP 445, iSCSI uses TCP 3260.
In ONTAP these map to physical ports (e0c), interface groups (a0a) for link bundles, VLAN ports (a0a-20), broadcast domains for layer 2, and LIFs that carry the IP address. A standard Ethernet frame carries 1500 bytes of payload; jumbo frames carry 9000, and every hop on the path must agree.
How it works, step by step
1The life of a packet: client to LIF
Say linux1 (192.168.56.21) reads a file from an NFS LIF at 192.168.56.130. The client checks its route table: the LIF is on its own subnet, so no router is needed.
It then needs the LIF’s MAC address, so it sends an ARP broadcast (“who has 192.168.56.130?”) and the node that hosts the LIF answers. The frame goes to the switch, the switch looks up that MAC in its table, and sends it out of the one port that leads to the storage node.
If the LIF were on another subnet, the client would send the frame to its gateway’s MAC instead, and the router would repeat the ARP step on the far side. That’s why a LIF that moves to a port in the wrong VLAN suddenly can’t be reached.
2VLANs and trunks
A VLAN splits one physical switch into several separate layer 2 networks. An access port carries one VLAN with no tag, while a trunk port carries many VLANs, each frame tagged with a 12-bit ID (1 to 4094) under the 802.1Q standard.
Storage ports are usually trunks, so one cable can carry NFS on VLAN 20, iSCSI on VLAN 30 and backup on VLAN 40. In ONTAP you create a VLAN port such as e0c-20 or a0a-20, and the switch port must allow that VLAN on its trunk or the traffic goes nowhere.
3Bundling links: NIC teaming and LACP
Bundling two or more ports gives you a spare link and more total bandwidth. LACP (802.3ad) lets both sides agree on the bundle and drop a bad member on their own; a static bundle just assumes every member works.
One thing surprises people: a single TCP connection still uses one member link, because the switch and the host pick a link by hashing addresses and ports. More clients spread over more links; one client doesn’t get double speed.
| Bundle type | Linux name | ONTAP name | Switch side |
|---|---|---|---|
| Active-backup (one link used) | bond mode active-backup | ifgrp -mode singlemode | Nothing special |
| Static (all links used) | bond mode balance-xor | ifgrp -mode multimode | Static port channel |
| LACP (all links, negotiated) | bond mode 802.3ad | ifgrp -mode multimode_lacp | LACP port channel |
4MTU and jumbo frames
Jumbo frames (MTU 9000) cut the number of packets for big transfers, which can lower CPU use on clients and storage. They only work if the client NIC, every switch port on the path and the ONTAP port all allow 9000 bytes.
When one hop is still at 1500, small packets work and big ones get dropped. Mounts succeed, ls works, and then a large copy hangs, which is the classic symptom. In ONTAP the MTU is set on the broadcast domain, as you can see in the practice shell:
saat-cluster::> network port broadcast-domain show
IPspace Broadcast Update
Name Domain Name MTU Port List Status Details
------- ----------- ------ ----------------------------- --------------
Cluster Cluster 9000
saat-cluster-01:e0a complete
...
Default Default 1500
saat-cluster-01:e0c complete
...The cluster network always uses 9000; data networks use whatever your switches support end to end.
Hands-on lab: trace ARP, capture NFS, test MTU and build a VLAN
Before you run any command, double-check it
Read every command twice before you press Enter. Check the target: the server name, the user, the disk or device name, the path and the sizes. These commands are for learning and were tested in our lab, not on your system. At work, run the read-only commands first, follow your change process, make sure a backup exists, and ask a second person to check anything that changes or deletes data. You run them at your own risk.
This lab uses the SaatVedha ONTAP practice shell, our own learning tool. It is not NetApp software: real ONTAP output looks like this but is not identical.
This lab uses two terminals. The first runs the practice cluster, which plays the storage side.
The second runs python ontapsim.py --host linux1, a real-looking Ubuntu 24.04 client at 192.168.56.21 that shares the lab with the cluster. Your MAC addresses and timings will differ from the examples.
1Build the storage side
Save these lines as setup-net.txt, then reset and run it in the first terminal. It creates an SVM with an NFS LIF on the 192.168.56.0/24 network, a volume at /lab, and a second LIF on tagged VLAN 20.
storage aggregate create -aggregate aggr1_01 -node saat-cluster-01 -diskcount 8 -disktype SAS
storage aggregate create -aggregate aggr1_02 -node saat-cluster-02 -diskcount 8 -disktype SAS
vserver create -vserver svm1 -aggregate aggr1_01 -rootvolume-security-style unix
network interface create -vserver svm1 -lif svm1_nas1 -service-policy default-data-files -home-node saat-cluster-01 -home-port e0c -address 192.168.56.130 -netmask 255.255.255.0
vserver export-policy rule create -vserver svm1 -policyname default -clientmatch 192.168.56.0/24 -rorule sys -rwrule sys -superuser sys
vserver nfs create -vserver svm1 -v3 enabled -v4.1 enabled
volume create -vserver svm1 -volume vol_lab -aggregate aggr1_01 -size 20g -junction-path /lab
network port vlan create -node saat-cluster-01 -vlan-name e0e-20
network port broadcast-domain create -broadcast-domain bd_vlan20 -mtu 1500 -ipspace Default -ports saat-cluster-01:e0e-20
network interface create -vserver svm1 -lif svm1_nas20 -service-policy default-data-files -home-node saat-cluster-01 -home-port e0e-20 -address 192.168.20.130 -netmask 255.255.255.0python ontapsim.py -c "simctl reset"
python ontapsim.py --run setup-net.txt✅ Checkpoint: No line in the output starts with Error.
2Look at the client’s interfaces, route and ARP table
In the second terminal, start linux1 with python ontapsim.py --host linux1 and run:
ip -br a
ip route get 192.168.56.130
ip neigh flush dev enp0s8
ip neigh
ping -c 2 192.168.56.130
ip neighYou should see this:
root@linux1:~# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
enp0s3 UP 10.0.2.15/24 metric 100 fe80::a00:27ff:fe59:f91f/64
enp0s8 UP 192.168.56.21/24 fe80::a00:27ff:feff:6dcf/64
root@linux1:~# ip route get 192.168.56.130
192.168.56.130 dev enp0s8 src 192.168.56.21 uid 0
cache
root@linux1:~# ip neigh flush dev enp0s8
root@linux1:~# ip neigh
root@linux1:~# ping -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 56(84) bytes of data.
64 bytes from 192.168.56.130: icmp_seq=1 ttl=64 time=0.292 ms
64 bytes from 192.168.56.130: icmp_seq=2 ttl=64 time=0.329 ms
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.292/0.310/0.329/0.019 ms
root@linux1:~# ip neigh
192.168.56.130 dev enp0s8 lladdr 00:a0:98:54:28:6c REACHABLE ip route get says the LIF is reached directly through enp0s8, with no “via” gateway: a same-subnet trip. Before the ping, the ARP table was empty; the ping triggered an ARP request, and now the LIF’s MAC is cached. The 00:a0:98 at the start is NetApp’s vendor prefix, so you can spot ONTAP LIFs in any ARP table.
✅ Checkpoint: ip neigh shows 192.168.56.130 as REACHABLE.
3Mount over NFS and watch the packets
Install the NFS client, mount the volume and capture four packets to port 2049:
apt install -y nfs-common tcpdump
mkdir -p /mnt/lab
mount -t nfs -o vers=4.1 192.168.56.130:/lab /mnt/lab
ss -tn
tcpdump -nn -i enp0s8 -c 4 port 2049You should see this (the apt lines are trimmed):
root@linux1:~# mkdir -p /mnt/lab
root@linux1:~# mount -t nfs -o vers=4.1 192.168.56.130:/lab /mnt/lab
root@linux1:~# ss -tn
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.56.21:756 192.168.56.130:2049
ESTAB 0 0 192.168.56.21:22 192.168.56.1:51842
root@linux1:~# tcpdump -nn -i enp0s8 -c 4 port 2049
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:06:45.306356 IP 192.168.56.21.756 > 192.168.56.130.2049: Flags [P.], seq 1:245, ack 1, win 502, options [nop,nop,TS val 3141592 ecr 271828], length 244: NFS request xid 2285417 240 getattr fh 0,0/22
12:06:45.306910 IP 192.168.56.130.2049 > 192.168.56.21.756: Flags [P.], seq 1:201, ack 245, win 4116, options [nop,nop,TS val 271828 ecr 3141592], length 200: NFS reply xid 2285417 reply ok 196 getattr NON 4 ids 0/0 sz 0
12:06:45.307726 IP 192.168.56.21.756 > 192.168.56.130.2049: Flags [P.], seq 245:489, ack 245, win 502, options [nop,nop,TS val 3141593 ecr 271829], length 244: NFS request xid 2285418 240 getattr fh 0,0/22
12:06:45.307925 IP 192.168.56.130.2049 > 192.168.56.21.756: Flags [P.], seq 245:445, ack 489, win 4116, options [nop,nop,TS val 271829 ecr 3141593], length 200: NFS reply xid 2285418 reply ok 196 getattr NON 4 ids 0/0 sz 0
4 packets captured
4 packets received by filter
0 packets dropped by kernelss -tn shows one TCP connection from linux1 to port 2049 on the LIF: that single connection carries every NFSv4.1 call. In tcpdump, each request from .21 gets a reply from .130, here GETATTR calls the client makes to check the mount. On a real client, start tcpdump before the mount to see the TCP handshake too.
✅ Checkpoint: ss shows an ESTAB connection to 192.168.56.130:2049 and tcpdump captures 4 packets.
4Test the MTU end to end
ping -M do -s 1472 -c 2 192.168.56.130
ping -M do -s 8972 -c 2 192.168.56.130
tracepath 192.168.56.130You should see this:
root@linux1:~# ping -M do -s 1472 -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 1472(1500) bytes of data.
1480 bytes from 192.168.56.130: icmp_seq=1 ttl=64 time=0.471 ms
1480 bytes from 192.168.56.130: icmp_seq=2 ttl=64 time=0.337 ms
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.337/0.404/0.471/0.067 ms
root@linux1:~# ping -M do -s 8972 -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1006ms
root@linux1:~# tracepath 192.168.56.130
1?: [LOCALHOST] pmtu 1500
1: 192.168.56.130 0.522ms reached
1: 192.168.56.130 0.401ms reached
Resume: pmtu 1500 hops 1 back 1 -M do forbids splitting the packet, so 1472 bytes of data plus 28 bytes of headers fills a 1500 frame exactly. The 8972-byte test is the one you run when someone says “we use jumbo frames”: it must pass on every client before you trust it. tracepath reports the path MTU (pmtu 1500) without any guessing.
✅ Checkpoint: 1472 passes, 8972 fails with mtu=1500, and tracepath shows pmtu 1500.
5Reach a LIF on a tagged VLAN
The cluster already has a LIF at 192.168.20.130 on VLAN 20 (port e0e-20). linux1 has no interface on that VLAN yet, so the first ping fails. Then add a tagged VLAN interface on top of enp0s8:
ping -c 2 192.168.20.130
ip link add link enp0s8 name enp0s8.20 type vlan id 20
ip addr add 192.168.20.21/24 dev enp0s8.20
ip link set enp0s8.20 up
ip -br a
ping -c 3 192.168.20.130You should see this:
root@linux1:~# ping -c 2 192.168.20.130
PING 192.168.20.130 (192.168.20.130) 56(84) bytes of data.
--- 192.168.20.130 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms
root@linux1:~# ip link add link enp0s8 name enp0s8.20 type vlan id 20
root@linux1:~# ip addr add 192.168.20.21/24 dev enp0s8.20
root@linux1:~# ip link set enp0s8.20 up
root@linux1:~# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
enp0s3 UP 10.0.2.15/24 metric 100 fe80::a00:27ff:fe59:f91f/64
enp0s8 UP 192.168.56.21/24 fe80::a00:27ff:feff:6dcf/64
enp0s8.20@enp0s8 UP 192.168.20.21/24 fe80::a00:27ff:feff:6dcf/64
root@linux1:~# ping -c 3 192.168.20.130
PING 192.168.20.130 (192.168.20.130) 56(84) bytes of data.
64 bytes from 192.168.20.130: icmp_seq=1 ttl=64 time=0.318 ms
64 bytes from 192.168.20.130: icmp_seq=2 ttl=64 time=0.302 ms
64 bytes from 192.168.20.130: icmp_seq=3 ttl=64 time=0.563 ms
--- 192.168.20.130 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.302/0.394/0.563/0.119 msenp0s8.20@enp0s8 is a child of enp0s8 that tags its frames with VLAN 20. That’s exactly what ONTAP did when you created e0e-20: a tagged child port on a physical port. On real VMs, VirtualBox may need Adapter 2’s Promiscuous Mode set to “Allow VMs” for VLAN traffic.
✅ Checkpoint: The second ping to 192.168.20.130 gets 3 replies.
Try it yourself: Build an ONTAP VLAN port in the Command Builder.
Break It, Then Fix It
Now make the MTU mismatch that causes so many “NFS hangs on big files” tickets, and fix it. Keep both terminals open.
1Raise the MTU on one side only
In the cluster terminal, run simctl break mtu-mismatch linux1. It sets linux1’s enp0s8 to MTU 9000 while the network path stays at 1500.
saat-cluster::> simctl break mtu-mismatch linux1
simctl: fault "mtu-mismatch" is active on linux1. Now find it from the host and the cluster.Then in the linux1 terminal:
ip a show enp0s8
ping -c 2 192.168.56.130
ping -M do -s 8972 -c 2 192.168.56.130
ping -M do -s 1472 -c 2 192.168.56.130You’ll get this:
root@linux1:~# ip a show enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:ff:6d:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.56.21/24 brd 192.168.56.255 scope global enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feff:6dcf/64 scope link
valid_lft forever preferred_lft forever
root@linux1:~# ping -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 56(84) bytes of data.
64 bytes from 192.168.56.130: icmp_seq=1 ttl=64 time=0.452 ms
64 bytes from 192.168.56.130: icmp_seq=2 ttl=64 time=0.606 ms
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.452/0.529/0.606/0.077 ms
root@linux1:~# ping -M do -s 8972 -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 8972(9000) bytes of data.
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms
root@linux1:~# ping -M do -s 1472 -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 1472(1500) bytes of data.
1480 bytes from 192.168.56.130: icmp_seq=1 ttl=64 time=0.452 ms
1480 bytes from 192.168.56.130: icmp_seq=2 ttl=64 time=0.606 ms
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.452/0.529/0.606/0.077 msSmall pings and 1500-byte pings work, so “the network is fine” to anyone who only runs a plain ping. But linux1 now sends 9000-byte frames that the path drops without a word, and big NFS writes hang. Notice there’s no “message too long” error this time: the client thinks 9000 is allowed.
✅ Checkpoint: Small pings pass and the 8972-byte ping loses every packet.
2Find it and fix it
Compare both ends. In the cluster terminal, check the LIF’s port and its broadcast domain:
network port show -node saat-cluster-01 -port e0c -fields mtu
network port broadcast-domain show -broadcast-domain Default -fields mtusaat-cluster::> network port show -node saat-cluster-01 -port e0c -fields mtu
node port mtu
--------------- ---- ----
saat-cluster-01 e0c 1500
saat-cluster::> network port broadcast-domain show -broadcast-domain Default -fields mtu
ipspace broadcast-domain mtu
------- ---------------- ----
Default Default 1500The storage side is at 1500, so the client is the odd one out. Put it back in the linux1 terminal and test again:
ip link set dev enp0s8 mtu 1500
ip a show enp0s8
ping -M do -s 1472 -c 2 192.168.56.130You should see this:
root@linux1:~# ip link set dev enp0s8 mtu 1500
root@linux1:~# ip a show enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:ff:6d:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.56.21/24 brd 192.168.56.255 scope global enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feff:6dcf/64 scope link
valid_lft forever preferred_lft forever
root@linux1:~# ping -M do -s 1472 -c 2 192.168.56.130
PING 192.168.56.130 (192.168.56.130) 1472(1500) bytes of data.
1480 bytes from 192.168.56.130: icmp_seq=1 ttl=64 time=0.353 ms
1480 bytes from 192.168.56.130: icmp_seq=2 ttl=64 time=0.657 ms
--- 192.168.56.130 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.353/0.505/0.657/0.152 msFinally clear the lab fault in the cluster terminal with simctl fix mtu-mismatch. At work, either set every hop (client, switch ports, ONTAP broadcast domain) to 9000 or put the odd one back to 1500; never leave a mix.
saat-cluster::> simctl fix mtu-mismatch
simctl: fixed mtu-mismatch.✅ Checkpoint: linux1 shows mtu 1500 and the 1472-byte test passes again.
This happened at work
Backups that died at 3 a.m.
A steel plant in Jamshedpur moved its backup network to jumbo frames over a weekend. The storage team set the ONTAP broadcast domain to 9000 and the backup server’s NICs to 9000, and every test copy of a small folder worked.
That night the full backup ran for twenty minutes and then stalled, and so did the next three nights. The network team said the switches were “configured for jumbo”, but one older switch in the middle had the setting on the uplinks only, not on the ports facing the backup server.
Someone finally ran ping -M do -s 8972 from the backup server to the LIF and got 100% loss, while small pings were fine. One switch port change later the backups finished in half the old time, and the team added the 8972-byte ping to their change checklist for any MTU work.
Common mistakes and troubleshooting
| Mistake | What happens | Do this instead |
|---|---|---|
| Setting MTU 9000 on storage and hosts but not on every switch hop | Mounts work, large transfers hang | Test with ping -M do -s 8972 from every client to every LIF |
| Creating a VLAN port on ONTAP without adding the VLAN to the switch trunk | The LIF is up but nothing can reach it | Ask for the switch trunk change first, then test with network ping from the LIF |
| Expecting LACP to double the speed of one client | One TCP session still uses one link | Plan bandwidth per client, use more sessions (nconnect, multipath) if needed |
| Mixing LACP on one side with a static bundle on the other | Flapping links, packet loss | Use multimode_lacp only with an LACP port channel on the switch |
| Putting storage and clients in different subnets without a route | Timeouts, “no route to host” | Keep NAS clients on the LIF subnet, or add a route on the SVM |
Interview questions
Click a question to open it. Each one is written the way an interviewer would ask it. Under it you will see why they ask it and one way you could answer, in your own words.
Fresher level
1. In simple words, what’s the difference between a MAC address and an IP address?
Why they ask this: They want to see you understand layer 2 and layer 3, which every storage network question builds on.
How you might answer: The IP address says which host the data is for, across networks. The MAC address is the hardware address of the next hop on the local network, and ARP finds it from the IP.
So a packet keeps the same IP addresses end to end, but the MAC addresses change at every router.
2. What ports do NFS, SMB and iSCSI use?
Why they ask this: They’re checking basic facts you’ll need for firewall requests.
How you might answer: NFS uses TCP 2049, SMB uses TCP 445 and iSCSI uses TCP 3260. For NFSv3 the client also talks to helper services like mountd, so I check the ports for those too before a firewall change.
2–5 years experience
3. A Linux client can mount an NFS export, but copying a big file hangs. What would you check?
Why they ask this: They want to see if you recognise an MTU problem and know how to prove it.
How you might answer: That pattern makes me think of an MTU mismatch. I’d run ping -M do -s 8972 and then -s 1472 from the client to the LIF; if the small one passes and the big one fails, some hop isn’t set for jumbo frames.
Then I’d compare the MTU on the client, each switch port and the ONTAP broadcast domain, and make them all match.
4. You add VLAN 30 for iSCSI on the storage side and the LIF can’t be reached. Where would you look?
Why they ask this: They’re checking a logical, layer-by-layer approach.
How you might answer: First I’d confirm the switch trunk allows VLAN 30 on every port that the ONTAP VLAN port uses, on both nodes. Then I’d check the ONTAP side: the VLAN port is up, it’s in the right broadcast domain, and the LIF’s home port is that VLAN port. I’d test with network ping from the LIF to the host.
Senior level
5. How would you design the network for a new two-node cluster serving NFS and iSCSI?
Why they ask this: They want to see design thinking: redundancy, separation and performance.
How you might answer: I’d use LACP interface groups on each node across two switches, with VLANs for NFS and iSCSI on top. NFS LIFs would sit in a broadcast domain with ports on both nodes so they can fail over, and iSCSI would get two separate subnets or VLANs for two independent paths.
I’d only use jumbo frames if every hop supports them, and I’d prove it with an 8972-byte ping before go-live.
6. Your network team wants to move the storage switches to a new core during business hours. How would you protect the storage traffic?
Why they ask this: They’re checking risk thinking and teamwork across teams.
How you might answer: I’d ask for the change one switch at a time, so LACP and ONTAP LIF failover keep one path alive. Before each step I’d note which LIFs are home and check host multipath, and after each step I’d check network interface show -is-home false and the host paths.
Quick quiz
Q1. Which TCP port does NFS use?
- 445
- 3260
- 2049
- 22
Show answer
C — NFS uses TCP 2049.
Q2. What does ARP do?
- Finds the MAC address for an IP address
- Assigns IP addresses
- Routes between subnets
- Encrypts frames
Show answer
A — ARP turns a known IP address into the MAC address of that host on the local network.
Q3. With an MTU of 1500, the largest ping payload with -M do is:
- 1500
- 1472
- 8972
- 9000
Show answer
B — 1500 minus 20 bytes IP and 8 bytes ICMP leaves 1472.
Q4. What is a trunk port?
- A port that carries several VLANs with tags
- A port in an LACP bundle
- A port that only carries storage
- A port with MTU 9000
Show answer
A — trunk ports carry many VLANs, each frame tagged with its VLAN ID.
Q5. Does LACP make a single TCP session twice as fast over two links?
- Yes, always
- Only with jumbo frames
- No, one session uses one link
- Only on ONTAP
Show answer
C — the hash picks one link per flow; more flows use more links.
Quick recap
- IP gets the data to the right host; MAC gets it to the next hop; ARP links the two.
- VLANs split one switch into separate networks; trunks carry many tagged VLANs.
- LACP bundles add a spare link and more total bandwidth, not more speed per session.
- Jumbo frames need 9000 on every hop; prove it with ping -M do -s 8972.
- ONTAP maps this to ports, interface groups, VLAN ports, broadcast domains and LIFs.
Next lesson
Lesson 19: Ports, interface groups and VLANs → You’ll build an LACP interface group and VLAN ports on the practice cluster.
Further reading: storage networking basics
Want to go deeper into storage networking basics? NetApp’s ONTAP concepts guide explains how ports, broadcast domains and LIFs fit together on a cluster. You can also see the full plan for this course on the NetApp ONTAP Storage Administration course page.