NetApp ONTAP Network Troubleshooting: Essential CLI Commands

When a NetApp ONTAP cluster starts dropping client traffic or failing replication, the first step is isolating the network layer — and ONTAP gives you a complete diagnostic toolkit without leaving the cluster CLI. This guide maps each command to the problem it solves: reachability checks with network ping, path tracing with network traceroute, neighbor discovery with network ndp, interface statistics via the nodeshell, and packet capture with network tcpdump. All commands are from the official ONTAP 9 documentation.

Reachability and Path Testing

Reachability is the cheapest test and it answers a question you should settle before anything else: is the problem specific to one LIF, or does it affect the whole node? A ping sourced from a LIF tells you what a client would see; a ping from the node tells you whether the physical path and the ARP/NDP resolution work at all. When the node can reach a host but the LIF cannot, the fault is in LIF, VLAN or routing configuration rather than in cables or switch ports.

network ping -node node1 -destination 10.1.1.10 -count 5
network ping -vserver svm1 -lif lif1 -destination 10.1.1.10
network ping6 -node node1 -destination 2001:db8::10
network traceroute -node node1 -destination 10.1.1.10

Run the ping from both sides where possible. If the storage node can reach the client but the client cannot reach the storage node, you are looking at a return path problem — a static route on the client side, a firewall rule, or a switch VLAN mismatch — not at a problem inside ONTAP.

Interface and Neighbor Checks

Display packet statistics for a specific network interface (available from the nodeshell):

run -node node_name ifstat

Show neighboring devices discovered from each node and port, including remote device type and platform:

network device-discovery show

View CDP neighbors (ONTAP supports CDPv1 advertisements only):

run -node node_name cdpd show-neighbors

Before you go deeper, confirm the basics of LIF placement and health. A LIF that has failed over to a port you did not expect still works, but it can send traffic along a path you were not counting on — and if that path is congested or routed differently, clients see slow or intermittent access with no visible error.

network interface show -vserver svm1
network interface show -fields home-node,home-port,curr-node,curr-port,is-home
network interface show -vserver svm1 -lif lif1 -instance
network port show -node node1
network port ifgrp show -node node1
network port vlan show -node node1
network port broadcast-domain show
network arp show -vserver svm1

What to look for: is-home false means the LIF is not on its home port; network port show shows link state, MTU and errors per port; network port ifgrp show confirms that an interface group has its ports up and distributed correctly; network arp show verifies that the gateway's MAC address is resolved for the broadcast domain.

LIF Failover and Migration

Failover behaviour is one of the most common causes of “the cluster lost a client” after maintenance. Check the failover groups and the broadcast domains a LIF may move into, then test the move deliberately instead of waiting for a real outage:

network interface failover-groups show
network interface migrate -vserver svm1 -lif lif1 -dest-node node2 -dest-port e0c
network interface revert -vserver svm1 -lif lif1

If a LIF migrates successfully but clients still cannot reach it, the destination port's broadcast domain or VLAN tagging is the likely culprit. Checking the broadcast domain before a maintenance window is far cheaper than discovering a missing VLAN at 03:00.

Packet Capture

Trace packets sent and received on a port (nodeshell command):

network tcpdump start -node node-name -port port_name

Packet capture is the tool that ends arguments. ONTAP writes a pcap file on the node, which you can pull off and open in Wireshark: check whether the SYN leaves the port at all, whether the reply arrives, and whether the VLAN tag, MTU or source address is what you assumed. Typical findings include jumbo frames configured on the storage side but not on the switch, TCP retransmissions caused by a congested uplink, and TCP MSS problems on traffic that traverses a tunnel or a device that rewrites MTU.

network tcpdump start -node node1 -port e0c
network tcpdump stop -node node1

Remember to stop the capture when you are done. A forgotten tcpdump on a busy data LIF fills the node's filesystem, which turns a network issue into a cluster issue.

Intercluster and Intracluster Path Testing

Measure latency and throughput between intercluster or intracluster nodes:

network test -path -source-node node1 local -destination-cluster cluster2 -destination-node node2 -session-type Default,AsyncMirrorLocal,AsyncMirrorRemote,SyncMirrorRemote,RemoteDataTransfer

This is invaluable when SnapMirror transfers are slow or time out — it isolates whether the problem is the network path or the data transfer itself. The session types map to the real workloads ONTAP runs across that path: management traffic, asynchronous mirroring inside the cluster, asynchronous mirroring across clusters, synchronous mirroring and remote data transfer. Testing each one separately tells you whether, for example, small management packets are fine while large throughput streams are not — which points at an MTU, shaping or QoS problem rather than latency.

Pair the path test with the peer state:

cluster peer health show
snapmirror show -fields state,healthy
network connections active show -vserver svm1

If the peer health is degraded or the cluster peer relationship is not healthy, the transfer problem is a consequence, not the cause.

Reading ifstat Without Guessing

ifstat is the single most useful output you can collect on a node, because it separates “nothing was sent” from “something was sent and came back broken”. The columns to read first are the receive and transmit error counters: ierrors, oerrors, idrops, odrops and the collision and no-buffer counts. A steady trickle of input errors points at a physical problem — a dirty or marginal optic, a duplex mismatch on an old copper link, or a cable that only fails under load. Output drops with clean error counters usually mean congestion or a speed mismatch: traffic arrives faster than the port can transmit, and the queue silently discards frames.

run -node node1 ifstat
run -node node1 ifstat -a

Take two samples a minute apart rather than trusting a single snapshot. Storage traffic is bursty, and a counter that is flat while the client complains proves the packets never arrived, which moves the investigation onto the switch. Sample, correlate timestamps with the client-side error, and only then start changing things.

Testing From the Client Side

The cluster CLI only sees the storage end of the conversation. To close the loop, reproduce the fault from the client with the same protocol the application uses: mount the NFS export and read a large file, or run a short dd or fio pass over iSCSI and watch dmesg and the network interface counters while it runs. A single ping proves reachability, not throughput — a path with an MTU mismatch or a congested uplink passes every ping and fails every large transfer. If the client-side counters show retransmissions while ONTAP shows clean transmit statistics, the loss is happening on the return path or in the middle of the fabric, and the packet capture is what pinpoints it.

Symptom to Cause: A Quick Map

What ONTAP Cannot Tell You

ONTAP can prove that a packet left the port and that nothing came back, but it cannot explain what the switch did with it. Once you have evidence from the storage side, check the other half:

• Switch port counters for CRC errors, discards and pause frames — physical layer faults masquerade as “slow storage”.
• LLDP/CDP neighbours on both ends, to confirm that the port you think you are patched into is the port you are actually patched into.
• MTU and jumbo-frame settings end to end. A mismatch that relies on fragmentation works for pings and fails for throughput.
• LACP and interface group hashing. A single-member failure inside a group is invisible to ONTAP until traffic lands on that member.
• Firewall or routing rules for the intercluster LIFs — often a recently changed ACL.

Collecting Evidence Before You Open a Case

NetApp support will ask for a specific set of outputs, and gathering them up front shortens the cycle. Capture the following while the fault is happening, not afterwards:

network interface show -fields is-home,curr-node,curr-port
network port show -node node1
run -node node1 ifstat
network device-discovery show
network ping -node node1 -destination 10.1.1.10
network traceroute -node node1 -destination 10.1.1.10
event log show -severity ERROR -time >1hours

Timestamp everything. A network fault that has already cleared is very hard to diagnose from a healthy-state dump, and the EMS log plus a concurrent packet capture is usually what turns “intermittent” into a root cause.

A Worked Case: Intermittent NFS Timeouts After a Switch Change

A customer reported mount commands that timed out for about ninety seconds, once or twice a day, on one SVM. The storage side looked healthy: no EMS errors, CPU low, no disk latency. Working from the CLI the path was:

network interface show -vserver nfs_svm -fields is-home,curr-node,curr-port
network port show -node node2
run -node node2 ifstat -a
network device-discovery show -node node2
network tcpdump start -node node2 -lif nfs_lif -count 200 -filter "host 10.20.30.40"

The LIF had failed over earlier in the week and was now homed on a port whose LACP aggregate had lost one member. ifstat on that port showed a steady trickle of unknown-protocol and discard counters climbing whenever the delay occurred, which pointed at a member link that was up but forwarding badly. The switch side confirmed a single-member flap. Because only one LAG member was affected, the failure was intermittent rather than total — the exact signature that makes an NFS timeout look like a storage problem.

The lesson generalises: when timeouts are intermittent and storage metrics are clean, capture on the LIF itself and read the port counters at the same moment. A capture that shows retransmits leaving but no replies returning has moved the question from the array to the wire, and the ifstat deep dive covers reading those counters in detail.

Choosing the Right Tool: A Short Decision Table

The set of network commands is small enough to memorise, but knowing which one to reach for first saves a round of guessing:

• Nothing answers at all — network ping from the node that owns the LIF, not from the cluster management address. Different nodes have different routing.
• Ping works, TCP does not — network tcpdump on the LIF. ICMP often succeeds on a path that drops the specific service port you care about.
• Slow rather than broken — run -node <node> ifstat -a and network test -path for intercluster. Look for retransmits, discards and CRC rather than bandwidth.
• Path is unclear — network traceroute, then network device-discovery show and the CDP neighbour listings to identify what sits at each hop.
• Wrong node or port — network interface show -fields is-home,curr-node,curr-port before anything else. A LIF that has failed over and not returned to its home port explains a surprising number of “the network changed” tickets.

For the configuration-layer counterpart to this diagnostic work, see ONTAP network configuration best practices, and for the wider picture of port states and counters, the ONTAP port troubleshooting guide pairs well with ONTAP performance monitoring commands.

More ONTAP Content on This Site

Continue with ONTAP 9 performance commands, ONTAP network configuration best practices, ONTAP SnapMirror guide, creating SVMs and data LIFs from the CLI and SnapMirror policy configuration.

原文链接：https://docs.netapp.com/us-en/ontap/networking/commands_for_diagnosing_network_problems.html