7 Essential Windows & Linux Commands to Diagnose Network Outages

Step 1: Basic Checks

Is the local configuration correct? (ipconfig / ifconfig)

On Windows, open CMD and run ipconfig /all to view IP address, subnet mask, default gateway, and DNS servers. Verify that the IP is in the correct subnet, that a gateway is present, and that DNS points to a public server such as 8.8.8.8.

Is the IP in the expected range?

Is there an automatically assigned address (169.254.x.x) indicating no DHCP lease?

Is the default gateway correct?

Are public DNS servers configured?

Common fixes: ipconfig /release + ipconfig /renew to obtain a new lease, or manually set the correct parameters.

On Linux, run ifconfig or ip addr show and check the output of ip route for IP, mask, and gateway.

Step 2: Test Connectivity

Can you ping? (ping)

Use ping to verify reachability at different layers:

Ping the loopback address: ping 127.0.0.1 – tests the TCP/IP stack.

Ping the default gateway: ping 192.168.1.1.

Ping another internal host: ping 192.168.1.10.

Ping a public IP: ping 8.8.8.8.

Ping a domain name (also checks DNS): ping www.baidu.com.

Advanced options: ping -t for continuous ping, ping -n 100 to send 100 packets and view loss rate.

Step 3: Check Layer‑2 Mapping (ARP)

Are there ARP issues? (arp)

ARP resolves IP to MAC addresses. On Windows, run arp -a to view the ARP cache; on Linux, use arp -n. Verify that the gateway MAC matches the switch’s MAC table and that no duplicate IPs map to different MACs.

Clear the cache on Windows: arp -d *.

If ARP spoofing is suspected, use anti‑ARP tools or bind static ARP entries.

Step 4: Trace the Path

Where does the break occur? (tracert / traceroute)

Use tracert 8.8.8.8 (Windows) or traceroute 8.8.8.8 (Linux) to display each hop. The -d flag on Windows skips DNS lookups for faster results.

Interpretation:

All hops respond with low latency – the path is healthy.

Timeouts or asterisks indicate a broken link, firewall block, or a host that does not respond to ICMP.

High latency or packet loss on a specific hop points to congestion at that node.

Step 5: View Connection State

Are ports listening? (netstat)

On Windows, netstat -an lists all connections and listening ports; netstat -rn shows the routing table; netstat -s provides statistics such as packet loss. On Linux, ss -tuln is a faster alternative.

Check that the target service port is in LISTENING state.

Look for many TIME_WAIT or SYN_SENT entries, which may indicate connection problems.

Step 6: Verify Routing Table (route)

Is the routing correct? (route)

Windows: route print. Linux: route -n or ip route. Ensure the default gateway (0.0.0.0) points to the correct next hop.

Fixes: add a static route with route add or delete an incorrect entry with route delete. Example: a multi‑NIC server may route external traffic to an internal NIC; adjusting the metric resolves the issue.

Step 7: Test DNS Resolution (nslookup)

Is DNS working? (nslookup)

If a website fails but ping to its IP succeeds, DNS is likely the culprit. Run nslookup www.baidu.com to query the default resolver, or nslookup www.baidu.com 8.8.8.8 to query a specific DNS server.

Interpretation: a correct IP address in the response means DNS is functional. Fixes include changing the DNS server to a public one such as 8.8.8.8 or 114.114.114.114.

Overall Diagnostic Flow

Check physical layer: verify link lights, replace cables or ports if needed.

Run ipconfig (Windows) or ifconfig (Linux) to confirm local configuration.

Ping sequence: loopback → gateway → public IP → domain name.

Inspect ARP cache with arp -a / arp -n.

Trace route with tracert / traceroute.

Examine connections and routes using netstat / ss and route.

Validate DNS with nslookup.

If the entire company experiences a total outage, prioritize checking core devices (router, switch logs), broadcast storms, or possible malware infections.