Network outages on Linux break DNS lookups, package downloads, monitoring, and remote administration, so isolating the failing layer quickly reduces downtime.
Most failures map cleanly to a layer: interface/link state, IP addressing, routing plus neighbor discovery (ARP/NDP), or name resolution and policy controls. Linux exposes each layer through ip, the kernel neighbor table, resolver lookups via getent, and firewall rules, making it possible to prove where traffic stops.
Capture outputs before changing configuration, especially on multi-homed hosts, VPN endpoints, or remote-only servers. Restarting networking or flushing firewall rules can terminate existing sessions and should be treated as last-resort actions unless console access is available.
Steps to troubleshoot a Linux network outage with ip, ping, and getent:
- Confirm interface link state with address assignment.
$ 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> $ ip -brief address show lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 192.0.2.40/24 metric 100 fe80::20/64
DOWN or missing addresses usually indicates a local link, DHCP, or interface configuration issue.
- Check interface counters for errors or drops.
$ 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 787744132 803916 0 0 0 0 TX: bytes packets errors dropped carrier collsns 653669811 662931 0 0 0 0Rising errors or carrier counters often point to cabling, duplex negotiation, or driver problems.
- Verify default route (gateway) selection.
$ ip route show default default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.40 metric 100 $ ip -6 route show default
- Confirm routing for a known external IP address.
$ ip route get 203.0.113.50 203.0.113.50 via 192.0.2.1 dev eth0 src 192.0.2.40 uid 1000 cacheAn unexpected dev or src indicates policy routing, multiple uplinks, or a wrong metric.
- Test gateway reachability for loss or neighbor failures.
$ 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=128 time=0.208 ms 64 bytes from 192.0.2.1: icmp_seq=2 ttl=128 time=0.348 ms 64 bytes from 192.0.2.1: icmp_seq=3 ttl=128 time=1.50 ms --- 192.0.2.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2038ms rtt min/avg/max/mdev = 0.208/0.685/1.501/0.579 ms $ 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 neighbor entries usually indicate L2 problems, wrong VLAN, or ARP/NDP filtering.
- Test reachability beyond the gateway using a known IP address.
$ ping -c 3 203.0.113.50 PING 203.0.113.50 (203.0.113.50) 56(84) bytes of data. 64 bytes from 203.0.113.50: icmp_seq=1 ttl=128 time=5.50 ms 64 bytes from 203.0.113.50: icmp_seq=2 ttl=128 time=15.6 ms 64 bytes from 203.0.113.50: icmp_seq=3 ttl=128 time=7.89 ms --- 203.0.113.50 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2013ms rtt min/avg/max/mdev = 5.502/9.656/15.573/4.296 ms
Success here with failed name lookups points to DNS; failure here points to routing, upstream, or ISP/provider reachability.
- Check DNS resolution through the system resolver.
$ getent ahosts api.example.net | head 203.0.113.50 STREAM api.example.net 203.0.113.50 DGRAM 203.0.113.50 RAW 203.0.113.51 STREAM 203.0.113.51 DGRAM 203.0.113.51 RAW 2001:db8:203:113::50 STREAM 2001:db8:203:113::50 DGRAM 2001:db8:203:113::50 RAW 2001:db8:203:113::51 STREAM
Related: How to check DNS resolution in Linux
- Inspect /etc/resolv.conf for unexpected nameservers or search domains.
$ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 39 Apr 23 2024 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf $ cat /etc/resolv.conf # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 trust-ad search localdomain
A local stub such as 127.0.0.53 is normal with systemd-resolved, but upstream DNS servers must still be reachable.
- Validate local firewall rules or blocked ports.
$ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT
On nftables systems, inspect with sudo nft list ruleset.
Disabling or flushing firewall rules can expose services directly to the network and may violate security policy.
- Repeat reachability and DNS checks after changes.
$ ping -c 1 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=128 time=0.330 ms --- 192.0.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.330/0.330/0.330/0.000 ms $ ping -c 1 203.0.113.50 PING 203.0.113.50 (203.0.113.50) 56(84) bytes of data. 64 bytes from 203.0.113.50: icmp_seq=1 ttl=128 time=5.36 ms --- 203.0.113.50 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 5.358/5.358/5.358/0.000 ms $ getent hosts api.example.net 2001:db8:203:113::50 api.example.net 2001:db8:203:113::51 api.example.net
If ICMP is blocked, validate with an application protocol such as HTTPS or the affected service port instead of ping.
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.
