4 Network Configuration Problems
Diagnose network configuration failures by checking client settings, VLANs, gateways, routes, DHCP, and DNS in a systematic order.
Start with the client
A computer can be unreachable because of configuration even when its cable, wireless link, and network adapter appear to work. Diagnose from the client outward: check the client’s settings and local network first, then the gateway, routes, and services needed to reach the destination. Change one setting at a time and record the original configuration.
Inspect IP settings
Identify the affected adapter and check its , or prefix length, , status, servers, and suffix. On Windows, display adapter configuration with:
Check the active adapter rather than a disconnected, virtual, or VPN adapter. Compare its settings with a known-working device on the same network or with the organization’s addressing plan.
Check the address and mask
An identifies an interface. The , or a prefix length such as /24, identifies the network portion of the address; together, they determine whether a destination is considered local or should be reached through a router. CIDR prefix notation expresses IPv4 network sizes.
For example, a client configured as 192.168.10.25/24 belongs to 192.168.10.0/24, and a gateway at 192.168.10.1 is in that subnet. If the client is mistakenly configured with /16, it may treat some addresses in 192.168.x.x as local and try to contact them directly rather than sending traffic to its router. A wrong mask can therefore cause selective failures rather than total disconnection.
Recognize address problems
Look for an address outside the expected subnet or address pool, a duplicate static address already in use, or a mask or prefix that differs from the network plan. On a Windows IPv4 client, an automatic private address such as 169.254.x.x when was expected often indicates that the client did not obtain a lease. Check the link, , availability, and relay path before assigning a static address.
Private IPv4 ranges are intended for private internets; an address from such a range does not by itself show that the client has working Internet access.
Verify the
The is the next hop for destinations without a more specific route. Its address must be reachable on the client’s local IP network. A wrong gateway can leave communication within the local subnet working while preventing access to other networks.
Check that the gateway is correct for the client’s subnet and . You can test it with:
Interpret a failed ping cautiously because a router or firewall may block ICMP even when other traffic works. If the gateway is unreachable, check the client’s address and mask, switch-port , local link, and gateway interface before changing routes.
Check VLANs and trunks
A is a logical Layer 2 network. Devices in different VLANs generally need a router or Layer 3 switch to communicate. A client in the wrong may receive an address for the wrong subnet, fail to reach its expected gateway, or be isolated from peers.
Check that the client’s switch port is assigned to the intended access and that the exists and is active on the relevant switches. Links between switches and to routing devices must be configured as trunks when required. Confirm that the required is allowed across each trunk and that trunk settings, including the native where used, match at both ends. Also verify that the gateway interface or switched virtual interface for the client’s is up and has the expected .
Inspect routes and return paths
Routers and hosts use a to decide where to send packets. A route includes a destination prefix and a next hop or outgoing interface; a default route handles destinations without a more specific match. When several routes match, the most specific prefix is normally preferred.
Check the client’s route table and the relevant router’s . On Windows, use:
On Cisco IOS, use:
Verify that the destination network has a usable route, that the next hop is correct and reachable, and that a default route is present when required.
Check the path in both directions
Check the as well as the route toward the destination: the destination network needs a route back to the client’s subnet. A one-way route can cause timeouts even when packets reach the destination.
On Windows, tracert <destination> shows which hops respond along a path:
A missing response at a hop does not prove that the hop is broken, because routers may not answer trace probes. A reported “destination net unreachable” can point to a missing or incorrect route.
Verify
If the client should use , confirm that is enabled on the correct adapter and that the client receives the expected address, mask, gateway, and settings. On Windows, release and renew the lease with:
If renewal fails, investigate the server or scope, address availability, , and any relay between the client subnet and server. can supply more than an , including the and server addresses.
Check and other client settings
If a service works by but not by host name, check name resolution. Verify that the configured server addresses are correct and reachable, and that the suffix is appropriate for the network. Test a lookup with:
nslookup queries the configured server rather than relying on the client’s cache. If the server is reachable but a stale or negative cached result is suspected, Windows can clear the cache with:
Also check other settings relevant to the failure, including VPN routes, proxy configuration, interface metric, and whether an unintended adapter is carrying traffic. Check the intended configuration before changing , proxy, or VPN settings.
Follow a diagnostic sequence
Use an ordered process so that each test narrows the possible cause:
Define the scope. Determine whether one device, one , one destination, or many users are affected. Record what works and what fails.
Inspect the active adapter. Check link status and record its , mask, gateway, status, servers, and suffix.
Test from local to remote. Test the local TCP/IP configuration, another host on the same subnet, the , a remote , and then the remote host name. Ping can fail because of ICMP filtering, so test the actual application or port when appropriate.
Compare with a working peer. Differences in subnet, , gateway, , , or VPN settings can reveal a misconfiguration.
Inspect switching and routing. Confirm membership and trunk carriage, then verify routes to the destination and back.
Correct one cause and retest. Preserve the old settings, make the smallest appropriate change, and confirm both the original failure and related connectivity.
Use symptoms to focus checks without treating them as proof of a particular cause:
No valid lease or unexpected address: Check enablement, scope availability, , relay, and link.
Local devices work but remote networks fail: Check the mask, , default route, and gateway interface.
Some local devices fail unpredictably: Check for a duplicate address, incorrect mask, or wrong .
Same-subnet peers fail across switches: Check access , trunk mode, allowed VLANs, and native mismatch.
IP connectivity works but host names fail: Check the server, suffix, stale cache, and host record.
One remote network fails: Check its specific route, next hop, filtering, and return route.