Unit 2 turns endpoint troubleshooting into shared-network systems thinking
The central change is scale. A single access point, DHCP service, gateway, DNS setting, NAT rule, or firewall policy can affect many clients at once. That means the most useful first question is not “what setting should I change?” but “what is the smallest shared dependency that matches the observed scope?”
Unit 2 progresses from diagnosis to documentation, design, features, security needs, and protection
2.1 Troubleshooting a SOHO Network
Use scope and shared dependencies to localize failures without wiping out useful evidence.
2.2 Documenting My Network
Build diagrams, inventories, and addressing records that make later troubleshooting faster.
2.3 Upgrading My Network
Measure the actual constraint before selecting new hardware, coverage, or service capacity.
2.4 Advanced Network Features
Explain reservations, port forwarding, NAT, guest networks, QoS, UPnP, and related behavior.
2.5 Network Security Needs
Identify assets, trust groups, exposures, consequences, and testable requirements.
2.6 Securing My Network
Apply controls while preserving required service and verifying intended restrictions.
Trace one website request through the whole SOHO dependency chain
Each dependency creates a different symptom. DHCP failure can prevent normal local configuration. DNS failure can preserve numeric-IP connectivity. A WAN failure can preserve local printing. A firewall rule can permit DNS but block TCP/443. Unit 2 gets easier when you keep these checkpoints in order.
Do not let one plastic enclosure replace the network model
A consumer gateway may contain a Layer 3 router, NAT/PAT function, DHCP server, DNS forwarder, Ethernet switch, wireless access point, firewall, and management plane. “The router works” is therefore too broad to be useful.
| Observed success | What it supports | What it does not prove |
|---|---|---|
| Wi-Fi association | Radio/association is functioning | DHCP, DNS, WAN, or application success |
| Gateway ping | Local Layer 3 path works | WAN or remote-service success |
| Remote numeric IP works | Remote IP path exists to that target | DNS is working |
| DNS returns expected IP | Name resolution works | TCP/application access works |
Swipe horizontally to see the evidence table.
Failure scope is one of the strongest clues in the entire unit
Working components should become controls, not targets for random changes
If wired clients work while Wi-Fi clients fail, the wired path is valuable evidence. If existing DHCP clients work but new ones fail, their leases tell you something. If DNS resolves correctly but HTTPS fails, DNS should be preserved as a successful checkpoint.
The strongest Unit 2 troubleshooting stops changing known-good dependencies and moves forward from the first unresolved one.
Addressing failures often reveal themselves by who fails and when
DHCP can distribute IP address, subnet information, default gateway, DNS servers, and lease timing. If a pool is exhausted, established clients may continue with valid leases while new devices fail. If DHCP gives the wrong default gateway, many clients can receive internally consistent but unusable remote-network configuration.
A manually assigned address inside the dynamic pool can create duplicate-IP behavior. The right response is to compare scope, leases, Discover/Offer evidence, and address ownership before assigning another random static address.
Translation changes addressing at the edge but does not replace routing knowledge
SOHO clients commonly use private IPv4 addressing. NAT/PAT can translate multiple internal connections to a public address and maintain state so returning traffic is mapped to the correct internal client.
Port forwarding is different. It creates an explicit mapping for selected inbound traffic. That can satisfy a remote-access need, but it also creates exposure that must be justified and secured.
A diagram should make a future outage faster to solve
A useful SOHO diagram records the Internet handoff, gateway, switches, access points, important wired devices, subnets, SSIDs, and relevant links. An inventory can add model, management address, interface, physical location, firmware state, and ownership.
After a change, documentation becomes a troubleshooting accelerator. If one room fails after a new switch is installed, a labeled uplink map can immediately narrow the branch.
Coverage, capacity, reliability, and capability are different upgrade problems
| Evidence | Constraint | Better upgrade direction |
|---|---|---|
| Wired and Wi-Fi both slow to Internet; local transfer fast | WAN/provider | ISP plan, WAN handoff, or edge capacity |
| Wired fast; one room Wi-Fi poor with high retries | RF/coverage/capacity | AP placement, channel plan, or additional AP capacity |
| Ethernet ports exhausted | Port capacity | Switch expansion |
| Frequent gateway outages affect everyone | Reliability | Gateway quality, recovery, backup, or redundancy planning |
Swipe horizontally to see the upgrade table.
Explain the feature by what it changes in packet handling
DHCP reservation
A known client identity receives a predictable lease.
Guest network
Visitors receive a separate trust boundary.
Port forwarding
Selected inbound traffic is directed to an internal service.
QoS
Traffic can be classified or prioritized when a shared link is contended.
UPnP
Some mappings can be created automatically.
Dynamic DNS
A changing public IP can be associated with a stable hostname.
One weak shared setting can expose many endpoints
Default administrator credentials, unsupported firmware, broad port forwards, unnecessary WAN administration, weak guest isolation, and flat trust can create shared risk. The strongest analysis starts with the protected asset and the required access.
A guest may need Internet access but not storage access. An administrator may need router management from the trusted LAN but not from the public Internet. Those requirements should be explicit before the control is selected.
Security changes need two proof points
Guest isolation: guest Internet succeeds; trusted-LAN access fails.
Wi-Fi credential change: authorized devices join; old or unauthorized credentials fail.
Port-forward removal: required local use remains available; unsolicited public access fails.
Match the symptom to the smallest shared dependency
| Observation | Stronger next branch | Useful evidence |
|---|---|---|
| One client has APIPA; peers lease normally | Client/VLAN/DHCP exchange | Discover/Offer + port/VLAN state |
| All wireless fail; wired works | Wireless/AP path | SSID, association, AP uplink, VLAN, RF evidence |
| Local services work; Internet fails for everyone | WAN/gateway/provider | WAN state, default route, upstream test |
| Names fail; remote numeric IP works | DNS | Resolver setting + lookup result |
| Remote service fails after forwarding change | NAT/firewall/listener | Mapping, policy, service listener |
Swipe horizontally to see the troubleshooting matrix.
Existing clients work while every new client fails
That scope is inconsistent with a complete WAN outage. Existing leases can keep working while new devices depend on DHCP capacity or authentication. Check free scope count, DHCP Discover/Offer behavior, and intended network placement before changing DNS or ISP settings.
Wi-Fi clients fail after an AP replacement, but wired clients are normal
Preserve the wired LAN and WAN path as known-good. Investigate SSID/security settings, AP uplink, VLAN mapping, DHCP reachability, and RF behavior. Replacing the modem would ignore the failure scope.
Local printing works, but every user loses Internet access
Local switching and at least some addressing remain healthy. The shared failed dependency is beyond the local LAN. Inspect gateway WAN state, provider handoff, default route, NAT behavior, and upstream service.
One room is slow on Wi-Fi while wired testing is strong
High retries and poor throughput in one area point toward RF placement, interference, channel utilization, or local capacity. A faster ISP package does not target the measured bottleneck.
A port forward fixes remote access but widens attack surface
The feature solves one availability requirement while creating a new security exposure. Define the exact external user, protocol, destination service, and authentication needed; then restrict the mapping and verify unauthorized access remains blocked.
A full pool can create a failure that looks random until you compare old and new clients
The evidence supports scope exhaustion. Existing clients retain leases while the next device cannot obtain one. A justified fix could enlarge the pool inside the valid subnet, remove stale reservations, adjust inappropriate lease duration, or redesign the subnet if demand has outgrown it.
Changes to shared devices should be narrow, reversible, and documented
A gateway edit can affect every client behind it. Record the current state, preserve evidence, make the smallest justified change, keep a rollback path, and update documentation afterward. If one port-forward rule is wrong, do not factory-reset the router.
Combine scope, addressing, WAN, and security evidence
The WAN is known-good because wired and guest users reach the Internet. Main Wi-Fi association is also occurring. The full main-LAN DHCP pool explains why new clients fail after association. Address the DHCP capacity problem, then verify a new client receives a valid main-LAN lease, reaches the gateway, resolves DNS, accesses the Internet, and remains under the intended policy.
Build answers from scope, evidence, bounded inference, and verification
Observation: state the exact failure scope and artifact.
Known-good: preserve successful shared dependencies.
Bounded inference: identify the first unresolved shared function.
Next evidence: choose the test that separates plausible causes.
Smallest change: modify only what the evidence justifies.
Verification: repeat the original requirement under the same conditions.
Before Unit 3, you should be able to explain the system rather than memorize router menu names
- Trace a SOHO client from local attachment to a public service.
- Separate the logical functions inside a combined gateway.
- Use failure scope to choose the smallest shared dependency.
- Explain DHCP and NAT behavior from evidence.
- Document topology, addressing, and important device roles.
- Justify upgrades from measurements.
- Explain advanced features by packet behavior.
- Identify shared-network security requirements.
- Use positive and negative verification after changes.
24 AP Networking Unit 2 digital flashcards
Practice SOHO scope, DHCP, NAT, documentation, upgrades, advanced features, security, shared dependencies, and verification.