Verify IP Parameters on Windows, macOS, and Linux

Half of "the network is down" tickets end at the client. Before touching a switch, verify four things on the host itself: its IP address and mask, its default gateway, its DNS servers, and whether it can reach that gateway. CCNA objective 1.10 asks you to do this on Windows, macOS, and Linux. This guide gives you the exact commands for all three - with the Linux output captured live from a real Debian machine in our Network Fundamentals lab.

The four questions, in order

1. Do I have an address? A real one - not 169.254.x.x, which means DHCP failed and the host self-assigned (APIPA).
2. Do I have a default gateway on my own subnet? Wrong-subnet gateways happen with fat-fingered static configs.
3. Can I reach the gateway? One ping isolates the problem to "my segment" or "beyond it."
4. Do I have working DNS? "The internet is down" while pings to 1.1.1.1 succeed is a DNS problem, every time.

Linux: real output

Modern Linux uses the ip suite (ifconfig is legacy). From our lab VM:

j@llmbits:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens192           UP             192.168.88.156/24
ens224           UP             169.254.147.59/16 192.168.99.100/24 2001:db8:99::100/64

j@llmbits:~$ ip route
default via 192.168.88.1 dev ens192 proto dhcp src 192.168.88.156 metric 1002
10.0.10.0/24 via 192.168.99.1 dev ens224
192.168.88.0/24 dev ens192 proto dhcp scope link src 192.168.88.156
192.168.99.0/24 dev ens224 proto kernel scope link src 192.168.99.100

j@llmbits:~$ cat /etc/resolv.conf | grep nameserver
nameserver 45.90.28.181
nameserver 45.90.30.181

Three flags in that real output worth reading like an engineer:

• ip -br addr (brief mode) is the fastest overview - state and addresses per interface, one line each. Note ens224 carries both a 169.254 APIPA address and a real static one: the APIPA appeared because no DHCP answers on that lab segment. Harmless here, but on a single-NIC client, 169.254-only means "DHCP failed" and your investigation moves to the DHCP server or the VLAN.
• ip route answers the gateway question. proto dhcp tells you the route was learned, not typed; the default via line is the gateway. Per-prefix static routes (the 10.0.10.0/24 line) show this host reaches lab networks via a different NIC - multihomed hosts route per-destination, a frequent source of "works for some destinations" tickets.
• DNS lives in /etc/resolv.conf (or resolvectl status on systemd-resolved distros, where resolv.conf may just point at a local stub).

Then prove gateway reachability - here against our lab router:

j@llmbits:~$ ping -c 3 192.168.99.1
PING 192.168.99.1 (192.168.99.1) 56(84) bytes of data.
64 bytes from 192.168.99.1: icmp_seq=1 ttl=255 time=2.20 ms
64 bytes from 192.168.99.1: icmp_seq=3 ttl=255 time=1.71 ms
--- 192.168.99.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

j@llmbits:~$ ip neigh show dev ens224
192.168.99.1 lladdr aa:bb:cc:00:12:00 DELAY

ip neigh is the ARP table - the gateway's MAC resolved, which proves Layer 2 adjacency even if ICMP were filtered. A gateway stuck at FAILED/INCOMPLETE means a Layer 2 problem: wrong VLAN, dead port, or the gateway simply isn't there.

Windows: the command set

C:\> ipconfig /all        <- address, mask, gateway, DHCP server, DNS, lease times
C:\> ping 192.168.1.1
C:\> nslookup pinglabz.com
C:\> arp -a               <- did the gateway's MAC resolve?
C:\> route print          <- full routing table when multihomed

The details that matter on Windows: plain ipconfig omits DNS and DHCP info - use /all. "Autoconfiguration IPv4 Address 169.254.x.x" is the APIPA tell. ipconfig /release and /renew retry DHCP; ipconfig /flushdns clears the resolver cache that keeps "it's still broken" alive after you've fixed DNS. PowerShell equivalents (Get-NetIPConfiguration, Get-NetRoute, Test-NetConnection) return objects and are what you script with.

macOS: the command set

$ ifconfig en0                          <- address and mask (still current on macOS)
$ netstat -rn | head -5                 <- default gateway
$ scutil --dns | grep nameserver        <- effective DNS servers
$ networksetup -getinfo "Wi-Fi"         <- the GUI's view, scriptable
$ ping -c 3 192.168.1.1

macOS is BSD underneath: ifconfig and netstat -rn remain the native tools (no ip command out of the box). scutil --dns shows the resolvers actually in use, which can differ from what the GUI displays when VPNs push split DNS - a modern gotcha worth knowing on any OS.

Same questions, three dialects

FAQ

What does a 169.254.x.x address mean?

APIPA / link-local: the host asked DHCP for an address, got no answer, and self-assigned from 169.254.0.0/16. It can talk to other link-local hosts on the same segment and nothing else. Diagnosis moves upstream: is the DHCP server up, is the port in the right VLAN, is the DHCP relay (ip helper-address) configured on the SVI?

Why does ping to an IP work but browsing fail?

DNS. If ping 1.1.1.1 succeeds but ping google.com can't resolve, the host's resolver settings are wrong, the DNS server is down, or something between them blocks UDP/53. Verify with nslookup (Windows), dig (Linux/macOS), or resolvectl query - and remember VPN clients love to rewrite DNS silently.

Is ifconfig deprecated on Linux?

Yes - it's part of the legacy net-tools package, frozen for years and absent from minimal installs. Use ip addr, ip route, ip neigh, and ss (for sockets). macOS is different: its ifconfig is the BSD one and remains the standard tool there.

How do I check for a duplicate IP address on the network?

Symptoms first: intermittent connectivity that follows no pattern, and hosts logging address-conflict warnings. Confirm from another machine: arp -a before and after pinging the suspect IP - if the MAC in the ARP entry flips between two values, two devices claim the address. On the gateway, show ip arp plus the MAC table walks you to both ports.

Which command shows the default gateway on each OS?

Windows: ipconfig /all (or route print, first 0.0.0.0 entry). macOS: netstat -rn, the default line. Linux: ip route, the default via line. In every case, sanity-check that the gateway is inside the host's own subnet - a mask typo puts it outside, and everything off-subnet dies while local traffic works.

Key takeaways

• Verify in order: address, gateway, gateway reachability, DNS. Each step halves the search space.
• 169.254.x.x anywhere means DHCP failed on that interface - move the investigation upstream.
• Linux: ip -br addr, ip route, ip neigh. Windows: ipconfig /all plus arp -a. macOS: BSD tools plus scutil --dns.
• An ARP entry for the gateway proves Layer 2 even when ping is filtered.

Next steps: How Ping Works for what those echoes actually do, Lab ts-nf-01 to practice the whole workflow on tickets, and the Network Fundamentals guide for the domain map.