Verify IP Parameters on the Client OS (Windows / macOS / Linux)

Mental model

Before you SSH into a switch or router, verify the client. Nine times out of ten the problem is on the laptop: DHCP failed, DNS is unset, or the default gateway isn’t reachable. Every OS has the same information. You just type slightly different commands to get at it.

The three-column cheat sheet

Reading ipconfig /all (Windows)

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . : corp.example.com
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection I219-V
   Physical Address. . . . . . . . . : 3C-52-82-1A-4B-77
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.1.42(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Sunday, August 9, 2026 8:12:31 AM
   Lease Expires . . . . . . . . . . : Monday, August 10, 2026 8:12:30 AM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.1
                                       8.8.8.8

Six values to check: IP, mask, gateway, DNS, DHCP server, lease timestamps.

Reading ip addr (Linux)

$ ip addr
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 3c:52:82:1a:4b:77 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.42/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0
       valid_lft 79832sec preferred_lft 79832sec
    inet6 fe80::3e52:82ff:fe1a:4b77/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

• Interface state: UP,LOWER_UP: cable connected + link protocol up.
• inet 192.168.1.42/24: v4 address and prefix length.
• inet6 fe80::.../64 scope link: the automatic link-local IPv6 (see ipv6-address-types).

For route + gateway:

$ ip route
default via 192.168.1.1 dev enp3s0 proto dhcp metric 100
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.42 metric 100

The default via 192.168.1.1 line is your gateway.

Reading ifconfig (macOS)

macOS still ships ifconfig. Filter for the IP:

$ ifconfig en0 | grep inet
	inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255
	inet6 fe80::3e52:82ff:fe1a:4b77%en0 prefixlen 64 secured scopeid 0x4

netmask 0xffffff00 = 255.255.255.0 = /24. Gateway lives in netstat -rn:

$ netstat -rn | grep default
default            192.168.1.1        UGSc          en0

DNS servers on macOS aren’t in ifconfig. Use scutil:

$ scutil --dns | grep 'nameserver\[' | head -3
  nameserver[0] : 192.168.1.1
  nameserver[1] : 8.8.8.8

Systematic triage: the “bottom-up” ladder

When a user says “the internet is broken”, run the ladder: first failure = broken layer.

1.  ipconfig /all                   ← Do I have an IP? Gateway? DNS?
2.  ping 127.0.0.1                  ← Is my TCP/IP stack alive?  (L3-4 loopback)
3.  ping <my own IP>                ← Is my NIC responding?      (L2 self)
4.  ping <default gateway>          ← Is my subnet reachable?    (L2/L3 local)
5.  ping 8.8.8.8                    ← Does routing work?         (L3 remote)
6.  ping google.com                 ← Does DNS work?             (L7 name-service)
7.  tracert google.com              ← Where's the hop that fails? (path)

Every step maps to an OSI layer. If ping to gateway works but ping to 8.8.8.8 doesn’t, routing is broken between your subnet and the outside. If DNS fails but ping-by-IP works, look at nslookup / dig.

Troubleshooting wireless clients (CCNA v2.0 1.6)

On Wi-Fi, check the radio link before the IP layer. A laptop can be “connected” to the wrong SSID, on a weak signal, or with a security setting that doesn’t match, and the IP checks above won’t tell you that.

Windows

C:\> netsh wlan show interfaces
C:\> netsh wlan show profiles

show interfaces describes the live connection. Read SSID (network name), BSSID (the MAC of the AP radio you joined, handy when many APs share one SSID), Radio type (802.11ac, 802.11ax and so on), Authentication (for example WPA2-Personal, WPA3-Personal, WPA2-Enterprise), Cipher, Channel and Signal (a percentage). show profiles lists saved networks. A stale profile with an old password or old security type is a common reason one SSID keeps failing on one laptop.

macOS

Hold Option and click the Wi-Fi icon in the menu bar. Under the connected network you’ll see the IP address, router, security type, channel and band, and the 802.11 mode. The same menu has Open Wireless Diagnostics, which runs checks and saves a report you can hand to the network team. From Terminal, system_profiler SPAirPortDataType prints the Wi-Fi hardware and current network details. Skip the old airport command in scripts: Apple deprecated it in macOS Sonoma 14.4.

Linux

$ nmcli device wifi list
$ nmcli dev show wlan0
$ iw dev wlan0 link

nmcli device wifi list shows every SSID in range with BSSID, CHAN, SIGNAL and SECURITY; a * in the IN-USE column marks the one you’re on. nmcli dev show wlan0 gives the address, gateway and DNS the interface received. iw dev wlan0 link shows the AP you’re associated with, the frequency in MHz and the signal in dBm. Interface names vary (wlp2s0 is common), so run nmcli device to list yours.

What to check, in order

1. Right SSID. Guest and corporate networks sit side by side, and users pick the wrong one.
2. Security type matches. A profile saved as WPA2-Personal won’t join an SSID that now allows WPA3 only. An Enterprise (802.1X) SSID needs a username and password or a certificate, not a passphrase.
3. Band and channel. Is the client on 2.4 GHz when you expected 5 or 6 GHz? Older adapters can’t see 6 GHz at all.
4. Signal. Weak signal means retries and drops. Move closer and retest before you blame the network.
5. Then the IP layer. Run the ladder above. An address in 169.254.x.x (APIPA) means the radio link came up but DHCP failed. Check the DHCP scope and the relay (ip helper-address) for the VLAN that WLAN maps to.

The #1 mistake

Assuming APIPA 169.254.x.x means “internet is broken”. That address means DHCP silently failed: your NIC assigned itself a link-local as a fallback. The wireless is up, the cable is plugged in, but no DHCP server answered. Fix DHCP (on the router / server), not the NIC.

Related deep-dives

• DHCP: how the address you see in ipconfig gets assigned
• DNS: how nslookup/dig turn a name into an IP
• ARP: how your OS learns the MAC that goes with the gateway IP
• OSI + TCP/IP: the mental model behind the ping ladder