IPConfig is most useful when you interpret relationships, not isolated fields
A Windows ipconfig display is not a checklist where every line can be judged independently. IPv4 address, subnet mask, default gateway, DNS servers, DHCP state, lease times, adapter identity, and multiple-interface behavior all interact. The strongest analysis asks whether those fields make sense together and then chooses the next test that targets the first unproven dependency.
Each IPConfig field answers a different troubleshooting question
IPv4 + Mask
What local subnet does the host believe it belongs to?
Gateway
Where does the host send remote IPv4 traffic?
DNS
Which resolver will answer name queries?
DHCP Enabled
Was configuration expected to come dynamically?
DHCP Server
Which server supplied the current lease?
Lease Times
When was configuration obtained and when must it be renewed?
Wrong default gateway for a /26
A /26 creates blocks of 64 addresses. 192.168.14.77 belongs to 192.168.14.64/26, whose usable hosts are .65 through .126. The gateway .1 is in the previous subnet, 192.168.14.0/26.
Show the block calculation when the prefix decides the answer
This calculation is much stronger than saying the gateway “looks wrong.”
APIPA with no gateway
The client self-assigned a link-local IPv4 address because normal expected configuration was unavailable. The blank gateway explains why ordinary remote IPv4 communication is unavailable from this configuration.
Use peers and DHCP artifacts to narrow the failure boundary
Valid addressing, wrong DNS server
Because local and remote numeric-IP connectivity work, DNS becomes a much stronger branch. Compare queries to the configured resolver and the intended resolver before changing routing.
Wrong DNS can break names without breaking IP reachability
A client can have a perfectly valid address, mask, and gateway while name resolution fails. That is why successful numeric-IP testing is a powerful control: it preserves the Layer 3 path while isolating the resolver branch.
The DHCP lease reveals where the configuration came from
The DHCP server does not need to live in the same subnet as the client. Relay can forward requests across routed boundaries. A remote server address therefore does not prove rogue DHCP.
Lease timestamps turn a static snapshot into a timeline
Lease Obtained tells you when the current dynamic configuration arrived. Lease Expires tells you how long the current address remains valid if renewal fails. These fields are especially valuable when a client works now but loses connectivity later.
Multiple adapters create competing default paths
Two active adapters each advertise a possible default path. The route table and interface metrics decide which path actually wins. ipconfig shows the competition but not the final route decision.
route print or the equivalent routing table before disabling adapters at random.IPConfig describes interface configuration; it does not replace the route table
A host may have several gateways, VPN adapters, virtual NICs, and local routes. Route specificity and metrics determine forwarding. A correct-looking gateway line on one adapter does not prove traffic actually uses that adapter.
Correct-looking fields still need a reachability test
These values are internally plausible, but ipconfig cannot prove that 172.20.8.1 answers ARP/ping or that 172.20.1.53 is reachable. “Looks correct” is not the same as “works.”
The mask is too broad, so a remote destination is treated as local
With /16, the client treats 10.20.40.50 as local and may ARP for it instead of sending traffic to the gateway. A route problem elsewhere may not be the first issue; the host's own local/remote calculation is wrong.
The mask is too narrow, so a local peer is treated as remote
A /27 splits the /24 into smaller local networks. The host may send traffic for a physically local peer toward the gateway because its configured prefix says that peer is remote.
The client has a valid lease—but from the wrong subnet
This can indicate wrong VLAN placement, wrong DHCP scope selection, relay mapping, or rogue DHCP. The fact that the client received a valid lease means the problem is not simply “DHCP unavailable.”
DHCP is enabled, but the address is static-looking and stale
The client is still configured, but the lease is about to expire. If renewal has been failing, the symptom may not appear until minutes later. Capture DHCP and route state before the lease lifecycle changes.
IPv4 is healthy, but IPv6 is only link-local
An IPv6 link-local address proves only local-link IPv6 identity. It does not prove global IPv6 connectivity. If the application prefers IPv6, compare IPv4 and IPv6 behavior rather than assuming the entire network is down.
An IPv6 gateway may legitimately be link-local
Unlike a typical IPv4 default gateway, an IPv6 next hop commonly appears as a fe80::/10 link-local address. Students should not mark a link-local IPv6 gateway as wrong simply because it is not globally routable.
Disconnected adapters are useful negative evidence
The disconnected Ethernet adapter cannot be the active IPv4 path at that moment. This helps eliminate one competing interface and keeps the analysis focused on Wi-Fi and the route table.
A VPN adapter can silently change DNS and routing behavior
IPConfig can reveal the new adapter and resolver, but the route table is still needed to see which prefixes move into the tunnel. This is a classic case where interface data and route data must be combined.
A working peer turns IPConfig into a configuration-diff tool
| Field | Affected client | Working peer | Meaning |
|---|---|---|---|
| IPv4 | 10.22.6.41 | 10.22.6.55 | Same subnet plausible |
| Mask | /24 | /24 | Prefix matches |
| Gateway | 10.22.6.1 | 10.22.6.1 | Gateway matches |
| DNS | 192.168.1.1 | 10.22.2.53 | Resolver mismatch |
Swipe horizontally to see the peer comparison.
Know what IPConfig can prove—and what it cannot
| IPConfig evidence | What it proves | What remains unproven |
|---|---|---|
| Valid IPv4 address | Address is configured | Gateway reachable |
| Default gateway listed | Host has a gateway setting | Gateway works |
| DNS listed | Resolver is configured | Resolver reachable/correct |
| DHCP server listed | Lease source reported | Relay/path currently healthy |
| Two gateways shown | Two interfaces advertise paths | Which route wins |
Swipe horizontally to see the artifact-boundary table.
Let the artifact choose the next test
| IPConfig clue | Next best test |
|---|---|
| APIPA | Compare peer + inspect DHCP path/logs |
| Gateway outside subnet | Verify intended mask/gateway |
| Numeric IP works, names fail | Query configured and intended DNS |
| Multiple gateways | Inspect route table and metrics |
| Fields look plausible | Test gateway reachability |
| Lease near expiration | Observe renewal/DHCP behavior before state changes |
Swipe horizontally to see the next-test matrix.
Do not call every 10.x or 192.168.x address “correct”
Private addressing only tells you the address belongs to a private range. The mask, gateway, VLAN, and intended design still decide whether it is correct for this client.
Do not treat the DHCP Server field as proof the server is local
Relay exists specifically so remote servers can serve client subnets. A remote server address can be perfectly normal.
Do not disable adapters before checking route selection
Disabling interfaces may make the symptom disappear while destroying the evidence you need to understand why traffic chose the wrong path. Capture the route table first.
Do not stop at “looks correct”
Configuration plausibility is only one checkpoint. You still need operational tests. A correctly formatted gateway can be down. A correct DNS address can be unreachable. A valid lease can be on the wrong VLAN.
State the decisive relationship and the next unproven dependency
Strong answers are specific: “192.168.14.77/26 belongs to 192.168.14.64/26, but gateway 192.168.14.1 is outside that subnet, so verify the intended gateway or mask before testing DNS.”
One IPConfig output can contain more than one clue
The right answer is not “wrong DNS” yet. The output shows two plausible resolver paths and multiple interfaces. Route and DNS tests are needed to determine which configuration is active for the failed query.
24 IPConfig Output Analysis digital flashcards
Practice subnet math, gateways, APIPA, DNS mismatches, DHCP lease fields, multiple adapters, IPv6 clues, route-table boundaries, peer comparison, and next-test selection.