Introduction
Every network engineer has a core set of CLI commands they reach for daily — the ones burned into muscle memory from years of troubleshooting at 2 AM. Whether you are configuring a new deployment, diagnosing a production outage, or verifying changes during a maintenance window, these commands are your essential toolkit.
This article covers the top 10 networking CLI commands that every engineer should know, with examples from Cisco IOS, Cisco NX-OS, and Linux. For each command, we cover what it does, when to use it, the most useful variations, and how to interpret the output.
1. show ip interface brief (Cisco) / ip addr (Linux)
The first thing you check on any network device: what interfaces exist and are they up?
Cisco IOS
Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.1.1.1 YES NVRAM up up
GigabitEthernet0/1 10.1.2.1 YES NVRAM up up
Serial0/0/0 unassigned YES NVRAM administratively down down
Loopback0 1.1.1.1 YES NVRAM up up
Cisco NX-OS
Nexus# show ip interface brief vrf all
! Includes interfaces across all VRFs — critical in Nexus environments
Linux
$ ip addr show
# Or the shorter form:
$ ip a
# Filter for a specific interface:
$ ip addr show eth0
# Show only IPv4 addresses:
$ ip -4 addr
Pro tip: On Cisco, if Protocol is “down” but Status is “up,” you likely have a Layer 2 issue (encapsulation mismatch, keepalive failure). If both are “down,” it is a physical issue (cable, SFP, or the far end is shut down).
2. show running-config (Cisco) / cat config files (Linux)
You cannot troubleshoot what you do not understand. Always review the current running configuration before making changes.
Cisco IOS
! View the entire running configuration
Router# show running-config
! View a specific section
Router# show running-config | section interface
Router# show running-config | section router ospf
Router# show running-config | section line vty
! Compare running vs startup (saved) config
Router# show archive config differences system:running-config nvram:startup-config
! Filter for specific patterns
Router# show running-config | include ip route
Router# show running-config | begin interface GigabitEthernet0/0
Linux Networking Config
# Network interfaces (depends on distro)
$ cat /etc/network/interfaces # Debian/Ubuntu (ifupdown)
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 # RHEL/CentOS
$ nmcli connection show # NetworkManager
$ cat /etc/netplan/*.yaml # Ubuntu 18.04+ (Netplan)
# Current routing
$ ip route show
# DNS configuration
$ cat /etc/resolv.conf
# Firewall rules
$ iptables -L -n -v # iptables
$ nft list ruleset # nftables
Pro tip: On Cisco, always use show running-config | section instead of scrolling through the entire config. It saves time and helps you focus on the relevant part.
3. ping and traceroute
The most basic yet most powerful connectivity tests. Ping tests reachability; traceroute shows the path packets take to get there.
Cisco IOS
! Basic ping
Router# ping 10.1.2.1
! Extended ping (specify source, count, size, timeout)
Router# ping
Protocol [ip]: ip
Target IP address: 10.1.2.1
Repeat count [5]: 100
Datagram size [100]: 1500
Timeout in seconds [2]: 2
Extended commands [n]: y
Source address or interface: 10.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]: yes ! Test MTU path
...
! Traceroute
Router# traceroute 10.1.2.1
Router# traceroute 10.1.2.1 source 10.1.1.1
Linux
# Basic ping
$ ping -c 5 10.1.2.1
# Ping with specific source
$ ping -I eth0 10.1.2.1
# Ping with large packet (MTU test, DF bit set)
$ ping -M do -s 1472 10.1.2.1
# Traceroute
$ traceroute 10.1.2.1
# TCP traceroute (bypasses ICMP-blocking firewalls)
$ traceroute -T -p 443 10.1.2.1
# MTR (combined ping + traceroute, real-time)
$ mtr 10.1.2.1
Pro tip: On Linux, mtr is far superior to separate ping and traceroute commands. It continuously probes each hop, showing packet loss and latency at every point in the path. Install it with apt install mtr or yum install mtr.
4. show ip route (Cisco) / ip route show (Linux)
Understanding the routing table is fundamental to diagnosing “I can ping X but not Y” problems.
Cisco IOS
! Full routing table
Router# show ip route
! Filter by protocol
Router# show ip route ospf
Router# show ip route bgp
Router# show ip route static
Router# show ip route connected
! Check route to a specific destination
Router# show ip route 10.2.0.0
! Show routing table summary
Router# show ip route summary
Linux
# Full routing table
$ ip route show
# Check which route matches a specific destination
$ ip route get 10.2.0.1
# Show routing table for a specific table (policy routing)
$ ip route show table 100
# Show all routing tables
$ ip rule list
Pro tip: On Cisco, the show ip route [destination] command shows exactly which route the router will use for a specific destination, including the next hop and exit interface. This is faster than scanning the entire routing table.
5. show interface (Cisco) / ethtool (Linux)
When you suspect a Layer 1 or Layer 2 problem, the interface details tell the story: error counters, speed/duplex, input/output rates, and queue drops.
Cisco IOS
Router# show interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is iGbE, address is aabb.cc00.0100
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
...
5 minute input rate 145000 bits/sec, 12 packets/sec
5 minute output rate 230000 bits/sec, 18 packets/sec
1234567 packets input, 789012345 bytes
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
9876543 packets output, 654321098 bytes
0 output errors, 0 collisions, 0 interface resets
! Key things to check:
! - input errors / CRC errors = physical layer problem
! - output drops = congestion (QoS issue)
! - collisions = duplex mismatch
! - interface resets = flapping link
Linux
# Interface statistics
$ ip -s link show eth0
# Detailed NIC info (speed, duplex, driver)
$ ethtool eth0
# NIC error counters
$ ethtool -S eth0
# Check for interface errors
$ netstat -i
# Or:
$ cat /proc/net/dev
6. show arp / show mac address-table
ARP and MAC address tables help you trace where a device is physically connected and diagnose Layer 2 connectivity issues.
Cisco IOS (Router)
! Show ARP table (IP to MAC mapping)
Router# show arp
Router# show ip arp
! Find a specific IP
Router# show arp | include 10.1.1.50
! Clear a stale ARP entry
Router# clear arp-cache
Cisco IOS (Switch)
! Show MAC address table (MAC to port mapping)
Switch# show mac address-table
! Find which port a specific MAC is on
Switch# show mac address-table address aabb.cc00.0100
! Find which MAC addresses are on a specific port
Switch# show mac address-table interface GigabitEthernet1/0/5
! Find which MAC addresses are in a specific VLAN
Switch# show mac address-table vlan 100
Linux
# Show ARP table
$ ip neighbor show
# Or the legacy command:
$ arp -a
# Clear a specific ARP entry
$ ip neighbor del 10.1.1.50 dev eth0
# Flush all ARP entries on an interface
$ ip neighbor flush dev eth0
Pro tip: Combining show arp on the router and show mac address-table on the switch is the fastest way to trace a device. Find the MAC in the ARP table using the IP, then find which switch port the MAC is learned on.
7. show cdp neighbors / show lldp neighbors
Discovery protocols tell you what is connected to what — invaluable for mapping a network you did not build or verifying cable paths.
Cisco IOS
! CDP (Cisco Discovery Protocol) — Cisco devices only
Router# show cdp neighbors
Router# show cdp neighbors detail
! LLDP (Link Layer Discovery Protocol) — vendor neutral
Router# show lldp neighbors
Router# show lldp neighbors detail
! Enable LLDP if not already
Router(config)# lldp run
Linux
# Install and use lldpd
$ sudo apt install lldpd # Debian/Ubuntu
$ sudo yum install lldpd # RHEL/CentOS
# View LLDP neighbors
$ lldpcli show neighbors
# Or use tcpdump to capture CDP/LLDP frames
$ sudo tcpdump -nn -v -i eth0 -s 1500 'ether proto 0x88cc' -c 1
Pro tip: If you are troubleshooting cabling, CDP/LLDP output tells you exactly which switch and port the device is connected to without physically tracing cables. Always check CDP before assuming a cable is patched to the right place.
8. show log / logging (Cisco) / journalctl (Linux)
The device logs often contain the answer to your problem — interface flaps, authentication failures, protocol events, and hardware errors.
Cisco IOS
! Show the log buffer
Router# show logging
Router# show logging | include %LINK
Router# show logging | include error
! Enable timestamps for useful logs
Router(config)# service timestamps log datetime msec localtime
! Send logs to a syslog server
Router(config)# logging host 10.1.1.50
Router(config)# logging trap informational
! Show logs from a specific time range (if timestamps enabled)
Router# show logging | include Feb 26
Linux
# System journal (systemd-based systems)
$ journalctl -xe
$ journalctl -u NetworkManager
$ journalctl --since "1 hour ago"
$ journalctl -f # Follow/tail the log in real-time
# Traditional syslog
$ tail -f /var/log/syslog
$ tail -f /var/log/messages
$ grep -i "error\|fail\|down" /var/log/syslog | tail -50
# Kernel messages (network driver issues)
$ dmesg | grep -i "eth\|net\|link"
Pro tip: On Cisco, the %LINK-3-UPDOWN and %LINEPROTO-5-UPDOWN messages tell you exactly when interfaces flapped. Correlate these timestamps with user-reported problems to narrow down the cause.
9. nslookup / dig (DNS Troubleshooting)
DNS is involved in almost every network connectivity issue. When users say “the internet is down,” it is often a DNS problem.
Cisco IOS
! Check DNS configuration
Router# show running-config | include name-server
Router# show running-config | include ip domain
! Test DNS resolution
Router# ping google.com
! If this resolves to an IP, DNS works
! Verify DNS server reachability
Router# ping 8.8.8.8
Linux
# Quick DNS lookup
$ nslookup google.com
$ nslookup google.com 8.8.8.8 # Query a specific DNS server
# Detailed DNS query (preferred over nslookup)
$ dig google.com
$ dig google.com @8.8.8.8 # Query a specific server
$ dig google.com +short # Just show the answer
$ dig -x 142.250.80.46 # Reverse DNS lookup
$ dig google.com MX # Query MX records
$ dig google.com +trace # Trace the full DNS resolution path
# Check current DNS configuration
$ cat /etc/resolv.conf
$ resolvectl status # systemd-resolved
Pro tip: dig +trace is incredibly useful for diagnosing DNS resolution failures. It shows every step of the recursive lookup from root servers to the authoritative nameserver, making it easy to identify where the resolution breaks.
10. tcpdump / Wireshark (Packet Capture)
When all else fails, capture the actual packets. Packet captures do not lie — they show exactly what is happening on the wire.
Cisco IOS (Embedded Packet Capture)
! Define a capture buffer
Router# monitor capture MYCAP interface GigabitEthernet0/0 both
! Add a filter (optional)
Router# monitor capture MYCAP match ipv4 host 10.1.1.50 host 10.1.2.100
! Start capturing
Router# monitor capture MYCAP start
! Stop after collecting enough data
Router# monitor capture MYCAP stop
! View the capture
Router# show monitor capture MYCAP buffer brief
! Export to a file for Wireshark
Router# monitor capture MYCAP export flash:capture.pcap
Linux (tcpdump)
# Capture all traffic on eth0
$ sudo tcpdump -i eth0 -w /tmp/capture.pcap
# Capture with filters
$ sudo tcpdump -i eth0 host 10.1.1.50
$ sudo tcpdump -i eth0 port 443
$ sudo tcpdump -i eth0 'host 10.1.1.50 and port 80'
$ sudo tcpdump -i eth0 'src host 10.1.1.50 and dst port 22'
# Capture with useful display options
$ sudo tcpdump -i eth0 -nn -v host 10.1.1.50
# -nn = don't resolve hostnames or port names
# -v = verbose output
# Capture a specific number of packets
$ sudo tcpdump -i eth0 -c 100 -w /tmp/capture.pcap
# Read a capture file
$ tcpdump -r /tmp/capture.pcap -nn
# Capture only SYN packets (new TCP connections)
$ sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'
Pro tip: Always capture to a pcap file (-w) and analyze in Wireshark afterward, rather than trying to read raw packet output in the terminal. Wireshark’s protocol decoders and filtering capabilities make analysis significantly faster.
Bonus: Quick Network Testing One-Liners
| Task | Command |
|---|---|
| Test if a TCP port is open | nc -zv 10.1.1.50 443 (Linux) or telnet 10.1.1.50 443 (Cisco) |
| Check public IP | curl ifconfig.me (Linux) |
| Test HTTP response | curl -I https://example.com |
| Bandwidth test | iperf3 -c 10.1.1.50 (requires iperf3 on both ends) |
| Find your default gateway | ip route show default (Linux) or show ip route 0.0.0.0 (Cisco) |
| Check open ports on local machine | ss -tlnp (Linux) |
| See all TCP connections | ss -tnap (Linux) or netstat -an |
| Flush DNS cache | sudo systemd-resolve --flush-caches (Linux) |
| Scan a subnet for live hosts | nmap -sn 10.1.1.0/24 |
Related Resources on UnifiedGuru
- ESXi Network Troubleshooting Checklist
- vSphere 8 Networking Guide
- CUE Voicemail Configuration Guide
- All Networking Configuration Templates
Conclusion
These 10 commands (and their variations) cover the vast majority of network troubleshooting scenarios you will face. Master them on both Cisco and Linux platforms, and you will be able to diagnose most network issues quickly and methodically. The key is building a systematic approach: start at the physical layer, verify Layer 2, check Layer 3 routing, test end-to-end connectivity, and capture packets when the other steps do not reveal the problem.
Have a favorite CLI command or trick that did not make the list? Share it in our Routing and Switching forum — we would love to hear what commands you rely on most.