How to check gateway reachability in Linux

Gateway reachability is one of the fastest checks for separating a local first-hop problem from a wider upstream outage. When the selected gateway cannot be reached, remote subnets, package mirrors, public APIs, and DNS resolvers can all appear down even though the interface still has a valid address.

Linux chooses the first hop from its routing tables and policy rules, then resolves that gateway IP to a link-layer neighbor entry through ARP for IPv4 or NDP for IPv6. ip route get shows the effective next hop and interface, ping checks whether the gateway answers, and ip neigh shows whether the kernel could resolve the gateway to a MAC address.

Some routers rate-limit or drop ICMP echo requests, and VPNs or multiple uplinks can cause a different gateway to be selected than the one shown in a simple default-route listing. Keep probes short with -c, use -n to avoid reverse-DNS delays, and treat repeated FAILED or INCOMPLETE neighbor state as stronger evidence of a first-hop problem than a single lost echo reply.

Steps to check gateway reachability with ip and ping in Linux:

Display the current default route to identify the gateway address and outgoing interface.
```
$ ip route show default
default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.40 metric 100
```
The address after via is the IPv4 gateway and dev is the interface used to reach it. If the active gateway is IPv6, inspect it with ip -6 route show default.

Related: How to check the default route in Linux
Ask the kernel which first hop it would use for an off-subnet destination.
```
$ ip route get 203.0.113.50
203.0.113.50 via 192.0.2.1 dev eth0 src 192.0.2.40 uid 0 
    cache 
```
This lookup reflects policy routing and the currently selected source address, so it is a more reliable first-hop check than reading only the stored default route.

Send a short numeric ping to the selected gateway.

$ ping -n -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.073 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 192.0.2.1: icmp_seq=3 ttl=64 time=0.039 ms

--- 192.0.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2067ms
rtt min/avg/max/mdev = 0.038/0.050/0.073/0.016 ms

Use ping -6 -n -c 3 2001:db8:1::1 when the selected gateway is IPv6. A missing reply can still be caused by filtering or rate-limiting, so confirm it against the neighbor state in the next step.

Inspect the neighbor entry for the gateway address.
```
$ ip neigh show to 192.0.2.1
192.0.2.1 dev eth0 lladdr 02:00:00:00:00:01 REACHABLE
```
REACHABLE, STALE, and DELAY show that Layer 2 resolution succeeded, while INCOMPLETE or FAILED means the host is not resolving the gateway MAC address cleanly. Use ip -6 neigh show to 2001:db8:1::1 for an IPv6 next hop.

Check interface counters on the same device for drops or link 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
      40419857  115529      0       0       0       0
    TX:  bytes packets errors dropped carrier collsns
        641101    9829      0       0       0       0

Rising errors, dropped, or carrier counts point to local link trouble between the host and its first hop. If any counters are non-zero, re-run the command during the test or use ip -s -s link show dev eth0 for a more detailed error breakdown.