Linux Network Troubleshooting

If you've spent any time as a sysadmin — or honestly, just as someone who's had to fix their own home network at 11pm — you know that connectivity issues are one of the most common headaches out there. The good news is that a handful of core tools and a methodical approach can take you from "why isn't this working" to a root cause pretty quickly. 

This guide walks through the essentials: configuring interfaces, managing routes, and diagnosing problems when things go sideways.

Configuring Network Interfaces

Your network interfaces are the actual bridge between your machine and the outside world, so getting them configured correctly is step one for any kind of reliable connectivity.

Doing It Manually

ifconfig is the old-school, tried-and-true tool for this on Unix-like systems. To see everything currently configured, run:

ifconfig -a

If you need to manually set up a specific interface — assigning an IP, a netmask, and bringing it online — it looks like this:

ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up

And taking an interface down (or bringing it back up) is about as simple as it sounds:

ifconfig eth0 down
ifconfig eth0 up

Letting the System Handle It

Most modern Linux distros give you a more convenient path: ifup and ifdown, which pull from configuration files (typically /etc/network/interfaces) instead of requiring you to type everything out by hand each time:

ifup eth0    # Activate interface using stored configuration
ifdown eth0  # Deactivate interface gracefully

These are genuinely worth using over manual ifconfig calls when you can, since they bring up the entire configuration for an interface — routes, DNS, the works — rather than just the bare-minimum IP and netmask.

Managing the Routing Table

The routing table is what decides where your traffic actually goes once it leaves your system. Get this wrong, and you can have a perfectly healthy interface that still can't reach anything useful.

Viewing and Adding Routes

To see what your routing table currently looks like:

route -n  # Display routes with numerical addresses

And if you need to add a route to a specific network through a particular gateway:

route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.1

Getting the Default Route Right

The default route deserves special attention — it's what handles traffic to anything outside your local subnet, and a misconfigured default route is one of the single most common causes of "the internet just doesn't work" tickets. To set or change it:

route add default gw 192.168.1.1  # Add default route
route del default                 # Delete existing default route

And to remove a specific route entirely:

route del -net 192.168.2.0 netmask 255.255.255.0

Diagnosing Problems When They Show Up

Once something's actually broken, the trick is working through the right tools in a sensible order rather than guessing randomly.

Start With the Basics: Ping

ping is almost always the first thing to reach for. It fires off ICMP echo requests and confirms whether basic communication is happening at all:

ping google.com          # Test internet connectivity
ping -c 4 192.168.1.1   # Send only 4 packets to local gateway

Tracing the Path

If ping tells you something's wrong but not where, traceroute is the natural next step. It maps out every hop your packets take on the way to their destination:

traceroute google.com

This is genuinely useful for pinpointing exactly where things fall apart — whether that's a slow hop somewhere in the middle or a dead end that never responds at all.

Ruling Out DNS

A surprising number of "connectivity issues" turn out to actually be DNS issues wearing a disguise. host and dig are your go-to tools here:

host google.com                    # Simple DNS lookup
dig google.com                     # Detailed DNS query information
dig @8.8.8.8 google.com           # Query specific DNS server

That last one — querying a specific DNS server directly — is especially handy for figuring out whether the problem is your configured DNS server specifically, or something more fundamental.

Checking Connections and Stats

netstat gives you a broader picture of what's actually happening on your system network-wise:

netstat -tuln     # Show listening ports (TCP/UDP)
netstat -rn       # Display routing table
netstat -i        # Show interface statistics

Checking the System's Identity

And finally, hostname — mostly relevant for identification purposes and certain services that care about it:

hostname          # Display current hostname
hostname newname  # Set hostname (temporary)

A Sensible Order to Work Through Things

When you're staring down a connectivity problem and not sure where to start, working through these steps roughly in order tends to save a lot of guesswork:

1. Check the physical layer first. Cables, switch ports, interface status — ifconfig will tell you if the interface is even up.
2. Ping the local interface itself. Confirms the interface's own IP is responding.
3. Ping something else on the same subnet. Confirms local network communication is working.
4. Ping the default gateway. Confirms you can actually leave the local subnet.
5. Ping something external. Confirms broader internet connectivity.
6. Check DNS resolution. Use host or dig to rule out (or confirm) DNS as the culprit.
7. Review the routing table. route -n will show you if traffic is being sent somewhere unexpected.
8. Trace the path. If everything above looks fine but something's still off, traceroute will usually show you exactly where packets are getting dropped.

Working through these in order means you're isolating the problem layer by layer, rather than jumping straight to advanced diagnostics before confirming the basics actually work.

Where Problems Usually Come From

In practice, most network headaches trace back to one of a few usual suspects: a bad default route, a misconfigured interface, or DNS resolution quietly failing in the background. It's always worth double-checking that your interface has the right IP, subnet mask, and gateway before digging deeper, and confirming your DNS servers are actually reachable and responding. And whenever you do make a change, it's worth documenting what you changed and testing connectivity right after — future-you (or whoever inherits the system next) will thank you.