Skip to main content
In this guide you’ll verify a Linux system’s network configuration step by step. We’ll inspect interfaces and IP addresses, review the routing table, test connectivity (including DNS resolution), trace a packet path, and list open ports and listening services. Follow the sequence below as a practical troubleshooting workflow.
Some commands (for example ss -p or certain ip operations) require root privileges to show process or full interface details. Prefix them with sudo or run as root when necessary.

​
Quick command reference

​
1) Show interfaces and their status

List interfaces and their administrative/link state:
Show IP addresses assigned to each interface (IPv4 and IPv6):
Example combined output demonstrating link-level state and assigned addresses. If an interface lacks inet or inet6, it cannot exchange IP traffic:
Tip: An interface can be administratively UP but still lack an IP address (no inet/inet6). That interface will not participate in IP networking until an address is assigned.

​
2) Check the routing table

Display the kernel routing table to find the default gateway and any specific routes:
Interpretation notes:
  • Look for a line beginning with default via — that is the system’s default route for outbound traffic.
  • If the default route is missing, the system likely cannot reach external networks beyond its local subnets.

​
3) Test connectivity with ping

Use ping to test reachability at different layers:
  • Ping the local gateway (e.g., 10.0.2.1) — verifies local network and L2/L3 connectivity.
  • Ping an external IP (e.g., 8.8.8.8) — verifies upstream routing and Internet access.
  • Ping a hostname (e.g., google.com) — verifies DNS resolution and downstream reachability.
Example session:
Troubleshooting hints:
  • If you can ping an IP (e.g., 8.8.8.8) but not a hostname, DNS is likely the issue.
  • If you can ping the gateway but not an external IP, check the default route or upstream connectivity.
  • Some networks block or rate-limit ICMP. A lack of responses is not definitive proof of total unreachability.

​
4) Trace the path to a destination

Use tracepath to reveal each hop packets take and identify where packets are delayed or dropped:
Interpreting tracepath output:
  • Each line represents a hop (router) along the path.
  • Increasing latencies are expected; repeated * or timeouts show where responses are blocked or lost.
  • Use this to narrow the location of failures (local router, ISP, or remote network).
Example invocation (output varies by network):

​
5) Show open ports and listening services

To see which sockets are listening and which processes own them, use ss:
Options explained:
  • -t : TCP sockets
  • -u : UDP sockets
  • -l : only listening sockets
  • -n : numeric addresses and ports (no name resolution)
  • -p : show process using the socket (requires root)
ss -p requires root privileges to display processes. Run as sudo ss -tulnp to see process names/PIDs owning the sockets. Misinterpreting listening addresses can cause services to be bound only to localhost (127.0.0.1) and appear unreachable remotely.
Use the output to confirm which services are bound to which interfaces and ports, and whether they are accepting connections from other hosts.

​
6) Show interfaces in a brief, summarized form

For a compact view (one line per interface) with primary addresses:
Example:
This command is useful for quick status checks or scripts that parse interface state.
Conclusion and practical workflow A reliable sequence for troubleshooting network issues is:
  1. Inspect link state and interfaces (ip link, ip addr, or ip -brief address)
  2. Verify routing (ip route)
  3. Test layer-3 reachability (ping to gateway, external IP, and hostname)
  4. Trace the path to the destination (tracepath)
  5. Inspect listening sockets and services (ss -tulnp)
Following these steps helps you pinpoint where configuration or connectivity breaks occur — whether local interface, routing, DNS, upstream connectivity, or service binding. Links and references

Watch Video