This cheat sheet is a decision map, not a pile of isolated facts
AP Networking questions become easier when each fact answers a packet-path question. Start with the requirement, identify what the artifact proves, locate the first unresolved dependency, and choose the smallest test that can separate competing explanations.
IPv4 addressing: the host must decide local or remote before anything else
Address + prefix
The IPv4 address identifies the interface in an IP context. The prefix/mask defines the local network boundary.
Local vs. remote
Local destination: resolve the endpoint's Layer 2 address. Remote destination: deliver the first frame to an appropriate local next hop, usually the default gateway.
Gateway
A wrong gateway can preserve local communication while breaking remote delivery.
DNS
DNS translates names into records. Numeric-IP success plus hostname failure moves the unresolved branch toward name resolution.
For the full mechanism, use the IP Addressing Guide.
Subnet formulas matter because they predict boundaries and host behavior
| Prefix | Total addresses | Traditional usable hosts* | Block size |
|---|---|---|---|
| /24 | 256 | 254 | 256 |
| /25 | 128 | 126 | 128 |
| /26 | 64 | 62 | 64 |
| /27 | 32 | 30 | 32 |
| /28 | 16 | 14 | 16 |
| /29 | 8 | 6 | 8 |
Swipe horizontally to see the subnet table.
*The familiar “minus two” rule is a conventional host-count shortcut for ordinary IPv4 multiaccess subnets; always apply the actual design/context. Practice boundaries in AP Networking Subnetting.
Choose the device by the function the packet path requires
| Device/function | Primary job | Useful artifact | Do not overclaim |
|---|---|---|---|
| NIC | Endpoint network interface | Link/interface state, address config | Link up does not prove IP service |
| Layer 2 switch | Frame forwarding inside VLAN context | MAC table, VLAN/port state | MAC learned does not prove application |
| Router/L3 function | Forward between IP networks | Route table, interface state | Route present does not prove next hop |
| Wireless AP | Provide wireless access/bridge clients into network service | Association, BSSID, VLAN mapping | Association does not prove DHCP |
| Firewall/ACL | Enforce policy | Rules, counters, logs | One allowed test does not prove policy is least-privilege |
Swipe horizontally to see the device table.
Compare roles in Network Devices and Router vs. Switch.
Know what each protocol can prove when it succeeds or fails
ARP
IPv4 local-neighbor resolution. A useful artifact is the ARP/neighbor cache.
ICMP
Control and diagnostic messaging. Ping can provide reachability/RTT evidence but is not an application test.
DHCP
Dynamic configuration. DORA: Discover → Offer → Request → ACK.
DNS
Name resolution. A correct answer does not prove TCP/UDP application reachability.
TCP
Connection-oriented transport with state and reliability mechanisms.
UDP
Connectionless datagrams without TCP's connection setup/reliability behavior.
Port numbers identify common service conventions, not proof that a service works
| Service | Common transport/port | Evidence boundary |
|---|---|---|
| SSH / SFTP | TCP 22 | Port convention does not prove listener or policy state |
| HTTP | TCP 80 | TCP reachability does not prove correct web content |
| HTTPS | TCP 443 | Open TCP path does not prove TLS/application success |
| DNS | UDP/TCP 53 | Transport depends on operation/context |
| DHCP | UDP 67/68 | Server reachability by another protocol does not prove DHCP |
Swipe horizontally to see the service table.
When the exact service is the requirement, verify that service rather than stopping after a generic ping.
Switching reasoning starts with source learning, destination lookup, and VLAN scope
A trunk can carry multiple VLANs, but trunking is Layer 2 carriage—not proof of inter-VLAN routing. Use Network Switching, VLANs Explained, and MAC Address Tables.
Routing is destination-prefix matching plus a usable forwarding next step
Longest-prefix match chooses the most-specific matching route. But a matching route is only a forwarding decision—it does not prove the next hop is reachable, the packet progresses, the return path exists, policy allows the flow, or the application works. Review Routing for AP Networking.
DORA stage evidence separates client, path, relay, scope, and server failures
| Last observed stage | What is known | Next branch |
|---|---|---|
| No Discover | No visible DHCP request yet | Client/interface/link/VLAN |
| Discover reaches server | Forward request path works | Scope/server response |
| Offer generated | Server can propose configuration | Return path/client receipt |
| ACK received | Lease transaction completed | Validate supplied config/service |
Swipe horizontally to see the DHCP table.
A 169.254/16 address is evidence that normal configuration did not complete, not proof of one cause. See DHCP Explained and APIPA Explained.
Security answers require both permitted behavior and preserved denial
Start with the stated need, then choose a control with the narrowest scope that satisfies it. VLANs create Layer 2 separation, but actual inter-segment security depends on the policy governing traffic that crosses the Layer 3 boundary.
A positive test proves required traffic works. A negative test proves traffic that should remain blocked is still blocked. Use Firewall Rules Explained and Network Access Control.
Separate RF/association evidence from VLAN, DHCP, routing, and application evidence
| Stage | Evidence | Still unresolved |
|---|---|---|
| SSID visible | Network is detectable | Authentication/association |
| Associated | Wireless link joined at that stage | VLAN/DHCP/gateway |
| Valid DHCP lease | Addressing path completed | Remote routing/DNS/app |
| Gateway reachable | Local first-hop path works | Remote path/service |
Swipe horizontally to see the wireless table.
2.4 GHz often provides longer practical reach and faces more congestion; 5 GHz often provides more channel capacity. Actual results depend on interference, channel width, client capability, placement, and design. Review Wireless Networking.
Bandwidth, throughput, latency, jitter, loss, and errors describe different failure mechanisms
| Metric | Meaning | Diagnostic clue |
|---|---|---|
| Bandwidth | Nominal/available capacity context | Capacity alone is not achieved rate |
| Throughput | Achieved data rate | Compare with requirement and capacity |
| Latency | Delay | High delay can hurt interactive services |
| Jitter | Variation in delay | Important for real-time traffic |
| Loss | Packets not successfully delivered | Can trigger retransmission/service degradation |
| CRC/input errors | Corruption/link receive errors | Points toward physical/link integrity more than simple congestion |
Swipe horizontally to see the performance table.
Use Network Performance and Network Congestion Explained for deeper diagnosis.
Choose the command that answers the next unresolved question
| Command family | Question it helps answer |
|---|---|
| ipconfig / ip addr | What address/interface configuration exists? |
| ping | Does the tested ICMP reachability path work? |
| tracert / traceroute | What hop/path evidence is visible? |
| nslookup / dig | What does DNS return? |
| netstat / ss | What listeners/connections are visible? |
| arp / ip neigh | What local neighbor mappings exist? |
| route / ip route | What forwarding choices exist? |
Swipe horizontally to see the CLI table.
Practice interpretation in Network CLI Output Practice.
Redundant-looking components do not prove the service survives a failure
Reliability is relative to a named service, failure, interruption tolerance, and capacity requirement. Two links may share the same upstream dependency; a backup route may lack capacity; a failover path may bypass intended security policy.
Review Network Reliability, Single Points of Failure, and Network Scaling Problems.
Gateway works, remote HTTPS fails: do not restart at the NIC
Preserve: local addressing, first-hop reachability, and DNS result.
Next discriminating evidence: route/next-hop progression and policy/service evidence for TCP/443.
Bad answer: “Reset the adapter and change DNS.” Those actions ignore known-good evidence.
One VLAN fails across a trunk while another VLAN works
Bounded inference: the shared physical uplink is functioning to a useful degree, but VLAN-specific carriage remains unresolved.
Next artifact: trunk allowed-VLAN state and VLAN 20 existence/port membership.
A route exists but the next hop is unreachable
Conclusion: route-table presence is not forwarding success.
Next evidence: outgoing interface state, connected network, neighbor resolution, and next-hop reachability.
Low utilization plus rising CRC errors is not a congestion diagnosis
More plausible branch: physical/link integrity, cabling, optics, interference, duplex/media issues depending on context.
Verification: after the narrow repair, error counters stop increasing under comparable load and the required service recovers.
Use the same evidence discipline across every AP Networking domain
1. Define scope: one host, VLAN, site, service, or everyone?
2. Preserve successes: do not retest or change what is already meaningfully known-good.
3. Localize: find the first unresolved dependency in the packet/service path.
4. Discriminate: choose an artifact that separates competing causes.
5. Repair narrowly: change only what the evidence supports.
6. Verify: repeat the original requirement; add a negative test when policy/security matters.
Fast review: what common artifacts prove—and what they do not
| Artifact/result | Supports | Does not prove |
|---|---|---|
| Link up | Some physical/link attachment | Correct VLAN/IP/service |
| MAC learned | Switch observed source in VLAN/port context | End-to-end service |
| Gateway ping succeeds | Tested first-hop ICMP path | Remote route or application |
| Route matches | Forwarding decision exists | Next-hop/return path |
| DNS answer returned | Name resolution succeeded | Application reachability |
| TCP port succeeds | Tested transport/service path reached that stage | Every app function or security boundary |
Swipe horizontally to see the evidence table.
Use layers to localize evidence, not to turn troubleshooting into a memorization exercise
A layer model is most useful when it separates mechanisms. Physical/link evidence such as carrier state and CRC errors answers different questions from an IP route table, a TCP connection attempt, or an application response. A failure at a higher layer does not automatically imply every lower layer is broken, and success at a lower layer does not prove the higher layer works.
| Evidence | Mechanism area | Useful next question |
|---|---|---|
| Link down | Physical/link attachment | Cable, radio, interface, port? |
| MAC learned | Layer 2 switching | Correct VLAN/path? |
| Gateway reachable | Local IP first hop | Route beyond gateway? |
| TCP handshake fails | Transport/service path | Policy, listener, route, return path? |
| HTTP response wrong | Application behavior | Server/app configuration? |
Swipe horizontally to see the layer-evidence table.
Review the models in Protocols, OSI & TCP/IP Models.
Scope patterns can eliminate entire branches before you touch configuration
One host fails
Prioritize endpoint state, its access port/SSID context, local configuration, and host-specific policy before assuming a site-wide outage.
One VLAN fails
Prioritize VLAN-specific carriage, SVI/gateway state, relay/scope, routing, and policy.
One service fails
Preserve broader reachability and inspect exact transport port, listener, DNS dependency, policy, and application state.
Everything fails
Look for shared dependencies: power, upstream path, core gateway, DHCP/DNS infrastructure, provider state, or a broad policy change.
The scope is not the diagnosis, but it changes which hypotheses deserve the next test.
Forward-path success is only half of many network conversations
A route toward the destination can be correct while replies have no route back, take a path blocked by policy, or return through a stateful device that never observed the original flow. This is why “the route exists” and “the server received the packet” are not complete service verification.
When one-way evidence appears, inspect the destination's route back toward the source and any stateful policy boundary in both directions.
Replace vague troubleshooting verbs with artifact-specific actions
| Weak wording | Stronger AP Networking wording |
|---|---|
| “Check the network.” | Inspect the client's IP/prefix/gateway and compare them with a working peer on the intended VLAN. |
| “Check the switch.” | Inspect the access VLAN and MAC-table location for the affected endpoint. |
| “Check routing.” | Find the longest-prefix route for the destination, then verify the selected next hop is reachable. |
| “Check the firewall.” | Inspect the rule matching the exact source, destination, protocol, and port, including evaluation order/counters. |
| “Test again.” | Repeat the original required service under the same conditions and preserve any required negative security test. |
Swipe horizontally to see the answer-upgrade table.
Before committing to an answer, ask these ten questions
- What exact service or requirement is failing?
- Is the scope one host, one VLAN, one service, one site, or broad?
- What evidence is already known-good?
- What is the first unresolved dependency?
- Does the IP/prefix make the destination local or remote?
- If remote, what next hop and route should be used?
- If a policy is involved, what exact source/destination/protocol/port should match?
- What artifact can distinguish my leading hypothesis from the best alternative?
- What is the smallest change supported by that evidence?
- What positive—and when appropriate negative—test proves the requirement after repair?
24 AP Networking cheat-sheet flashcards
Use these for rapid retrieval across addressing, subnetting, devices, protocols, switching, routing, security, wireless, performance, CLI evidence, and troubleshooting.