Managing global connections means proving the path one dependency at a time
Unit 4 expands troubleshooting beyond a single LAN. A client can have a healthy NIC, correct VLAN, valid IP address, and reachable local gateway while still failing because of DNS, a broken specific route, an upstream provider issue, a firewall decision, a failed remote listener, or a missing return path. The most important skill is separating what has already been proven from what remains unknown.
Unit 4 moves from diagnosis to resilient design
4.1 Failures
Use scope to locate the first likely failure domain.
4.2 Protocols & Models
Map symptoms to the mechanisms that could produce them.
4.3 CLI Tools
Choose commands because of a hypothesis.
4.4 Routing Paths
Understand prefix choice, next hops, and return paths.
4.5 Monitoring & Defense
Use baselines, logs, visibility, and controls.
4.6 Reliability & Growth
Design around failure domains and rising demand.
Who is affected often tells you where to start
One user failing to reach one application suggests a very different path from an entire site losing all external access. One subnet failing while neighboring subnets work makes subnet-specific dependencies stronger. Internal services working while all external destinations fail pushes attention toward the WAN edge, NAT, upstream routing, or provider service.
A successful gateway test changes the investigation boundary
Do not keep replacing cables after the local gateway is proven reachable. Move outward.
“The Internet is down” can hide a very narrow failure
Opening a website by name can involve DHCP-provided configuration, ARP or neighbor resolution for the local next hop, DNS, IP routing, transport behavior, TLS, and the application itself. One failed dependency can look like a universal outage to the user.
OSI and TCP/IP models are useful only when tied to evidence
The value of a layered model is not reciting labels. It is recognizing that a cable fault, wrong subnet mask, missing route, blocked TCP port, and DNS failure occur at different functional boundaries.
Run the command that answers the nearest unresolved question
| Tool | Question it helps answer |
|---|---|
| ipconfig / ifconfig / ip addr | What local configuration does this interface have? |
| ping | Can this IP path answer ICMP, and what latency/loss samples appear? |
| tracert / traceroute | Which Layer 3 hops respond along the path? |
| nslookup / dig | Does DNS return the expected result? |
| netstat / ss | Which local connections/listeners are present? |
| arp / neighbor tools | How is local IP-to-MAC resolution behaving? |
Swipe horizontally to see the CLI matrix.
A browser failure does not justify running every command
DNS is now the nearest unresolved dependency. A route dump may still be useful later, but it is not the most direct next artifact.
Routers choose the most specific matching destination prefix
A default route is a fallback. It does not override a more-specific route. This distinction explains why general Internet access can work while one remote network fails.
A healthy default route can coexist with one broken destination
If the specific next hop for 172.20.40.0/24 is unreachable, packets for that subnet can fail even while other Internet traffic follows the default route successfully.
A request arriving does not prove the reply can get back
End-to-end communication normally requires usable forwarding in both directions. If server logs prove the request arrived, many forward-path hypotheses become weaker. Investigate the server's default gateway, route table, filtering, and return-path policy.
The same flow can fail after the forward path succeeds
Asymmetry matters because a firewall may track session state, one provider may have a different return route, or the destination may send replies toward an unexpected gateway. “Request reached server” is powerful evidence because it moves the uncertainty downstream.
A number has meaning only relative to normal behavior
Seventy percent utilization is not automatically healthy or unhealthy. If an uplink normally sits at 15% and jumps to 70% while latency and output drops rise, that deviation matters. If a scheduled backup routinely creates the same pattern without service degradation, the number has different meaning.
Combine utilization, latency, loss, errors, and service checks
One metric is a clue. Several aligned metrics are evidence.
Security depends on visibility as well as prevention
Firewalls and ACLs block prohibited flows, but logs and monitoring explain what happened. Segmentation limits lateral movement. Secure management protocols reduce administrative exposure. Authentication failures, configuration changes, scans, and unusual traffic all become more useful when they are timestamped and attributable.
Too little logging hides evidence; too much can bury it
Useful logs should preserve enough context to identify the source, destination, action, rule, event time, and relevant device state. Logging every harmless event without prioritization can make meaningful incidents harder to find.
Redundancy should protect a specific failure domain
Adding a second component helps only if it reduces the effect of a meaningful failure. Two routers on one power source still share that power dependency. Two ISP circuits in the same conduit may fail together. Two application servers behind one storage array still share storage risk.
Mark single points of failure along the service path
Scale can turn a previously healthy design into a capacity problem
More endpoints consume DHCP leases, switch ports, wireless airtime, uplink capacity, firewall state, address space, and administrative attention. Growth also increases the impact of shared dependencies.
DHCP exhaustion can be a growth problem, not a DHCP-service failure
The service may be functioning normally while the pool is no longer large enough for demand.
Remote IP works, hostname fails
Useful routed IP connectivity exists. DNS becomes the strongest next dependency. Replacing the Ethernet cable contradicts the evidence.
Specific remote subnet fails while Internet works
Longest-prefix logic explains why the broken specific route wins over the default.
DNS and firewall are healthy, but the remote listener is missing
The first directly demonstrated failed dependency is the remote service listener.
Server receives the request but the client never receives the reply
The forward path is substantially proven. The return path is the first demonstrated failure.
Monitoring shows a new pattern before users complain
Capacity planning can act before the circuit reaches sustained saturation.
Read artifacts as a sequence that moves the uncertainty boundary
| Artifact | What it substantially proves | What remains |
|---|---|---|
| Valid IP config | Local addressing is configured | Gateway reachability |
| Gateway ping succeeds | Local path to gateway works | Remote routing/service |
| Remote IP succeeds | Useful routed IP path exists | DNS/application-specific dependencies |
| DNS resolves | Name resolution works | Transport/TLS/application |
| Firewall allows | Policy permitted the observed flow | Listener, return path, app behavior |
Swipe horizontally to see the evidence chain.
What did not fail can be just as useful
If interface errors stay at zero during a latency spike while utilization reaches saturation, damaged media becomes weaker than congestion. If one VLAN works across a trunk while another does not, a dead cable becomes weaker. If the server logs the request, a source-side switch failure becomes weaker.
Move from mechanism to artifact to decision
Strong Unit 4 answers stop exactly where the evidence stops
Instead of saying “the network is down,” say: “The client reaches the gateway and a remote IP, but DNS queries time out, so local connectivity and basic routed IP reachability are substantially proven while DNS is the first unresolved dependency.”
24 AP Networking Unit 4 digital flashcards
Practice failure scope, protocol dependencies, OSI/TCP-IP reasoning, CLI tools, longest-prefix routing, return paths, monitoring baselines, security visibility, redundancy, growth, and evidence chains.