3 Network Connectivity Diagnosis
A staged method for diagnosing network connectivity, from the local interface and IP settings to routed paths and application services.
Diagnose from the source outward
proceeds from the source outward. A failure close to the source narrows the likely cause; when a test succeeds, continue to the next network segment. A network diagram can help identify the expected devices and routes along the path.
Check the interface and
Begin by confirming that the network adapter is enabled and reports a working link. Check its status on the device and, where accessible, the connected switch port.
A down or disconnected points to a local issue, such as a loose or faulty cable, a disabled interface, or a switch-port problem. A link light alone does not establish that the or routed connection is working.
Useful commands include:
Look for an enabled interface with link up. Exact status labels vary by operating system and device.
Verify
Inspect the interface’s IP address, subnet mask or prefix length, default gateway, and DNS servers when relevant. Check that the address is valid for the intended network and that the gateway is on the local subnet. A missing address, incorrect prefix, or incorrect gateway can prevent communication beyond the local device or subnet.
Use these commands to inspect settings:
For example, a device configured as 192.168.10.25/24 considers 192.168.10.0 through 192.168.10.255 local. Its configured gateway should normally be reachable on that local network. These example addresses should not be assumed to apply to a particular network.
Test reachability in stages
Use to test basic IP reachability, moving outward through known targets:
If the loopback or local-address test fails, investigate the device’s network stack or interface configuration. If local tests succeed but the gateway test fails, check the link, addressing, subnet, VLAN, or local network path. If the gateway responds but a remote IP does not, investigate routing or a failure farther along the path.
A successful shows that echo traffic received a reply; it does not prove that a particular application or service is reachable. A failed alone does not prove that the network is down, because a host or firewall may block . When service access is the issue, test the relevant application or port as well.
Trace the routed path
When a local test succeeds but a remote test fails, use a route-tracing tool to observe responding hops toward the destination:
tracert discovers hops by sending probes with increasing values. Routers may return a time-exceeded message as a probe’s TTL expires. A trace that reports an unreachable network can indicate that a router has no valid route.
A hop that does not answer is not conclusive evidence of a break. Devices may filter or deprioritize trace probes, and later hops may still respond.
Use results to narrow the fault
Use test results to choose the next checks:
Interface is down or has no link: Check the adapter state, cable, switch port, and .
Interface is up, but its address or gateway is missing or unexpected: Check , DHCP, subnet or prefix, and gateway settings.
Local tests succeed, but the gateway is unreachable: Check the local subnet, VLAN, switch path, and gateway availability.
The gateway responds, but a remote IP is unreachable: Check routes and intermediate network devices; compare the trace with the expected path.
A remote IP responds, but a named destination or application fails: Check name resolution and the application’s specific port or service.
fails but the application works: may be filtered; is not a complete service test.
Record the source device, destination, interface configuration, test commands, and exact results. Comparing these observations with the expected path—and testing in both directions when possible—helps isolate where connectivity stops.