A Linux network outage is easiest to diagnose when checks follow the packet path instead of starting with service restarts. The first failed layer is the useful evidence, whether it is interface state, IP addressing, default routing, gateway neighbor discovery, upstream reachability, resolver output, or local firewall policy.
The command sequence uses ip for link, address, route, and neighbor state, ping for simple reachability, and getent for the same name-service path that normal applications use. These checks are read-only except for generated ICMP traffic, so they preserve the outage state long enough to decide which layer needs a fix.
Run the checks from the affected host, container, network namespace, or VPN session. Capture the output before changing routes, resolver settings, firewall rules, or interface state, and avoid restarting networking over SSH unless console or out-of-band access is available.
Steps to troubleshoot a Linux network outage:
- Check whether the affected interface has carrier.
$ ip -brief link lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> eth0 UP 02:00:00:00:00:10 <BROADCAST,MULTICAST,UP,LOWER_UP>
DOWN, missing LOWER_UP, or the wrong interface name points to a local link, cable, virtual switch, VLAN, or driver problem before routing or DNS is involved.
Related: How to check network interface link state in Linux - Check the assigned IP addresses.
$ ip -brief address show lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 192.0.2.40/24 fe80::20/64
A link can be UP without a usable address. Missing IPv4 or IPv6 addresses usually shifts the repair toward DHCP, static network configuration, VPN assignment, or the container/network namespace that owns the interface.
- Inspect interface counters for drops or hardware errors.
$ ip -s link show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 02:00:00:00:00:10 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 27436250 1265 0 0 0 0 TX: bytes packets errors dropped carrier collsns 46661 608 0 0 0 0Rising errors, dropped, or carrier counters while the outage is active can point to media, driver, switch-port, or overload trouble even when the interface still shows UP.
- Check the default route.
$ ip route show default default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.40 metric 100
No default route means the host may reach only local subnets. Multiple defaults are normal on multi-homed systems only when metrics or policy routing choose the intended path.
Related: How to check the default route in Linux - Confirm the route selected for a known external IP address.
$ ip route get 1.1.1.1 1.1.1.1 via 192.0.2.1 dev eth0 src 192.0.2.40 uid 1000 cacheUse a numeric IP so DNS does not hide the route decision. An unexpected dev, src, or gateway usually points to route metrics, policy routing, VPN split tunneling, or a stale static route.
- Test the default gateway.
$ ping -c 3 192.0.2.1 PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data. 64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.437 ms 64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.065 ms 64 bytes from 192.0.2.1: icmp_seq=3 ttl=64 time=0.047 ms --- 192.0.2.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2077ms rtt min/avg/max/mdev = 0.047/0.183/0.437/0.179 ms
Replace 192.0.2.1 with the gateway from the default route. If gateway ICMP is blocked by policy, use a gateway-supported management or application probe instead.
Related: How to check gateway reachability in Linux - Check the neighbor entry for the gateway.
$ ip neigh show to 192.0.2.1 192.0.2.1 dev eth0 lladdr 02:00:00:00:00:01 REACHABLE
INCOMPLETE or FAILED means the host cannot resolve the gateway to a link-layer address, which usually moves the investigation to ARP/NDP, VLAN tagging, virtual switching, or same-segment filtering.
- Test reachability beyond the gateway with a known IP address.
$ ping -c 3 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=63 time=6.59 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=63 time=6.08 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=63 time=9.16 ms --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2011ms rtt min/avg/max/mdev = 6.077/7.275/9.156/1.346 ms
Gateway success with external-IP failure points upstream of the host, such as the router, provider edge, VPN, cloud route table, or egress firewall. If ICMP is filtered, test the affected application protocol instead of treating ping loss alone as proof.
- Check name resolution through the system resolver.
$ getent ahosts example.com 172.66.147.243 STREAM example.com 172.66.147.243 DGRAM 172.66.147.243 RAW 104.20.23.154 STREAM 104.20.23.154 DGRAM 104.20.23.154 RAW
IP reachability with failed getent output points to resolver configuration, upstream DNS reachability, split-horizon DNS, search domains, or DNSSEC validation.
Related: How to check DNS resolution in Linux
Tool: DNS Record Lookup - Inspect the resolver configuration.
$ cat /etc/resolv.conf # Managed by the local resolver service. nameserver 127.0.0.53 options edns0 trust-ad search example.net
A stub resolver such as 127.0.0.53 is normal on many systemd-resolved hosts, but the upstream DNS servers still need to be reachable. Use the affected hostname, not only a public test name, when private DNS or VPN search domains are involved.
- Inspect local firewall policy after link, route, and resolver checks pass.
$ sudo nft list ruleset table inet filter { chain output { type filter hook output priority filter; policy accept; } }On legacy hosts, sudo iptables -S may be the relevant view instead. Look for output-chain drops, DNS blocks, VPN kill-switch rules, or interface-specific matches tied to the first failed check.
Related: How to check firewall status in Linux
Related: How to list open ports on Linux - Fix only the first failing layer.
Missing carrier or addresses belongs to interface, DHCP, static config, or VPN repair; missing or wrong routes belong to routing repair; gateway neighbor failures belong to the local segment; external-IP failure after gateway success belongs upstream; DNS failure after IP success belongs to resolver repair; firewall drops belong to policy repair.
Do not flush firewall rules, restart all networking, or bounce the only remote interface as a first response. Those actions can hide the original failure and can disconnect the active session.
- Repeat the failed check and the original application test after the repair.
Retest from the repaired layer outward. A fixed route should pass ip route get and a gateway or external-IP probe; a fixed resolver should pass getent ahosts for the affected hostname; an application outage should pass the same package download, monitoring check, SSH connection, or service request that first exposed the problem.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
