Linux Networking Tools Complete Guide

Yashrajsinh

·January 16, 2025·12 min read·Intermediate

Linux Networking Tools Complete Guide

Networking is the backbone of modern software systems. Every API call, database query, container communication, and cloud service interaction travels over a network. When a microservice cannot reach its database, when latency spikes in production, or when a deployment fails because a port is already in use, you need networking tools to diagnose and resolve the problem. Linux provides a comprehensive set of utilities for inspecting interfaces, analyzing traffic, testing connectivity, managing firewall rules, and debugging DNS resolution.

This guide covers the essential networking tools that every engineer needs when working with production systems. Whether you are debugging connectivity between Docker containers, configuring security groups on AWS EC2, setting up load balancers with CloudFront, or troubleshooting Jenkins build agents that cannot reach artifact repositories, these tools give you visibility into what is happening on the wire.

Concept Overview

Linux networking tools operate at different layers of the network stack, from physical interfaces through transport protocols to application-level HTTP. Understanding which tool to use at each layer enables systematic troubleshooting that isolates problems quickly instead of guessing at causes.

Step-by-Step Explanation

The sections below cover each networking tool category in order of the diagnostic workflow you would follow when investigating connectivity issues. Starting with interface inspection and progressing through connection analysis, DNS, and packet capture gives you a complete troubleshooting toolkit.

What You Will Learn

By completing this guide you will understand and be able to apply the following networking concepts and tools:

How to inspect and configure network interfaces using the ip command suite
How to analyze active connections, listening ports, and socket statistics with ss and netstat
How to test HTTP endpoints and APIs using curl with headers, authentication, and timing
How to diagnose DNS resolution issues using dig, nslookup, and host
How to capture and analyze network traffic with tcpdump for deep packet inspection
How to trace network paths and identify latency bottlenecks with traceroute and mtr
How to manage firewall rules with iptables and nftables for securing services
How to transfer files securely between systems using scp, rsync, and ssh tunnels
How to debug common networking problems systematically using a layered approach

These skills connect directly to container networking where overlay networks route traffic between services, to cloud infrastructure where security groups and NACLs control access, and to CI/CD pipelines where build agents need connectivity to registries and deployment targets.

Prerequisites

Before working through this guide, you should be comfortable with basic Linux commands including navigating the filesystem, reading files, using pipes, and running commands with elevated privileges via sudo. Understanding of processes and signals helps when you need to manage long-running network captures or background tunnels.

You should have access to a Linux system where you can install packages and run networking commands. Some tools like tcpdump and iptables require root privileges. A basic understanding of IP addresses, ports, and the client-server model is assumed, though this guide explains concepts as they arise. Having two machines or containers that can communicate with each other is helpful for practicing connection debugging.

Network Interface Inspection

The first step in any networking investigation is understanding what interfaces exist on your system, what addresses they have, and whether they are operational. The ip command suite has replaced the older ifconfig as the standard tool for interface management.

Viewing Interfaces and Addresses

Network interface and connection inspection reveals the current state of your system's network stack. These commands show IP addresses, active connections, listening ports, and routing information needed for connectivity diagnosis.

# Show all network interfaces with their addresses
ip addr show
 
# Show only IPv4 addresses in brief format
ip -4 addr show
 
# Show a specific interface
ip addr show dev eth0
 
# Show interface statistics (packets, bytes, errors)
ip -s link show
 
# Show only interfaces that are UP
ip link show up
 
# Show the routing table
ip route show
 
# Show the default gateway
ip route show default
 
# Show ARP/neighbor cache
ip neigh show
 
# Show which interface a destination would use
ip route get 8.8.8.8

Configuring Interfaces

While most production systems use DHCP or cloud-provided networking, understanding manual configuration helps when debugging or setting up test environments:

# Bring an interface up or down
sudo ip link set eth0 up
sudo ip link set eth0 down
 
# Add an IP address to an interface
sudo ip addr add 192.168.1.100/24 dev eth0
 
# Remove an IP address
sudo ip addr del 192.168.1.100/24 dev eth0
 
# Add a static route
sudo ip route add 10.0.0.0/8 via 192.168.1.1
 
# Add a default gateway
sudo ip route add default via 192.168.1.1
 
# Set MTU for an interface
sudo ip link set eth0 mtu 9000
 
# Create a virtual interface (useful for testing)
sudo ip link add veth0 type veth peer name veth1

Understanding Interface Output

When you run ip addr show, each interface entry contains critical information. The flags tell you the interface state: UP means administratively enabled, LOWER_UP means the physical link is active. The mtu value shows the maximum transmission unit. The inet line shows the IPv4 address with its subnet mask in CIDR notation. The link/ether line shows the MAC address. Understanding these fields helps you quickly identify misconfigured interfaces.

Connection Analysis with SS

The ss command (socket statistics) is the modern replacement for netstat. It provides fast, detailed information about network connections, listening ports, and socket states. This is your primary tool for answering questions like "what is listening on port 8080?" or "how many connections does my database have?"

Viewing Active Connections

# Show all TCP connections
ss -t
 
# Show all listening TCP sockets
ss -tln
 
# Show listening sockets with process information
ss -tlnp
 
# Show all UDP sockets
ss -uln
 
# Show connections to a specific port
ss -tn dport = :443
 
# Show connections from a specific source
ss -tn src 192.168.1.0/24
 
# Show connection states (ESTABLISHED, TIME-WAIT, etc.)
ss -t state established
 
# Show socket memory usage
ss -tm
 
# Show timer information (keepalive, retransmit)
ss -to
 
# Count connections by state
ss -t | awk '{print $1}' | sort | uniq -c | sort -rn
 
# Find which process is using a specific port
ss -tlnp | grep :3000

Diagnosing Connection Issues

Connection states tell you exactly where in the TCP lifecycle a connection sits. A large number of TIME_WAIT connections indicates a service that opens and closes many short-lived connections. SYN_SENT connections that never transition to ESTABLISHED suggest a firewall blocking the traffic or the remote host being unreachable. CLOSE_WAIT connections indicate your application is not properly closing sockets after the remote end disconnects.

# Count connections by state for a specific service
ss -tn state time-wait | wc -l
ss -tn state close-wait | wc -l
ss -tn state established dst :5432 | wc -l
 
# Show connections with detailed TCP info
ss -ti dst :8080
 
# Monitor connection count over time
watch -n 1 "ss -s"
 
# Find connections that have been in CLOSE_WAIT too long
ss -tn state close-wait | awk '{print $4}' | sort | uniq -c | sort -rn

HTTP Testing with Curl

Curl is the Swiss Army knife for testing HTTP endpoints. It supports every HTTP method, custom headers, authentication, cookies, file uploads, and detailed timing information. When you need to verify an API endpoint works correctly, test authentication flows, or measure response times, curl is your tool.

Basic HTTP Requests

HTTP testing with curl verifies that web services respond correctly to requests with specific headers, methods, and payloads. Advanced curl usage includes authentication, certificate handling, and performance timing for API debugging.

# Simple GET request
curl https://api.example.com/health
 
# GET with response headers displayed
curl -i https://api.example.com/users
 
# Only show response headers
curl -I https://api.example.com/users
 
# POST with JSON body
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "email": "[email protected]"}'
 
# PUT request with authentication
curl -X PUT https://api.example.com/users/123 \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice Updated"}'
 
# DELETE request
curl -X DELETE https://api.example.com/users/123 \
  -H "Authorization: Bearer $TOKEN"
 
# Follow redirects
curl -L https://example.com/old-path
 
# Save response to a file
curl -o response.json https://api.example.com/data
 
# Upload a file
curl -X POST https://api.example.com/upload \
  -F "file=@/path/to/document.pdf"

Advanced Curl Usage

# Detailed timing breakdown
curl -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
  -o /dev/null -s https://api.example.com/health
 
# Test with a specific DNS resolution (bypass DNS)
curl --resolve api.example.com:443:10.0.1.50 https://api.example.com/health
 
# Use a specific network interface
curl --interface eth1 https://api.example.com/health
 
# Set connection and request timeouts
curl --connect-timeout 5 --max-time 30 https://api.example.com/slow-endpoint
 
# Retry on failure
curl --retry 3 --retry-delay 2 https://api.example.com/flaky-endpoint
 
# Verbose output showing TLS handshake and headers
curl -v https://api.example.com/health
 
# Test HTTP/2
curl --http2 -v https://api.example.com/health
 
# Send multiple requests in parallel (curl 7.66+)
curl --parallel --parallel-max 10 \
  https://api.example.com/endpoint1 \
  https://api.example.com/endpoint2 \
  https://api.example.com/endpoint3

Timing Analysis

The timing breakdown from curl reveals exactly where latency occurs. If DNS lookup is slow, your resolver might be overloaded or the domain has a low TTL causing frequent lookups. If the connect time is high, there might be network congestion or the server is far away. If TLS handshake is slow, the server might be doing expensive certificate operations. If time to first byte is high after connection, the server is slow processing the request.

DNS Troubleshooting

DNS resolution failures are among the most common networking issues. When a service cannot resolve a hostname, everything that depends on it fails. Linux provides several tools for diagnosing DNS problems.

Using Dig for DNS Queries

DNS troubleshooting tools query name servers directly to verify resolution behavior independent of local caching. Understanding query types and response codes helps you distinguish between DNS configuration issues and network connectivity problems.

# Query A records for a domain
dig example.com
 
# Query specific record types
dig example.com MX
dig example.com AAAA
dig example.com TXT
dig example.com NS
 
# Query a specific DNS server
dig @8.8.8.8 example.com
 
# Short output format
dig +short example.com
 
# Trace the full resolution path
dig +trace example.com
 
# Reverse DNS lookup
dig -x 93.184.216.34
 
# Check CNAME chains
dig +short CNAME api.example.com
 
# Query with TCP instead of UDP (useful for large responses)
dig +tcp example.com
 
# Check SOA record for zone information
dig SOA example.com
 
# Verify DNSSEC
dig +dnssec example.com

Diagnosing DNS Issues

# Check which DNS servers your system uses
cat /etc/resolv.conf
 
# Check systemd-resolved status (modern systems)
resolvectl status
 
# Test resolution using the system resolver
getent hosts example.com
 
# Check /etc/hosts overrides
grep example.com /etc/hosts
 
# Measure DNS resolution time
dig example.com | grep "Query time"
 
# Check if a domain exists at all
dig +short NS example.com
 
# Flush DNS cache (systemd-resolved)
sudo resolvectl flush-caches
 
# Monitor DNS queries in real time
sudo tcpdump -i any port 53 -n

When DNS fails, work through these layers: First check /etc/resolv.conf to verify the configured nameservers are correct. Then test resolution against those nameservers directly with dig. If that works but application resolution fails, check /etc/nsswitch.conf to understand the resolution order. Check /etc/hosts for overrides. On systems using systemd-resolved, check resolvectl status for the active configuration.

Packet Capture with Tcpdump

Tcpdump captures network packets and displays or saves them for analysis. When you need to see exactly what data is flowing between systems, tcpdump provides ground truth. It is invaluable for debugging protocol issues, verifying encryption, and understanding application behavior.

Basic Packet Capture

Packet capture provides definitive evidence of what data is actually traversing the network, resolving disputes between application logs and network configuration. Targeted capture filters keep output manageable on busy interfaces.

# Capture all traffic on an interface
sudo tcpdump -i eth0
 
# Capture with human-readable timestamps
sudo tcpdump -i eth0 -tttt
 
# Capture traffic to/from a specific host
sudo tcpdump -i eth0 host 10.0.1.50
 
# Capture traffic on a specific port
sudo tcpdump -i eth0 port 443
 
# Capture only TCP SYN packets (new connections)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'
 
# Capture DNS traffic
sudo tcpdump -i eth0 port 53
 
# Capture and display packet contents in ASCII
sudo tcpdump -i eth0 -A port 80
 
# Capture and display in hex and ASCII
sudo tcpdump -i eth0 -X port 80
 
# Save capture to a file for later analysis
sudo tcpdump -i eth0 -w /tmp/capture.pcap port 8080
 
# Read a saved capture file
sudo tcpdump -r /tmp/capture.pcap
 
# Capture with a packet count limit
sudo tcpdump -i eth0 -c 100 port 443
 
# Capture with a size limit per packet (snap length)
sudo tcpdump -i eth0 -s 128 port 80

Advanced Filtering

Advanced techniques build on the fundamentals to handle complex scenarios that arise in production environments. These patterns combine multiple tools and options to solve problems that simpler approaches cannot address effectively.

Tcpdump uses Berkeley Packet Filter (BPF) syntax for powerful filtering. You can combine conditions with and, or, and not to capture exactly the traffic you need:

# Traffic between two specific hosts
sudo tcpdump -i eth0 host 10.0.1.50 and host 10.0.1.51
 
# Traffic on port 80 OR port 443
sudo tcpdump -i eth0 port 80 or port 443
 
# Traffic NOT from a specific host
sudo tcpdump -i eth0 not host 10.0.1.1
 
# Only incoming traffic to a specific port
sudo tcpdump -i eth0 dst port 8080
 
# TCP RST packets (connection resets)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'
 
# Packets larger than 1000 bytes
sudo tcpdump -i eth0 greater 1000
 
# HTTP GET requests (matching the ASCII pattern)
sudo tcpdump -i eth0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

Path Tracing and Latency

When connectivity works but is slow, you need to identify where in the network path the latency occurs. Traceroute and mtr show you every hop between your system and the destination.

Traceroute and MTR

Path tracing reveals the network hops between your system and a destination, identifying where latency or packet loss occurs. This information distinguishes between local network issues and problems at intermediate routers or the destination.

# Basic traceroute
traceroute example.com
 
# TCP traceroute (bypasses ICMP-blocking firewalls)
sudo traceroute -T -p 443 example.com
 
# UDP traceroute on a specific port
traceroute -U -p 33434 example.com
 
# Set maximum hops
traceroute -m 20 example.com
 
# MTR combines traceroute with continuous ping
mtr example.com
 
# MTR in report mode (run for 100 packets then exit)
mtr -r -c 100 example.com
 
# MTR with TCP
mtr --tcp -P 443 example.com
 
# MTR showing AS numbers (useful for identifying ISPs)
mtr -z example.com

Interpreting Results

Each hop in a traceroute shows the router at that point in the path and the round-trip time to reach it. Look for sudden jumps in latency between consecutive hops, which indicate a slow link. Consistent packet loss at a specific hop suggests congestion or a failing router. If the final destination shows high latency but intermediate hops are fast, the problem is at the destination server itself.

Stars (* * *) in traceroute output mean that hop did not respond to probes. This does not necessarily indicate a problem since many routers are configured to not respond to traceroute probes while still forwarding traffic normally. Only worry about stars if they correlate with actual connectivity issues.

Firewall Management

Firewalls control which network traffic is allowed to reach your services. On Linux, iptables (and its successor nftables) provides packet filtering at the kernel level. Understanding firewall rules is essential when services are unreachable despite being correctly configured.

Viewing and Managing Rules

Service lifecycle management commands let you start, stop, restart, and inspect services. Understanding the state machine behind these transitions helps you diagnose startup failures and dependency ordering issues. Proper rule management prevents accidental lockouts and ensures consistent security policy enforcement across server reboots.

# List all iptables rules with line numbers
sudo iptables -L -n --line-numbers
 
# List rules for a specific chain
sudo iptables -L INPUT -n --line-numbers
 
# List rules in the NAT table
sudo iptables -t nat -L -n
 
# Show rules with packet/byte counters
sudo iptables -L -n -v
 
# Allow incoming TCP traffic on port 8080
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
 
# Allow traffic from a specific subnet
sudo iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
 
# Block traffic from a specific IP
sudo iptables -A INPUT -s 192.168.1.100 -j DROP
 
# Delete a rule by line number
sudo iptables -D INPUT 3
 
# Allow established and related connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Log dropped packets for debugging
sudo iptables -A INPUT -j LOG --log-prefix "DROPPED: " --log-level 4
 
# Save current rules
sudo iptables-save > /etc/iptables/rules.v4
 
# Restore saved rules
sudo iptables-restore < /etc/iptables/rules.v4
 
# Flush all rules (careful in production!)
sudo iptables -F

Debugging Firewall Issues

When a service is unreachable, systematically check firewall rules at each layer. On cloud platforms like AWS, you have security groups and NACLs in addition to host-level firewalls. Check from the outside in: cloud firewall rules first, then host iptables, then application binding.

# Check if a port is open from the local machine
ss -tln | grep :8080
 
# Test connectivity from another machine
nc -zv target-host 8080
 
# Check if iptables is blocking traffic
sudo iptables -L INPUT -n -v | grep 8080
 
# Watch the iptables counters increment
watch -n 1 "sudo iptables -L INPUT -n -v"
 
# Temporarily insert an allow rule at the top for testing
sudo iptables -I INPUT 1 -p tcp --dport 8080 -j ACCEPT

Secure File Transfer and Tunneling

Secure file transfer and tunneling tools provide encrypted communication channels for moving data between systems and accessing remote services. These tools are fundamental to secure operations workflows and remote administration.

Moving files between systems and creating secure tunnels for accessing remote services are daily tasks for engineers managing distributed systems.

SCP and Rsync

# Copy a file to a remote system
scp local-file.tar.gz user@remote:/tmp/
 
# Copy a directory recursively
scp -r ./deploy/ user@remote:/opt/app/
 
# Copy from remote to local
scp user@remote:/var/log/app.log ./
 
# Rsync for efficient incremental transfers
rsync -avz ./build/ user@remote:/opt/app/build/
 
# Rsync with delete (mirror source to destination)
rsync -avz --delete ./deploy/ user@remote:/opt/app/
 
# Rsync over a specific SSH port
rsync -avz -e "ssh -p 2222" ./files/ user@remote:/data/
 
# Rsync with bandwidth limit (in KB/s)
rsync -avz --bwlimit=1000 ./large-file user@remote:/tmp/
 
# Rsync with progress display
rsync -avz --progress ./backup.tar.gz user@remote:/backups/

SSH Tunneling

SSH tunnels let you securely access remote services that are not directly reachable. This is essential for accessing databases, admin panels, and internal services in private networks:

# Local port forwarding: access remote service through local port
# Access remote PostgreSQL (port 5432) via localhost:15432
ssh -L 15432:localhost:5432 user@bastion-host
 
# Access a service on a private network through a jump host
ssh -L 8080:internal-service:80 user@bastion-host
 
# Remote port forwarding: expose local service to remote
ssh -R 9090:localhost:3000 user@remote-host
 
# Dynamic SOCKS proxy (route all traffic through remote)
ssh -D 1080 user@remote-host
 
# SSH tunnel in the background
ssh -fN -L 15432:db-host:5432 user@bastion
 
# Jump host (ProxyJump) for multi-hop access
ssh -J user@bastion user@internal-host
 
# Test if a tunnel is working
curl -s http://localhost:8080/health

Systematic Troubleshooting Approach

Systematic troubleshooting follows a diagnostic workflow that narrows the problem space efficiently. Starting with service status and journal output before examining configuration and dependencies resolves most issues quickly.

When facing a networking issue, work through the network stack systematically from bottom to top. This layered approach prevents you from chasing symptoms instead of root causes.

Layer-by-Layer Diagnosis

The following commands and techniques demonstrate practical usage patterns for this category. Each example includes commonly used flags and options that you will encounter in daily development and operations workflows.

Start at the physical and link layer: Is the interface up? Does it have an IP address? Can you reach the local gateway?

# Layer 1-2: Interface and link status
ip link show
ip addr show
 
# Layer 3: IP connectivity to gateway
ping -c 3 $(ip route show default | awk '{print $3}')
 
# Layer 3: IP connectivity to destination
ping -c 3 target-host
 
# Layer 4: TCP connectivity to service port
nc -zv target-host 443
# or
curl --connect-timeout 5 https://target-host/health
 
# DNS: Name resolution
dig target-host
getent hosts target-host
 
# Application: Service responding correctly
curl -i https://target-host/api/status

Common Scenarios and Solutions

Connection refused means the port is reachable but nothing is listening. Check if the service is running and bound to the correct interface. Connection timed out means packets are being dropped, likely by a firewall. Check security groups, iptables, and network ACLs. Name resolution failed means DNS is misconfigured. Check resolv.conf and test with dig against known-good nameservers.

When debugging intermittent issues, use continuous monitoring tools. Run mtr for ongoing path analysis, use ss with watch to track connection states over time, and capture packets with tcpdump during the failure window for post-mortem analysis.

Best Practices

Follow these guidelines for effective network troubleshooting and management:

Always start diagnosis at the lowest network layer and work up. Verify physical connectivity before debugging application protocols. This prevents wasting time on application configuration when the problem is a disconnected cable or misconfigured interface.
Use ss instead of netstat on modern systems. It is faster, provides more information, and supports filtering syntax that makes complex queries simple.
When using tcpdump in production, always set a packet count limit or file size rotation. Unbounded captures fill disks and can cause outages worse than the original problem.
Test firewall changes incrementally. Add one rule at a time and verify it works before adding the next. Keep a backup of working rules and know how to restore them quickly.
Use curl's timing output to identify which phase of a request is slow. This immediately narrows the investigation to DNS, network, TLS, or application processing.
Document your network topology including IP ranges, DNS servers, firewall rules, and service ports. When an incident occurs at 3 AM, having this documentation saves critical minutes.
Prefer SSH tunnels over exposing services directly to the internet. Tunnels provide encryption, authentication, and access control without modifying firewall rules or service configuration.
When debugging container networking, remember that containers have their own network namespaces. Use nsenter or docker exec to run networking tools from inside the container's network context.

Real-World Use Cases

DevOps engineers use these networking tools daily to diagnose deployment failures, verify service connectivity, and validate firewall rules. When a microservice cannot reach its database, systematic use of ss, curl, and tcpdump pinpoints whether the issue is DNS resolution, network routing, or application-level authentication.

Common Mistakes

Running tcpdump without proper filters on a busy server generates overwhelming output that obscures the packets you need to see. Forgetting that iptables rules are evaluated in order causes new rules to be shadowed by earlier matches. Using ping to test connectivity to services that block ICMP leads to false conclusions about network reachability.

Summary

Linux networking tools give you complete visibility into how your systems communicate. From inspecting interfaces with ip to analyzing connections with ss, testing endpoints with curl, diagnosing DNS with dig, capturing traffic with tcpdump, and managing firewalls with iptables, each tool addresses a specific layer of the networking stack. Combined together, they form a systematic troubleshooting methodology that can diagnose any connectivity issue.

These skills are essential when working with Docker container networking, configuring AWS VPC security groups, managing systemd services that bind to network ports, and writing shell scripts that automate network operations. The layered diagnostic approach works whether you are debugging a local development environment or a distributed production system spanning multiple availability zones. Master these tools and you will resolve networking issues faster and with greater confidence.

Intermediate11 min read

Related Articles

Linux Shell Scripting Complete Guide

Linux Systemd Services Complete Guide

Linux Commands for Developers