Offensive Security Researcher & Quantum Cryptography Analyst

Network tools to manage TCP/IP and Fibre Channel networks

Abdul Wahab Junaid
Network tools to manage TCP/IP and Fibre Channel networks

Photo by Andrea Piacquadio on Pexels.com

Over the years I have built a personal toolkit of commands and platforms I reach for constantly when managing storage networks, whether that is a pure IP-based iSCSI/NAS environment or a Fibre Channel SAN. Knowing the right tool for the right job — and knowing it well enough to use under pressure during an outage — is a skill that separates a good storage admin from a great one. This article catalogs the essential tools for both TCP/IP and Fibre Channel network management, with practical usage examples.

TCP/IP Network Management Tools

1. ping and ping with DF (Don’t Fragment) flag

The most basic tool, but still one of the most useful, especially when combined with the “don’t fragment” flag for MTU path testing.

# Basic reachability test
ping 10.10.20.50

# MTU path discovery (Linux)
ping -M do -s 8972 10.10.20.50

# MTU path discovery (Windows)
ping -f -l 8972 10.10.20.50

2. traceroute / tracert / mtr

Used to map the path packets take and identify where latency or loss is introduced.

# Linux
traceroute 10.10.20.50

# Windows
tracert 10.10.20.50

# mtr combines ping and traceroute into continuous, real-time path monitoring
mtr 10.10.20.50

mtr is particularly valuable during active troubleshooting because it continuously re-tests every hop, making intermittent packet loss at a specific hop much easier to spot than a single traceroute snapshot.

3. netstat / ss

Used to inspect active connections, listening ports, and socket states — essential when diagnosing iSCSI session issues or verifying a storage service is actually listening.

# Linux (ss is the modern replacement for netstat)
ss -tunap | grep 3260   # iSCSI target port

# Windows
netstat -an | findstr 3260

4. tcpdump / Wireshark

Packet capture tools for deep protocol-level analysis — essential for diagnosing TCP retransmissions, iSCSI login failures, NFS RPC errors, or SMB negotiation problems.

# Capture traffic to/from a specific storage array, write to file for analysis
tcpdump -i eth0 host 10.10.20.50 -w storage_capture.pcap

# Filter for iSCSI traffic specifically
tcpdump -i eth0 port 3260 -w iscsi_capture.pcap

Wireshark is then used to open the capture file for deep inspection, with filters like tcp.analysis.retransmission, iscsi, or nfs to isolate protocol-specific issues.

5. iperf3

The standard tool for raw network throughput testing, independent of any storage protocol — critical for isolating whether a performance problem is network-layer or storage-layer.

# Server side (run near the storage array or on the array's subnet)
iperf3 -s

# Client side (run from the host)
iperf3 -c 10.10.20.50 -t 30 -P 4 -i 5

6. ethtool

Used on Linux to inspect and configure NIC-level settings — link speed, duplex, offload settings, ring buffer sizes.

# Check current link status
ethtool eth0

# Check and adjust ring buffer size (useful for high-throughput storage NICs)
ethtool -g eth0
ethtool -G eth0 rx 4096 tx 4096

# Check offload settings (TSO, GSO, checksum offload)
ethtool -k eth0

7. nslookup / dig

DNS resolution verification tools, critical for AD-integrated NAS environments where Kerberos authentication depends on consistent forward and reverse DNS.

nslookup nasfiler01.corp.local
dig -x 10.10.30.20   # reverse lookup

8. SNMP Tools (snmpget, snmpwalk)

Used for polling storage devices and network equipment for monitoring metrics when a full monitoring platform is not available or for quick ad-hoc checks.

snmpwalk -v2c -c public 10.10.10.50 1.3.6.1.2.1.2.2.1.10
# Walks interface input octet counters for trending throughput manually

9. Network Configuration and Management Platforms

Fibre Channel Network Management Tools

1. Switch CLI Tools (Cisco MDS NX-OS, Brocade Fabric OS)

These are the primary day-to-day tools for FC fabric management.

# Cisco MDS - core diagnostic commands
show flogi database
show fcns database
show zoneset active vsan 10
show interface fc1/1 counters
show interface fc1/1 transceiver

# Brocade Fabric OS equivalents
switchshow
nsshow
zoneshow
portshow fc1/1
sfpshow fc1/1

2. Fabric Management Platforms

These platforms are essential once a fabric grows beyond a handful of switches, since manually correlating FLOGI/zoning state across many individual switch CLIs does not scale.

3. Host-Side FC Diagnostic Tools

# Linux - check FC host adapter status directly from sysfs
cat /sys/class/fc_host/host0/port_state
cat /sys/class/fc_host/host0/port_name
cat /sys/class/fc_host/host0/speed

# systool provides a more structured view of FC host attributes
systool -c fc_host -v

# HBA vendor-specific management tools
# Emulex: HBAnyware / OneCommand Manager
# QLogic: QConvergeConsole (QCC)

4. Multipathing Management Tools

# Linux native multipathing (DM-Multipath)
multipath -ll
multipathd show paths
multipathd show maps

# Check multipath configuration
cat /etc/multipath.conf

Vendor-specific multipathing software (e.g., PowerPath from Dell EMC, or vendor DSMs on Windows) provides equivalent path status and failover management, often with additional array-aware load balancing logic beyond generic DM-Multipath.

5. Fibre Channel Analyzers

For deep protocol-level FC troubleshooting beyond what switch counters provide, dedicated FC protocol analyzers (hardware taps or switch-integrated features like Cisco’s fcanalyzer) capture and decode FC frame exchanges — used relatively rarely, typically reserved for very persistent or vendor-escalated issues.

# Cisco MDS built-in frame analyzer
fcanalyzer local interface fc1/1

6. Zoning and LUN Masking Management Tools

Comparison of Tool Categories

CategoryTCP/IP ToolsFibre Channel Tools
Basic connectivityping, tracerouteshow flogi database, switchshow
Path/topology mappingmtr, tracerouteshow fcns database, Nexus Dashboard Fabric Controller
Performance testingiperf3Switch port counters, fcanalyzer
Packet/frame analysistcpdump, Wiresharkfcanalyzer, hardware FC analyzers
Interface configurationethtoolSwitch CLI (interface fc1/1 config)
Centralized managementSolarWinds, Grafana/PrometheusSANnav, Nexus Dashboard Fabric Controller
Host-side path managementN/A (routing table, NIC teaming)multipath -ll, PowerPath, HBA vendor tools

Practical Combined Workflow Example

A real troubleshooting session combining both toolsets — diagnosing an NFS datastore performance issue that turned out to involve both an underlying FC-attached backend array and an IP-based NFS front end (a common architecture where NAS heads present file protocols over IP but sit on FC-attached back-end storage):

# Step 1: Confirm raw IP path health between NFS client and NAS head
ping -M do -s 8972 10.10.30.20
iperf3 -c 10.10.30.20 -t 30

# Step 2: Confirm NFS mount options and current I/O stats
mount | grep nfs
nfsstat -c

# Step 3: Confirm NAS head's back-end FC connectivity to the array is healthy
# (run on the NAS head itself, or via array-side switch CLI)
show flogi database
show interface fc1/1 counters

# Step 4: Correlate array-side performance metrics via vendor monitoring
# platform for the relevant time window

This kind of cross-layer diagnostic workflow is exactly why storage administrators benefit from being comfortable in both toolsets rather than treating IP networking and FC networking as entirely separate disciplines.

Automating Routine Diagnostics

Once you have used the same handful of commands manually for the tenth time during an incident, it is worth scripting them into a quick health-check that can be run on demand or scheduled. A simple example that pulls together several of the tools above into one pass:

#!/bin/bash
# Quick storage network health check
echo "=== NIC Status ==="
ethtool eth0 | grep -E "Speed|Duplex|Link detected"

echo "=== MTU path test ==="
ping -M do -s 8972 -c 3 10.10.20.50

echo "=== Multipath status ==="
multipath -ll

echo "=== FC host status (if present) ==="
for host in /sys/class/fc_host/host*; do
  echo "$host: $(cat $host/port_state 2>/dev/null)"
done

echo "=== Active iSCSI sessions ==="
iscsiadm -m session 2>/dev/null

Running a script like this before and after any maintenance window gives you a quick before/after comparison, and having it ready before an incident means you are not typing commands from memory while under pressure.

Choosing the Right Tool for the Situation

A quick mental model I use when deciding where to start troubleshooting:

Common Mistakes

  1. Relying only on switch-level dashboards without ever using host-side tools (ethtool, multipath -ll, systool) to confirm the host’s own view of connectivity.
  2. Not having packet capture tools readily available/pre-approved before an incident — scrambling to get tcpdump/Wireshark access during a live outage wastes valuable time.
  3. Using default SNMP community strings in production (public/private) as a long-term monitoring solution, which is a real security risk, not just a lab-testing shortcut.
  4. Ignoring vendor-specific multipathing tools (PowerPath, HBA vendor utilities) in favor of only generic OS tools, missing array-aware optimizations those tools provide.
  5. Not keeping a documented baseline of normal show interface counters or iperf3 throughput values, making it hard to tell “abnormal” from “normal” during an actual incident.

FAQs

Q: Do I need to learn both Cisco MDS and Brocade CLI syntax? If your environment has both switch families (common after mergers/acquisitions or multi-vendor procurement policies), yes — the underlying FC concepts are identical, but command syntax differs meaningfully between NX-OS and Fabric OS.

Q: Is Wireshark safe to use in a production storage network? Yes, when used correctly — passive packet capture on a mirrored/SPAN port does not affect production traffic. Capturing directly inline or on a heavily loaded production interface should be done cautiously and briefly.

Q: What is the single most useful tool for a new storage administrator to learn first? multipath -ll (or the vendor equivalent) and basic switch CLI status commands (show flogi database, switchshow) — together these cover the majority of “why can’t my host see storage” questions.

Keeping a Personal Toolkit Reference

I keep a short reference card of the commands I use most often taped, figuratively, to the inside of my troubleshooting brain — and literally saved as a quick-access note. It is worth building your own version tailored to your environment’s specific switch vendors and OS mix, since command syntax differences between Cisco, Brocade, Linux, and Windows are exactly the kind of thing that is easy to blank on during a stressful incident. Even experienced engineers benefit from having show flogi database vs. switchshow, or ss -tunap vs. netstat -an, written down somewhere fast to find rather than relying purely on memory at 3 a.m.

Summary

Managing TCP/IP and Fibre Channel storage networks well requires fluency across a fairly compact but essential toolkit: basic connectivity tools (ping, traceroute), performance tools (iperf3, switch counters), deep packet/frame analyzers (Wireshark, fcanalyzer), and both host-side and switch-side status commands. The real skill is not memorizing every command, but knowing which layer to check first and which tool answers that specific question fastest — that instinct is what turns a multi-hour outage into a fifteen-minute fix.

References

Exit mobile version