Download eight editable, classroom-ready PowerPoint decks (104 slides total). Every deck begins with a real networking problem, presents evidence students must interpret, and ends with a verification task—not a vocabulary slideshow.
A useful networking presentation does not answer the incident on slide two. Show the opening symptom, ask pairs to identify what is known, then reveal one artifact at a time. When the evidence changes, have students revise their hypothesis in writing. The slide deck becomes a structured troubleshooting discussion rather than a list of terms to copy.
Ask every student to write one suspected failure boundary and one observation that would disprove it. A student who guesses “DNS” must explain what would make DNS unlikely.
Require a three-column note: observation, supported inference and uncertainty. A successful ping to a gateway supports local reachability; it does not prove that DNS or the application works.
Change one condition—another device fails, a DNS lookup succeeds or a traceroute hop does not respond—and ask whether the original diagnosis still holds. This is where students demonstrate transferable reasoning.
Suggested 45-minute period: 5 minutes opening incident and individual prediction; 12 minutes evidence reveals; 10 minutes paired defense of two plausible answers; 10 minutes changed-fact challenge; 8 minutes exit ticket and verification plan.
Simple formative scoring: 1 point for accurately describing the observation, 1 for a justified inference, 1 for stating a meaningful uncertainty and 1 for choosing a safe next test. Repeat across two artifacts for an eight-point check.
A networking presentation becomes more useful when each short explanation leads to an artifact students must interpret: an IP configuration, MAC table, route table, firewall rule, topology, command output, performance graph, or failure signature. The slide should create a decision. The teacher's explanation should reveal the mechanism. The next artifact should test whether students can use that mechanism.
This structure prevents a 40-slide vocabulary lecture. It also gives teachers a consistent way to move from explanation to evidence without turning every lesson into a full lab.
Not every deck needs exactly eight slides. The value is the sequence: students should know what question an artifact answers before they see it.
Use the slide for the network model, critical values, and the question students must answer. Put elaboration in speaker notes or teacher explanation. A route table is more instructionally useful than a paragraph describing route selection when students are learning to identify the longest matching prefix.
A practical test is whether a student can identify the slide's decision in five seconds. If the slide simultaneously teaches subnetting, DNS, routing, NAT, and firewall policy, split it. Networking dependencies are connected, but instruction becomes clearer when one new dependency is introduced at a time.
| Artifact | Good classroom question | What it can support | Overclaim to challenge |
|---|---|---|---|
| IP configuration | Is this endpoint configured for the intended subnet? | Address/prefix/gateway/DNS state | “The Internet must work.” |
| MAC table | Where has the switch learned this source? | Layer 2 learning/port association | “The application is reachable.” |
| Route table | Which route matches this destination most specifically? | Local forwarding decision | “The entire path is healthy.” |
| Firewall rules | Which rule matches the exact flow first? | Configured policy decision | “A permit rule guarantees the server responds.” |
| Ping result | What exchange succeeded or failed? | Tested ICMP reachability | “Every protocol works.” |
| Performance counters | Which constrained resource correlates with delay/loss? | Mechanism evidence over time | “High utilization always means congestion.” |
Swipe horizontally to see the full table.
Symptom scope → working peer → interface/link → IP/prefix/gateway/DNS → local versus remote decision → first failed dependency → targeted change → same-test verification.
Give two clients nearly identical configurations but change one consequential field, such as a wrong default gateway or prefix. Ask students to identify what will still work before asking what will fail. This forces mechanism reasoning rather than visual error spotting.
Teacher prompt: “Which successful test should we preserve instead of repeating?” Follow with: “What is the first unresolved dependency?”
Start with a requirement such as “the laptop must reach a remote learning platform with stable interactive performance.” Build slides for local/remote addressing, gateway behavior, DHCP, DNS, and then performance metrics such as throughput, latency, jitter, loss, and retransmissions.
Use a wired-versus-wireless control under the same workload. Students should explain why higher throughput does not automatically mean lower latency and why an optimization must be tested under comparable conditions.
Exit question: “What metric is actually tied to the stated user requirement, and what same-condition test verifies improvement?”
Structure the deck as Asset → Exposure → Threat → Vulnerability → Consequence → Security Need → Control → Verification. Students might choose between stronger authentication, patching, encryption, least privilege, or reducing management exposure, but the slide must state the requirement that makes one choice more appropriate.
Add both a positive and negative test. If a management service should be available only from an administrative network, students should verify that the approved source succeeds and a disallowed source remains blocked.
Draw client → Wi-Fi/Ethernet → LAN gateway → WAN/provider → remote network, then place DHCP, DNS forwarding, NAT, and firewall functions alongside the path. Present “wired works, Wi-Fi authentication fails” and ask which shared dependencies the wired success makes less likely.
A second case can show all clients reaching remote numeric IPs while names fail. Students should move to the shared DNS dependency instead of resetting healthy IP addressing.
Pair this deck with Topic 2.1: Troubleshooting a SOHO Network.
Show a topology diagram, address inventory, device/port map, configuration baseline, and capacity snapshot. Ask which artifact would shorten a future outage and which must be updated after an upgrade.
For the upgrade sequence, use Requirement → Baseline → Bottleneck → Candidate Change → Risk/Tradeoff → Implementation → Post-change Validation. Students should reject upgrades that are impressive but unrelated to the measured constraint.
Use a four-step frame sequence: receive a frame, identify VLAN, learn the source MAC, then look up the destination and forward/flood/filter. Follow with an unknown-unicast example and a broadcast example so students distinguish why each is flooded.
Then add access ports, trunks, and a selective missing-VLAN symptom. If VLANs 10 and 20 cross a trunk while VLAN 30 fails, ask why a total physical-link failure is inconsistent with the evidence.
Useful follow-up: Network Switching and VLANs Explained.
Begin with trust groups and a traffic requirement matrix. Then show source, destination, protocol, service/port, zone, state, and action. Students predict which rule should match before seeing the rule set.
Include a deliberately broad rule above a narrow rule to teach first-match/shadowing behavior. End with positive and negative tests so “fixing” connectivity by allowing everything is visibly incorrect.
Use Firewall Rules Explained for deeper rule-analysis practice.
Show several overlapping prefixes and require students to identify every matching route before selecting the longest prefix. Only compare metrics when routes are otherwise eligible and comparable for the destination.
Next, separate “route exists” from “next hop is reachable” and “forward path works” from “return path works.” A traceroute can provide path evidence, but missing responses should not automatically be labeled as failed forwarding.
Continue with Routing for AP Networking.
Rather than presenting protocols as isolated vocabulary, follow a client reaching a named service. DNS obtains an address; IP provides addressing/routing; ARP or neighbor resolution supports local delivery to the next hop; transport identifies the service conversation; Ethernet carries local frames.
Ask students where a failure can occur while earlier layers still work. For example, successful DNS resolution does not prove TCP connection establishment, and a successful TCP connection does not prove the application returns the required content.
Organize slides around questions: What is my configuration? Can I reach this destination? Where does the path change? Can the name resolve? Is the service listening? What neighbor did I learn? Which route will be selected?
Reveal output only after students select the question and command. Then require a bounded inference and a second command whose result would distinguish the remaining causes.
Show a baseline and a problem interval with utilization, throughput, latency, jitter, loss, interface errors, and queue drops. Students identify which measurements change together and which mechanism could connect them.
Contrast congestion with physical/interface errors. High offered load plus queue growth, delay, and drops tells a different story from rising CRC/interface errors at ordinary utilization. Require the same workload after the change so the comparison is meaningful.
Pair with Network Performance and Network Congestion.
Start with a required service and map every dependency. Identify a single point of failure, then add an alternate path. Ask whether the alternate depends on the same power, uplink, provider, gateway, or failure domain.
For growth, show capacity trends rather than one utilization snapshot. Students should justify when a design change is needed and then describe a controlled failover or capacity test that proves the requirement.
Useful extensions: Network Reliability and Single Points of Failure.
“Ping failed, so the network is down.” Ask what exact ICMP exchange failed and what remains unknown.
“The SSID is visible, so DHCP should work.” Ask which wireless states occur before DHCP.
“Allow any-to-any because the app works afterward.” Ask which security requirement the change violated.
The misconception should be reasonable enough to discuss. The goal is not to trick students; it is to expose the evidence boundary that separates a defensible claim from an overclaim.
| Moment | Prompt | Purpose |
|---|---|---|
| Before artifact | What would normal operation produce here? | Creates a prediction |
| After artifact | What is the smallest conclusion this supports? | Prevents overclaiming |
| Competing causes | What result would differ between these explanations? | Creates a discriminating test |
| Before change | Which evidence justifies changing this setting? | Stops random configuration changes |
| After change | What original test and control test must pass? | Builds verification discipline |
10 minutes: requirement, mechanism model, one artifact, one prediction, one exit question. 25 minutes: add a competing explanation and partner discussion. 45 minutes: give groups different artifacts, require a written claim/evidence boundary, then exchange evidence and revise conclusions.
This makes the deck reusable without padding it with extra text. The teacher changes the interaction around the slides, not the underlying networking mechanism.
Use large text, high contrast, descriptive headings, and labels in addition to color. When a configuration or command output matters, provide the text in a form students can inspect closely rather than embedding a tiny screenshot. Describe diagram relationships in speaker notes or accompanying materials.
Keep one key question per slide and avoid animations that are required to understand the final state. If animation teaches a process such as MAC learning, ensure the final sequence can also be reviewed statically.
After teaching an artifact, reuse its mechanism with changed values. A route-table lesson can become a new destination-prefix decision; a firewall lesson can change source network and rule order; a troubleshooting lesson can preserve one successful checkpoint and move the failure one dependency downstream.
A strong short response asks students to state a claim, cite exact evidence, explain the mechanism, identify what the evidence does not prove, and choose the next discriminating action.
Slide one states the requirement: a workstation must reach a server on a remote subnet. Slide two shows a working peer and the affected workstation. Both have addresses in the intended local subnet, but the affected workstation has a different default gateway. Before revealing any test result, ask students what local communication should still succeed and which traffic requires the gateway.
Slide three reveals that the affected workstation reaches a same-subnet peer but not the remote server. Students now have two pieces of mutually reinforcing evidence: local addressing is usable for local delivery, while remote delivery fails at a dependency that differs from the peer. Slide four shows the intended gateway from the network documentation. Students make the narrow correction rather than changing DNS, switch ports, or the remote server.
Slide five repeats the original remote-server test. Slide six adds a control: same-subnet communication still succeeds and the corrected gateway matches the documented design. This miniature lesson demonstrates a larger instructional principle: reveal evidence in an order that lets students eliminate causes themselves.
Start with a requirement: student devices may reach an HTTPS learning server, but they may not reach the management subnet. Show the exact source and destination networks and the required TCP service. On the next slide, present a short ordered rule set containing a broad deny above a narrower permit. Ask students to predict which rule receives the flow and to cite the fields that match.
After students identify the first matching rule, move the permit to the justified position or narrow the earlier rule according to the intended policy. Verification should include the authorized HTTPS flow and a separate attempt toward the management network that must remain denied. This prevents the common classroom mistake of treating “the application works now” as sufficient evidence that the firewall configuration is correct.
Each presentation contains an opening incident, actual-looking sample network evidence, questions students must answer before the next reveal, a changed-fact challenge and an exit ticket. The PPTX files are editable; use the notes pane for facilitation prompts. No account or email address required.
Download all 8 PowerPoints (ZIP)
Start with a cloud-document outage; contrast a working gateway and external IP test with a failing DNS lookup.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Diagnose a 169.254 address, inspect DHCP dependency and separate physical connectivity from address assignment.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Map a Wi-Fi-connected/no-Internet incident through client, gateway, WAN and ISP, then change the evidence.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Follow a frame through a switch, read a two-VLAN MAC table and diagnose a misassigned access port.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Trace one TCP 443 request through ordered rules and design a narrow change without opening unrelated traffic.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Choose the longest-prefix match, interpret a misleading traceroute and examine return-path uncertainty.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Match ipconfig, ping, nslookup and tracert to diagnostic questions; distinguish NXDOMAIN from timeouts.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Compare latency, jitter, loss and utilization against a baseline; test whether failover actually meets requirements.
Related free lesson and topic guide
Download editable PowerPoint (.pptx)Classroom-use note: These are independent, original instructional materials—not official College Board presentations or past exam questions. Example addresses, command output and incident records are fictional teaching artifacts.
Yes. All eight files are standard .pptx presentations. You can edit slides, substitute your own network screenshots and add district-specific lab directions.
Yes, the set samples skills across Units 1–4. It is not a complete yearlong curriculum: the eight decks concentrate on evidence-based troubleshooting, configuring, securing and verifying network behavior.
Upload each .pptx to Google Drive and open it with Google Slides. Review fonts, slide spacing and speaker notes after conversion.
The presentations include teacher prompts and a final debrief slide. Many incidents support more than one plausible hypothesis until the next artifact appears; use the suggested evidence chain rather than grading early guesses as absolute answers.
Yes, use and adapt them for your classroom. Consider hiding the final debrief slide before distributing student copies. These independent materials are not official College Board resources.
Use the related lesson links beside each download, then assign an evidence decision lab, troubleshooting simulator or Wrong Answer Detective to check whether students can transfer the reasoning to a new incident.
Write the requirement, expected normal result, plausible misconception, exact artifact values, discriminating question, intended correction, and verification result. Confirm that addresses, prefixes, ports, and rule order are internally consistent.
Pause before revealing outputs. Require a prediction, ask students to cite exact evidence, record competing explanations, and preserve known-good checkpoints as the scenario advances.
Ask what the evidence did not prove. A correct answer with an unjustified mechanism is an opportunity to strengthen reasoning rather than simply mark the response correct.
Save the artifact and a changed-value version. The second version can become retrieval practice, a bell ringer, an exit ticket, or a future cumulative review item.
These cards turn the page into a quick teacher-planning tool. Filter by lesson design, artifacts, questioning, troubleshooting, security, performance, or verification.