Linux Network Tools Guide: Commands for Network Troubleshooting

Linux provides one of the richest command-line environments for understanding, configuring, and troubleshooting computer networks.

A Linux administrator can inspect interfaces, IP addresses, routes, neighboring devices, sockets, DNS behavior, application connectivity, packet flows, Ethernet statistics, and network services without relying on a graphical interface.

The most important Linux network tools include:

• ip
• ss
• ping
• traceroute
• mtr
• dig
• resolvectl
• curl
• nc
• tcpdump
• nmcli
• ethtool

These tools do not all solve the same problem. Each answers a different question at a different layer of the networking stack.

For example:

Application
    |
   curl
    |
TCP / UDP
    |
 ss / nc
    |
    IP
    |
ip / route
    |
Ethernet
    |
ethtool / tcpdump

Effective Linux network troubleshooting is therefore not about memorizing hundreds of commands.

A better methodology is:

Question
   ↓
Choose the correct layer
   ↓
Choose the correct tool
   ↓
Collect evidence
   ↓
Interpret the result
   ↓
Test a hypothesis

Linux networking is closely connected to the concepts explained in Computer Networking Explained and TCP/IP Explained. If routing, IP addressing, TCP, UDP, or DNS are still unfamiliar, those guides provide useful foundations.

1. Linux Network Tools at a Glance

A useful way to organize Linux network utilities is by purpose.

No single command replaces the others.

The original guide makes this distinction early and repeatedly: the right tool depends on the layer being investigated. Pasted text

2. A Layered Linux Network Troubleshooting Method

A reliable troubleshooting workflow starts at the lowest practical layer and moves upward.

Interface
   ↓
IP Address
   ↓
Routing
   ↓
Neighbor
   ↓
Reachability
   ↓
Network Path
   ↓
Transport / Port
   ↓
DNS
   ↓
Application
   ↓
Packets
   ↓
NIC / Driver

A practical mapping is:

This is much more efficient than restarting services or changing firewall rules without evidence.

3. The ip Command

The modern ip command is one of the most important tools in Linux networking.

It belongs to the iproute2 toolset and is used to inspect and manipulate networking objects such as:

ip link
ip addr
ip route
ip neigh
ip rule
ip -s

Think of ip as the command that answers:

What does the Linux kernel currently believe about this machine’s network configuration?

For detailed syntax, the Linux ip manual is available through man7.org.

4. Inspect Network Interfaces with ip link

Start with:

ip link

Example:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    mtu 1500
    state UP

Important fields include:

• Interface name
• Interface index
• MTU
• MAC address
• Administrative state
• Lower-layer link state

A critical distinction is:

UP

does not necessarily mean:

Physical or lower-layer connectivity is working

On physical interfaces, LOWER_UP can provide additional evidence about the lower-layer link.

For a compact list:

ip -br link

5. Inspect IP Addresses with ip addr

Use:

ip addr

For a more compact display:

ip -br addr

Example:

lo        UNKNOWN    127.0.0.1/8
eth0      UP         192.168.10.20/24

This immediately tells you:

• Interface
• Interface state
• Address
• Prefix length

Before investigating DNS, HTTP, or remote servers, first verify that the machine actually has the expected address.

6. Inspect IPv4 and IPv6 Separately

To view IPv4:

ip -4 addr

For IPv6:

ip -6 addr

A dual-stack interface may contain both:

IPv4: 192.168.10.20/24
IPv6: 2001:db8:1234::20/64

This distinction matters because an application may attempt IPv6 even when the administrator is only testing IPv4.

Never automatically assume:

IPv4 works
=
All network connectivity works

Modern troubleshooting should consider both address families when both are configured.

7. Inspect Interface Statistics

Use:

ip -s link

For more detailed statistics on one interface:

ip -s -s link show dev eth0

Typical counters include:

RX

• Bytes
• Packets
• Errors
• Dropped packets
• Overruns
• Multicast

TX

• Bytes
• Packets
• Errors
• Drops
• Carrier errors
• Collisions

Suppose:

RX errors = 0
TX errors = 0

but:

RX dropped = increasing rapidly

That creates a different troubleshooting direction.

Possible areas include:

• NIC buffers
• Kernel receive path
• Driver behavior
• Traffic overload
• Packet filtering
• Virtualization

This is why network troubleshooting should not focus only on CPU and RAM. The original article emphasizes that interface counters can provide the first useful clue. Pasted text

8. Linux Routing with ip route

Display the routing table:

ip route

Example:

default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20

This tells you:

Default gateway:
192.168.10.1

Connected network:
192.168.10.0/24

Interface:
eth0

Source address:
192.168.10.20

Query the Exact Route to a Destination

One of the most useful commands is:

ip route get 8.8.8.8

Example:

8.8.8.8 via 192.168.10.1 dev eth0 src 192.168.10.20

This answers a practical question:

Which gateway, interface, and source IP will Linux actually use?

If a server cannot reach:

10.50.20.30

run:

ip route get 10.50.20.30

You might see:

unreachable 10.50.20.30

or:

10.50.20.30 via 10.0.0.1 dev eth0

This can quickly distinguish a local routing problem from problems farther along the network.

For the theory behind route selection, see TCP/IP Explained.

9. Neighbor Discovery with ip neigh

Run:

ip neigh

For IPv4, this commonly exposes ARP-related neighbor information.

For IPv6, the equivalent mechanism uses Neighbor Discovery.

Example:

192.168.10.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Possible states include:

REACHABLE
STALE
DELAY
PROBE
FAILED

Suppose:

ping 192.168.10.1

fails.

Check:

ip neigh show 192.168.10.1

If the neighbor state becomes:

FAILED

the investigation may move toward:

• Wrong subnet
• VLAN configuration
• Switch port
• ARP filtering
• Layer-2 connectivity
• Local firewall

This can be much more useful than repeatedly running ping.

10. Socket Inspection with ss

The ss command is used to inspect Linux sockets and connections.

Basic command:

ss

A common listener check is:

ss -tuln

Options:

-t = TCP
-u = UDP
-l = listening
-n = numeric

Example:

LISTEN 0 4096 0.0.0.0:22
LISTEN 0 4096 0.0.0.0:80
LISTEN 0 4096 127.0.0.1:3306

This could mean:

SSH   → listening on all IPv4 interfaces
HTTP  → listening on all IPv4 interfaces
MySQL → listening only on loopback

Find Which Process Owns a Port

Use:

sudo ss -ltnp

Or:

sudo ss -ltnp | grep ':80'

You might see:

users:(("nginx",pid=1234,fd=6))

This gives you:

Port
 ↓
Socket
 ↓
Process

Never assume a service is listening simply because a process appears to be running.

Verify the socket.

Inspect Established Connections

Run:

ss -tn

or:

ss -tp

This can reveal:

• Local address
• Remote address
• Local port
• Remote port
• TCP state
• Process information

Useful TCP states include:

LISTEN
SYN-SENT
SYN-RECV
ESTAB
FIN-WAIT-1
FIN-WAIT-2
TIME-WAIT
CLOSE-WAIT
LAST-ACK

Large numbers of CLOSE-WAIT may indicate applications that are not closing sockets properly.

Large numbers of TIME-WAIT can occur in workloads with many short-lived TCP connections.

Interpretation always depends on the application.

11. Testing Reachability with ping

Basic test:

ping 192.168.10.1

Use a fixed number of probes:

ping -c 4 192.168.10.1

IPv4:

ping -4 example.com

IPv6:

ping -6 example.com

What Does a Successful Ping Prove?

It proves that an ICMP Echo Request/Reply exchange occurred.

It does not prove that:

• TCP/443 works
• HTTP works
• DNS works
• The application works
• Authentication works

Therefore:

Ping success
≠
Application success

Likewise:

Ping failure
≠
Complete network failure

ICMP may simply be filtered.

Check Packet Loss

Run:

ping -c 20 1.1.1.1

If the result shows:

20 packets transmitted
19 received
5% packet loss

you now have evidence of end-to-end loss during the test.

The next question is:

Where does that loss occur?

That is where mtr, traceroute, tcpdump, and interface statistics become useful.

12. Path Analysis with traceroute

Use:

traceroute example.com

Example:

1  192.168.1.1
2  10.10.0.1
3  203.0.113.1
4  198.51.100.1
5  example.com

traceroute helps identify path boundaries and intermediate hops.

However, it is not a perfect representation of every application packet.

Results may be affected by:

• ECMP
• Asymmetric routing
• ICMP filtering
• Rate limiting
• Control-plane behavior
• Different probe types

Treat traceroute as evidence, not absolute truth.

TCP or ICMP Probes

Depending on your implementation:

traceroute -T example.com

or:

traceroute -I example.com

can help when the default probes are filtered.

This is especially useful when the actual application uses TCP.

13. Continuous Path Diagnostics with mtr

mtr combines traceroute-style path discovery with repeated latency measurements.

Interactive mode:

mtr example.com

Report mode:

mtr -rw example.com

TCP mode:

mtr --tcp --port 443 example.com

A report can show:

• Hop
• Response behavior
• Latency
• Loss percentage
• Variation

Interpret Intermediate Loss Carefully

Suppose:

Hop 3:  0% loss
Hop 4: 35% loss
Hop 5:  0% loss
Destination: 0%

Do not immediately conclude that hop 4 is dropping 35% of production traffic.

Some routers rate-limit or deprioritize diagnostic replies.

The key question is whether the loss continues to subsequent hops and the final destination.

This caution appears explicitly in the original guide and is important for avoiding false diagnoses. Pasted text

14. DNS Troubleshooting with dig

dig is one of the most useful tools for DNS diagnosis.

Basic query:

dig example.com

Query A records:

dig example.com A

IPv6:

dig example.com AAAA

Mail:

dig example.com MX

Nameservers:

dig example.com NS

For deeper DNS concepts, see DNS Explained.

Query a Specific DNS Server

Use:

dig @1.1.1.1 example.com

or:

dig @8.8.8.8 example.com

Internal DNS:

dig @10.0.0.53 internal.example.com

This is particularly useful because it can separate:

Local resolver problem

from:

DNS data or upstream resolver problem

Inspect DNS Responses

Useful fields include:

status: NOERROR
ANSWER: 1
Query time: 21 msec
SERVER: 10.0.0.53#53

These answer:

• Did the DNS server answer?
• Which DNS server answered?
• How quickly?
• Was an answer returned?

Compact Output

dig +short example.com

Example:

203.0.113.25

This is convenient for:

• Scripts
• Monitoring
• Automation
• Quick checks

Reverse DNS

dig -x 203.0.113.25

This performs a PTR lookup.

Authoritative DNS Troubleshooting

First:

dig example.com NS

Then query an authoritative server directly:

dig @ns1.example.net example.com A

You can now compare:

Recursive resolver
vs.
Authoritative DNS server

15. Inspect the Local Resolver with resolvectl

On systems using systemd-resolved:

resolvectl status

and:

resolvectl query example.com

This is useful when:

dig works
but applications do not

or when you need to understand:

• Which DNS server is configured?
• Which interface owns the DNS configuration?
• Is split DNS being used?

The role of systemd-resolved depends on the Linux distribution and configuration.

16. Test HTTP, HTTPS, and APIs with curl

curl moves troubleshooting into the application layer.

Basic request:

curl https://example.com

Headers only:

curl -I https://example.com

Verbose mode:

curl -v https://example.com

The official project documentation is available at curl.se/docs.

Why curl -v Is So Useful

Verbose output can expose:

DNS resolution
      ↓
TCP connection
      ↓
TLS negotiation
      ↓
HTTP request
      ↓
HTTP response

This makes curl an extremely useful end-to-end diagnostic tool.

HTTP Status Codes

Run:

curl -I https://example.com

Possible results include:

200 OK
301 Moved Permanently
302 Found
403 Forbidden
404 Not Found
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable

If:

curl connects successfully

but the result is:

503 Service Unavailable

network connectivity may be functioning while the upstream application has a problem.

Test a Virtual Host or Reverse Proxy

curl -H 'Host: app.example.com' http://192.0.2.10

This is useful with:

• Nginx
• Apache
• Reverse proxies
• Load balancers
• Virtual hosts

Inspect TLS Behavior

curl -Iv https://example.com

This can expose:

• TLS version
• Certificate information
• Hostname behavior
• Cipher negotiation
• HTTP response

It is not a complete TLS security audit, but it is an excellent troubleshooting step.

For related security concepts, see Network Security Basics and Firewalls Explained.

17. Test TCP Ports with nc

nc, commonly called Netcat, is useful for testing network connections.

Test HTTPS connectivity:

nc -vz example.com 443

This answers:

Can I establish a TCP connection to port 443?

It does not answer:

Does HTTPS work correctly?

For that, use:

curl -Iv https://example.com

Local Port Test

nc -vz 127.0.0.1 8080

Remote Port Test

nc -vz 192.0.2.10 443

A useful combination is:

ss
↓
Is the server listening?

nc
↓
Can the client connect?

tcpdump
↓
Are packets arriving?

UDP Requires More Care

Example:

nc -vzu 192.0.2.10 53

UDP is connectionless, so an apparent “success” does not provide the same certainty as a completed TCP connection.

For UDP, combine:

• Packet capture
• Server logs
• Application-level tests

rather than relying on Netcat alone.

18. Packet Capture with tcpdump

When configuration inspection is not enough, inspect the packets.

Basic capture:

sudo tcpdump -ni eth0

Capture from the Linux any interface:

sudo tcpdump -ni any

Official project information is available at tcpdump.org.

Capture ICMP

sudo tcpdump -ni eth0 icmp

Then run:

ping 192.168.10.1

You may observe:

Echo Request
Echo Reply

Capture DNS

sudo tcpdump -ni any port 53

Then:

dig example.com

This helps determine whether DNS queries and responses are actually crossing the network.

Capture HTTPS Transport Traffic

sudo tcpdump -ni any 'tcp port 443'

You cannot read encrypted HTTPS application content directly, but you can still observe transport-level behavior such as:

SYN
SYN-ACK
ACK
TLS traffic
FIN
RST

Filter a Specific Host

sudo tcpdump -ni any host 192.0.2.10

Or:

sudo tcpdump -ni any 'host 192.0.2.10 and port 443'

Precise filters are usually better than capturing everything on a busy server.

Save a PCAP File

sudo tcpdump -ni any -w capture.pcap

Stop with:

Ctrl+C

You can later inspect the file with tcpdump:

tcpdump -nr capture.pcap

or use a packet-analysis application such as Wireshark.

Why Packet Capture Changes Troubleshooting

Suppose:

curl timeout

That is only a symptom.

Packet capture may show:

SYN
SYN
SYN

with no reply.

Investigate:

• Routing
• Firewall
• Remote server
• Packet filtering

Another capture might show:

SYN
SYN-ACK
ACK

followed by application data.

Now you know the TCP handshake is working, and the problem is likely higher in the stack.

This evidence-based distinction is one of the strongest practical parts of the source article. Pasted text

19. NetworkManager from the Command Line with nmcli

nmcli is the command-line interface for NetworkManager.

List devices:

nmcli device status

List connections:

nmcli connection show

Active connections:

nmcli connection show --active

Detailed connection information:

nmcli connection show "Connection Name"

Official NetworkManager documentation is available at networkmanager.dev.

ip vs nmcli

This is an important distinction:

ip
↓
Current kernel networking objects

nmcli
↓
NetworkManager configuration and management

For example:

ip addr

shows addresses currently configured.

While:

nmcli connection show

shows NetworkManager connection profiles.

They are related but not interchangeable.

Configure a Static Address

Example:

sudo nmcli connection modify "Wired connection 1" \
  ipv4.addresses 192.168.10.20/24 \
  ipv4.gateway 192.168.10.1 \
  ipv4.method manual

DNS:

sudo nmcli connection modify "Wired connection 1" \
  ipv4.dns "1.1.1.1 8.8.8.8"

Activate:

sudo nmcli connection up "Wired connection 1"

Then verify:

ip addr
ip route
nmcli device status

Connection names and distribution defaults can vary.

20. NIC Diagnostics with ethtool

ethtool focuses on Ethernet interface and NIC information.

Typical uses include:

• Link state
• Speed
• Duplex
• Auto-negotiation
• Driver
• Firmware
• Offload settings
• Hardware counters

Run:

sudo ethtool eth0

Driver information:

sudo ethtool -i eth0

Statistics:

sudo ethtool -S eth0

Diagnose a Link-Speed Problem

Suppose the interface operates at:

100 Mb/s

when you expect:

1 Gb/s

Run:

sudo ethtool eth0

Check:

• Speed
• Duplex
• Auto-negotiation
• Link detected

This can explain severe performance problems even if:

• Ping works
• DNS works
• HTTP works

Not all networking problems are binary up/down failures.

21. Linux Network Troubleshooting by Layer

The main tools can be summarized as:

NIC / Physical      → ethtool
Interface           → ip link
Address             → ip addr
Neighbor            → ip neigh
Routing             → ip route
Reachability        → ping
Path                → traceroute / mtr
Socket / Transport  → ss / nc
DNS                 → dig / resolvectl
Application         → curl
Packets             → tcpdump
Configuration       → nmcli

A small set of tools can solve a remarkable number of networking incidents:

ip
ss
dig
curl
tcpdump

Add:

ping
mtr
nmcli
ethtool

and the toolkit becomes significantly more complete.

22. Practical Linux Network Troubleshooting Scenarios

Website Does Not Open

Suppose:

curl https://example.com

fails.

Do not immediately restart services.

Step 1 — DNS

dig example.com

Step 2 — Route

ip route get 1.1.1.1

Step 3 — Reachability

ping -c 4 1.1.1.1

Step 4 — TCP

nc -vz example.com 443

Step 5 — HTTPS

curl -Iv https://example.com

Step 6 — Packets

sudo tcpdump -ni any 'host <resolved-ip> and port 443'

Now the failure is measurable.

DNS Resolution Fails

Start:

dig example.com

Inspect resolver configuration:

cat /etc/resolv.conf

If systemd-resolved is present:

resolvectl status

Then test an explicit resolver:

dig @1.1.1.1 example.com

Compare:

Local resolver
vs.
Explicit resolver

If public DNS succeeds while the local resolver fails, investigate:

• Resolver configuration
• Firewall
• Internal DNS
• Split DNS
• Network path

Service Works Locally but Not Remotely

Suppose:

curl http://127.0.0.1:8080

works.

But a remote client cannot reach:

192.168.10.20:8080

Check:

ss -ltnp | grep ':8080'

If you see:

127.0.0.1:8080

the service is bound only to loopback.

The network itself may be functioning correctly.

This is an application-binding problem.

Service Is Listening but Remote TCP Fails

Suppose:

ss -ltnp

shows:

0.0.0.0:443

but:

nc -vz 192.0.2.10 443

fails remotely.

Investigate:

• Host firewall
• Network firewall
• Security groups
• ACLs
• Routing

Linux firewall control may involve:

• nftables
• iptables compatibility
• UFW
• firewalld

For firewall concepts, see Firewalls Explained.

Missing or Incorrect Route

Suppose:

ip addr

looks correct, but:

curl https://example.com

times out.

Check:

ip route

Then:

ip route get 1.1.1.1

If there is no usable default route, you may have identified the problem quickly.

Packet Loss

Start:

ping -c 50 1.1.1.1

Then:

mtr -rw 1.1.1.1

Then:

ip -s link show dev eth0

If necessary:

sudo tcpdump -ni eth0 icmp

Now compare:

End-to-end loss
+
Path behavior
+
Interface counters
+
Actual packets

This is much stronger evidence than one ping test.

Slow Network Performance

Start with:

ip -s link

and:

ss -s

Then:

ethtool eth0

Path analysis:

mtr -rw destination.example.com

Measure HTTP stages:

curl -w '\nDNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n' \
  -o /dev/null \
  -s https://example.com

This separates:

DNS lookup
   ↓
TCP connect
   ↓
TLS
   ↓
Server processing
   ↓
Transfer

This can be especially useful for:

• APIs
• Reverse proxies
• Load balancers
• CDNs
• Slow upstream applications

High Interface Errors

Suppose:

ip -s link show dev eth0

shows:

RX errors increasing
RX dropped increasing

Then inspect:

sudo ethtool eth0

and:

sudo ethtool -S eth0

Possible investigation areas:

• NIC
• Driver
• Cable
• Switch port
• Speed
• Duplex
• Hardware
• Virtualization layer

Routing Loop

Run:

traceroute 10.20.30.40

Suppose you repeatedly see:

10.0.0.1
10.0.1.1
10.0.0.1
10.0.1.1

This suggests a routing-path issue.

Inspect:

ip route

and:

ip rule

The problem may now involve:

• Policy routing
• Static routes
• Dynamic routing
• Network topology

23. Advanced Linux Networking: Network Namespaces

Linux network namespaces provide isolated networking environments.

A namespace can have its own:

• Interfaces
• Routes
• Sockets
• Firewall state

Conceptually:

Host
 |
 +-- Namespace A
 |      |
 |     eth0
 |
 +-- Namespace B
        |
       eth0

Network namespaces are important for understanding:

• Containers
• Kubernetes networking
• Service isolation
• Network labs
• Virtual topologies

Simple Namespace Lab

Create two namespaces:

sudo ip netns add ns1
sudo ip netns add ns2

Create a virtual Ethernet pair:

sudo ip link add veth1 type veth peer name veth2

Move interfaces:

sudo ip link set veth1 netns ns1
sudo ip link set veth2 netns ns2

Assign addresses:

sudo ip netns exec ns1 ip addr add 10.10.10.1/24 dev veth1
sudo ip netns exec ns2 ip addr add 10.10.10.2/24 dev veth2

Bring them up:

sudo ip netns exec ns1 ip link set veth1 up
sudo ip netns exec ns2 ip link set veth2 up

Test:

sudo ip netns exec ns1 ping -c 3 10.10.10.2

You have now created a miniature network entirely inside one Linux host.

Why Namespaces Matter

Container networking can conceptually look like:

Container
   |
Network Namespace
   |
Virtual Ethernet
   |
Bridge / Virtual Network
   |
Host
   |
Physical NIC

The source article explicitly connects network namespaces to Docker, Kubernetes, and virtual networking. Pasted text

For the virtualization concepts underneath these abstractions, see Virtualization Explained.

24. Linux Network Tools on Containers, VMs, and Cloud Servers

Containers

Inside a container:

ip addr
ip route
ss -lntp

On the host:

ip link
ip neigh
ip netns
tcpdump

This can help trace:

Container
  ↓
veth
  ↓
Bridge
  ↓
Host
  ↓
NAT
  ↓
Physical NIC

Cloud Servers

Cloud VMs still require Linux network troubleshooting even when physical networking is abstracted.

Useful commands remain:

ip route
ss -lntup
dig example.com
curl -v https://example.com

For the provider-side network architecture, see Cloud Networking Explained and Cloud Computing Explained.

Virtual Machines

A VM networking problem may exist at several layers:

Guest OS
   |
Virtual NIC
   |
Hypervisor
   |
Virtual Switch
   |
Physical NIC
   |
Physical Network

Linux tools inspect the guest side.

The hypervisor or cloud platform provides evidence for the next layer.

25. Linux Network Tools for Security

Network commands are also useful for defensive administration.

For example:

sudo ss -lntup

can expose unexpected listening services.

ip route

can reveal unexpected routes.

ip neigh

can expose unexpected neighbor state.

tcpdump

can reveal unexpected traffic.

dig

can help investigate suspicious DNS behavior.

Use these tools only on systems and networks you are authorized to inspect.

For broader defensive concepts, see Network Security Basics.

Audit Listening Services

Run:

sudo ss -lntup

Build an inventory:

22/tcp
53/udp
80/tcp
443/tcp

Then ask:

• Why is the port open?
• Which process owns it?
• Does it require external exposure?
• Is a firewall restricting access appropriately?

This connects network administration with host security.

Protect Packet Captures

Packet captures may contain sensitive information such as:

• IP addresses
• Hostnames
• URLs
• Metadata
• Unencrypted credentials
• Application data

Avoid capturing more than necessary.

Instead of:

sudo tcpdump -ni any -w capture.pcap

without a clear scope, define:

• Which host?
• Which protocol?
• Which port?
• Which period?
• What are you trying to prove?

For example:

sudo tcpdump -ni any -w dns.pcap 'host 10.10.10.53 and port 53'

Filtered captures are easier to analyze and can reduce unnecessary data collection.

26. Automating Linux Network Diagnostics

Linux networking commands can be combined into reusable diagnostic scripts.

A basic information script:

#!/usr/bin/env bash

set -u

echo "=== Interfaces ==="
ip -br link

echo
echo "=== Addresses ==="
ip -br addr

echo
echo "=== Routes ==="
ip route

echo
echo "=== Neighbors ==="
ip neigh

echo
echo "=== Listening Sockets ==="
ss -lntup

echo
echo "=== DNS ==="
if command -v resolvectl >/dev/null 2>&1; then
    resolvectl status
fi

This does not change configuration.

It simply collects evidence.

You can extend it:

echo "=== Connectivity ==="
ping -c 3 1.1.1.1 || true

echo
echo "=== DNS Resolution ==="
getent hosts example.com || true

echo
echo "=== HTTP Test ==="
curl -I --max-time 10 https://example.com || true

This produces a simple Linux network health report.

In production, diagnostic scripts should use:

• Timeouts
• Predictable output
• Careful error handling
• Minimal privileges
• Secure log handling

Linux network commands can also be integrated into:

• Bash
• Python
• Ansible
• CI/CD
• Monitoring
• Incident-response workflows

For example:

if ip route get 1.1.1.1 >/dev/null 2>&1; then
    echo "Routing available"
else
    echo "Routing failure"
fi

Or:

if curl -fsS --max-time 5 https://example.com >/dev/null; then
    echo "HTTPS OK"
else
    echo "HTTPS FAILED"
fi

This turns manual diagnosis into repeatable automation.

27. Linux Network Tools Cheat Sheet

Useful One-Line Checks

What is my IP?

ip -br addr

What is my default gateway?

ip route | grep default

Which interface handles Internet traffic?

ip route get 1.1.1.1

What ports are listening?

sudo ss -lntup

Is DNS working?

dig example.com

Can I reach the gateway?

ping -c 4 "$(ip route | awk '/default/ {print $3; exit}')"

Can I reach TCP/443?

nc -vz example.com 443

Does HTTPS work?

curl -Iv https://example.com

Are packets actually leaving?

sudo tcpdump -ni any host example.com

28. Linux Network Production Checklist

Before declaring a Linux server’s network healthy, verify:

• Interface names are known
• Interface is up
• IPv4 configuration is correct
• IPv6 configuration is understood
• Default route exists
• Local gateway is reachable where appropriate
• Neighbor state looks reasonable
• Required services are listening
• DNS works
• Destination connectivity works
• Network path has been checked if necessary
• Application port is reachable
• Application protocol works
• Interface counters have been checked
• NIC state is healthy
• Packet capture is used only when necessary
• Evidence is preserved for difficult incidents
• Sensitive packet captures are protected

29. Real-World Troubleshooting Matrix

This table preserves the practical symptom-to-tool mapping from the original guide while avoiding dozens of repeated troubleshooting sections. Pasted text

30. Frequently Asked Questions

What is the most important Linux network command?

For general network configuration and inspection, ip is one of the most important commands because it covers interfaces, addresses, routing, neighbors, and other kernel networking objects.

What replaced ifconfig on modern Linux systems?

Modern Linux workflows commonly use the ip command from iproute2 instead of relying on older ifconfig-based workflows.

What is the difference between ip and nmcli?

ip works with current Linux kernel networking objects.

nmcli manages and reports NetworkManager configuration and connection profiles.

What does ss do?

ss displays Linux socket information, including listening services and active network connections.

What is ping used for?

ping uses ICMP Echo operations to test reachability and measure response times.

What is the difference between ping and traceroute?

ping primarily tests end-to-end ICMP reachability.

traceroute investigates the path toward a destination using TTL-based probing.

What is MTR?

MTR combines repeated latency measurements with traceroute-style hop analysis.

What is dig used for?

dig queries DNS servers and provides detailed DNS response information.

What is curl used for?

curl transfers data using URLs and is particularly useful for testing HTTP, HTTPS, APIs, redirects, TLS behavior, and application responses.

What is tcpdump?

tcpdump captures and displays packets matching selected filters and can save packet captures for later analysis.

What is the difference between tcpdump and Wireshark?

tcpdump is primarily command-line oriented and works particularly well on servers.

Wireshark provides a graphical packet-analysis environment with extensive protocol dissection.

What is ethtool used for?

ethtool is used to inspect Ethernet interface properties such as speed, duplex, link state, driver information, and NIC statistics.

What does ip neigh show?

It shows Linux neighbor information, including IPv4 ARP-related and IPv6 Neighbor Discovery states.

How can I test whether TCP port 443 is reachable?

Use:

nc -vz example.com 443

To test actual HTTPS behavior:

curl -Iv https://example.com

Which Linux network tool is best?

There is no single best tool.

The best command depends on the question:

State        → ip
Path         → ip route / mtr
Socket       → ss
TCP Port     → nc
DNS          → dig / resolvectl
Application  → curl
Packets      → tcpdump
NIC          → ethtool
Management   → nmcli

Final Linux Network Troubleshooting Workflow

When a Linux network problem appears, use this sequence:

                NETWORK PROBLEM
                       |
                       v
                 ip link / addr
                       |
          "Is the interface configured?"
                       |
                       v
                   ip route
                       |
             "Where will traffic go?"
                       |
                       v
                   ip neigh
                       |
          "Can I resolve the local neighbor?"
                       |
                       v
                    ping
                       |
              "Is it reachable?"
                       |
                       v
                traceroute / mtr
                       |
              "What is the path?"
                       |
                       v
                   ss / nc
                       |
        "Is the service listening and can
             TCP reach the port?"
                       |
                       v
             dig / resolvectl
                       |
                "Does DNS work?"
                       |
                       v
                    curl
                       |
        "Does the application protocol work?"
                       |
                       v
                  tcpdump
                       |
          "What is actually on the wire?"
                       |
                       v
                  ethtool
                       |
          "Is the NIC / link healthy?"

This is the core philosophy of the original article: diagnose configuration, addressing, routing, neighbors, reachability, transport, DNS, application behavior, packets, and hardware systematically instead of running commands randomly. Pasted text

Conclusion

Linux provides a powerful set of command-line networking tools for administrators, network engineers, DevOps engineers, cloud engineers, and security professionals.

The core toolkit is:

ip
ss
ping
traceroute
mtr
dig
resolvectl
curl
nc
tcpdump
nmcli
ethtool

Each answers a different question.

ip shows the Linux networking state.

ss shows sockets and connections.

ping, traceroute, and mtr help investigate reachability and path behavior.

dig and resolvectl help isolate DNS problems.

curl moves troubleshooting into HTTP, HTTPS, TLS, and application behavior.

nc tests transport connectivity.

tcpdump reveals the packets actually crossing the interface.

nmcli manages NetworkManager.

ethtool provides deeper visibility into the NIC, driver, link, and Ethernet layer.

The most important skill is therefore not memorizing one command.

It is learning to move logically through:

Configuration
      ↓
Addressing
      ↓
Routing
      ↓
Neighbors
      ↓
Reachability
      ↓
Path
      ↓
Transport
      ↓
DNS
      ↓
Application
      ↓
Packets
      ↓
Hardware

When these layers are investigated systematically, apparently complex Linux networking incidents become much easier to isolate.

For the wider technical context, continue with Linux Server Administration, DNS Explained, DHCP Explained, Cloud Networking Explained, and Network Security Basics.