Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Linux Admins By James Joyner IV · · 10 min read

Linux Error: Network is unreachable — Cause, Fix, and Troubleshooting Guide

How to fix the Linux 'Network is unreachable' (ENETUNREACH) error: diagnose missing routes, default gateways, down interfaces, and IPv6 vs IPv4 routing problems.

  • #linux
  • #troubleshooting
  • #networking
  • #routing

Summary

Network is unreachable maps to the errno ENETUNREACH (101). The kernel returns it at connect() time when the routing table has no route that can reach the destination address — not even a default gateway. It is a purely local decision: the packet never leaves the host. This differs from a timeout or a refused connection, where the packet did leave and something downstream dropped or rejected it.

Common Symptoms

  • curl, ping, or an application fails immediately with connect: Network is unreachable.
  • The failure is instant (no timeout wait), because the kernel rejects the send before any packet is transmitted.
  • IPv6 destinations fail with this error while IPv4 works (or vice versa).
  • All outbound traffic to off-subnet addresses fails, but same-subnet hosts still work.

Most Likely Causes of the ‘Network is unreachable’ Error

The most common production causes of the Network is unreachable error, roughly in order:

  1. No default route — the routing table has on-link subnets but no default via gateway, so anything off-subnet is unreachable.
  2. Interface is down — the NIC carrying the route is DOWN, so its routes are removed from the table.
  3. Gateway on the wrong subnet — the configured gateway is not reachable on any interface’s on-link prefix.
  4. IPv6 has no route — the app prefers AAAA/IPv6, but the host only has IPv4 routing configured.
  5. A container/namespace with no gateway — a pod or netns has an address but no default route.
  6. A route was flushed — a NetworkManager/netplan reload or a manual ip route flush removed the default.

Quick Triage

# Does a route to the target even exist?
ip route get 8.8.8.8

# Is there a default gateway at all?
ip route show default

# Is the interface up with an address?
ip -br addr

If ip route get prints RTNETLINK answers: Network is unreachable, the kernel has no route — that is the whole problem.

Diagnostic Commands

# Full routing table (IPv4 and IPv6)
ip route
ip -6 route

# Which route/interface/source would the kernel use for a destination?
ip route get 1.1.1.1
ip route get 2606:4700:4700::1111

# Interface state and addresses
ip -br link
ip addr show

# Is the gateway itself reachable on-link (ARP/neighbor)?
ip neigh show

# Confirm reachability once a route exists
ping -c3 -I eth0 8.8.8.8

# Link-layer / carrier status (cable, negotiation)
ethtool eth0 | grep -E 'Link detected|Speed'

ip route get is the single most useful command: it tells you exactly which route, source address, and interface the kernel would select, or that none exists.

Fix / Remediation

  1. Bring the interface up if it is down:

    sudo ip link set eth0 up
  2. Add a default route pointing at the correct gateway for the box:

    sudo ip route add default via 192.168.1.1 dev eth0
  3. Add a specific route if only one destination network is unreachable:

    sudo ip route add 10.20.0.0/16 via 192.168.1.254 dev eth0
  4. Persist the route. On Ubuntu/Debian with netplan (/etc/netplan/*.yaml):

    network:
      version: 2
      ethernets:
        eth0:
          addresses: [192.168.1.10/24]
          routes:
            - to: default
              via: 192.168.1.1

    Then sudo netplan apply. On RHEL/Rocky with NetworkManager:

    sudo nmcli connection modify eth0 ipv4.gateway 192.168.1.1
    sudo nmcli connection up eth0
  5. For IPv6, add the v6 default if the app needs it:

    sudo ip -6 route add default via fe80::1 dev eth0

Warning: Editing routes on a remote host over SSH can lock you out. Add the new route before deleting the old one, and keep a console/out-of-band session open. Never ip route flush a production gateway without a fallback path.

Validation

ip route get 8.8.8.8          # should now show 'via <gw> dev eth0'
ping -c3 8.8.8.8
curl -sSf https://example.com -o /dev/null && echo OK

A successful ip route get that names a gateway and interface, followed by a returning ping, confirms the route is functional.

Prevention

  • Manage routes declaratively via netplan (Ubuntu/Debian) or NetworkManager keyfiles (RHEL/Rocky) so they survive reboots and reloads.
  • Alert on ip route show default returning empty on any host that needs egress.
  • In containers, ensure the CNI/networking layer installs a default route in each namespace.
  • If you run IPv4-only, disable IPv6 in resolvers/apps or provide a v6 route so getaddrinfo() ordering does not pick an unroutable AAAA record.

Final Notes

Network is unreachable is a local routing verdict: the kernel found no route, so the packet was never sent. Start with ip route get <dest> to see the decision, confirm the interface is up and has an address, and add or fix the default gateway. Distinguish it from No route to host (ARP/gateway reachability failure) and Connection timed out (packet left but nothing answered) — those mean the route existed but something downstream failed.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.

Free download · 368-page PDF

Download the Free 500-Prompt DevOps AI Toolkit

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.