The final session of the course, and it is unlike all the previous ones. There are no more sections by topic, no hints about which lesson to review, no "subnetting" or "DNS" exercises: there are incidents. Four complete cases — two at Grupo Meridiano, two at Clínica Azahar, on the network you yourself designed in the previous session — told the way they arrive in real life: a user describing a symptom in their own words, some command outputs, and nobody telling you which layer the problem is in. Your job is to apply module 6's methodology (define, reproduce, hypothesize, test, apply, verify, document) leaning on everything learned in modules 1 through 5. It is the course's unofficial final exam — and the exact format of your future day-to-day.

1. How to work through these cases
2. Case 1: the new Torrevieja PC that "has Internet but no records"
3. Case 2: "the Internet is down" at Meridiano Valencia
4. Case 3: the medical records server that comes and goes
5. Case 4: the new Elche router
6. Common mistakes when diagnosing
7. Conclusion: end of the course

• Each case has four parts: context, symptoms, data (real command outputs) and guided questions. The worked solution comes afterwards — and here, more than ever: don't look at it until you have your diagnosis written down, suspect layer and root cause included.
• Work with the 7-step method from lesson 06-03. The guided questions follow its order; if you get stuck, go back to the golden question: who is affected and what changed?
• Keep your addressing plans at hand: Meridiano Valencia's /24 (192.168.10.0/24, router .1, server .10, DHCP .100–.199) and your Azahar VLSM plan from lesson 07-05 (Alicante 172.20.40.0/26, waiting room .64/27, Elche .96/28, Torrevieja .112/28, tunnels .128/30 and .132/30). In these cases, knowing the plan is half the diagnosis: several clues are only visible to whoever knows what should be there.
• Note down which modules you use in each case. At the end you'll see that none of them is solved with a single module — that's the whole point.

Azahar is already running on the VLSM plan you designed in the previous lesson. On Monday a physiotherapist joins the Torrevieja branch clinic and the medical records software vendor installs her PC. Since the installer "didn't trust DHCP", he configured the network by hand.

Tuesday, 9:40. The new physio calls: "I can browse the Internet just fine, but the records program says cannot connect to the server. Everything works for my colleague at the next desk".

On the new PC:

On the colleague's PC (working): 172.20.40.115, mask 255.255.255.240, gateway 172.20.40.113, all via DHCP.

1. Before touching anything: what does the pattern "Internet yes, records no, and only on this machine" tell you? What does it rule out?
2. Compare the new PC's ipconfig with your Torrevieja addressing plan. Which field is wrong?
3. Why does the ping to the server fail with "Destination host unreachable" from the PC's own IP, and what role does ARP play in that message?
4. Why, with that very same configuration error, does the Internet work perfectly?
5. State the root cause, the model layer, the fix and how to prevent a recurrence.

Step 1 — define and scope. It affects a single machine (the colleague is working) → the cause lives at that desk. That something works (the Internet) rules out the physical layer, the switch and the branch clinic's WAN egress in one stroke: it is not "the Torrevieja network", it is this PC talking to that destination. The fact that "it was configured by hand yesterday" (what changed) points straight at the configuration.

Step 2 — reproduce. Done in the data: the gateway responds, the server doesn't — and the message is not a shy "Request timed out", but "Destination host unreachable" issued by the PC itself (look closely: "Reply from 172.20.40.120", its own address). That means the PC never even tried to send the packet far away: it decided it didn't know how to deliver it.

Step 3 — hypothesis. Checking against the plan: Torrevieja is 172.20.40.112/28, mask 255.255.255.240. The PC has mask 255.255.255.0. Hypothesis: wrong mask — the PC believes ALL of 172.20.40.0–255 is its local network.

Step 4 — test (understand the mechanism). With /24, module 5's AND tells the PC that 172.20.40.10 is on its own LAN → instead of sending it to the gateway, it fires an ARP onto the Torrevieja cable asking "who has 172.20.40.10?". But the server is in Alicante, on the other side of the tunnel: nobody in Torrevieja answers that ARP. With no destination MAC there can be no frame, and the system declares "Destination host unreachable" — which is why arp -a shows no entry for .10. The gateway .113 does respond because it happens to sit inside both versions of the network (the real /28 and the imaginary /24): the error stays masked in exactly the most common check. And the Internet works because any public destination (e.g. 198.51.100.60) falls outside even the imaginary /24 → that traffic does go to the gateway, which pushes it out through NAT completely normally. The failure only hits remote 172.20.40.x destinations: records, other sites' printers… exactly the symptom.

Steps 5 and 6 — apply and verify. The mask is corrected to 255.255.255.240 (better still: the PC is switched to DHCP, like the rest of the branch clinic):

~39 ms and TTL 62 (64 − 2 routers: Torrevieja's and Alicante's): the packet now crosses the tunnel. The records program connects. The physio confirms.

Step 7 — document. Root cause: wrong subnet mask (/24 on a /28 subnet) in a manual configuration — layer 3, addressing configuration. Prevention: branch clinic workstations are configured via DHCP (with a reservation if the software demands a fixed IP), and every external vendor gets the addressing plan sheet before installing anything. It is, almost literally, the NAS case from lesson 05-02 — seen now from the chair of the person diagnosing it.

Modules used: 2 (ARP), 5 (masks and the AND), 6 (method and reading ping/arp).

Wednesday, 8:55. Reports start arriving in a chain from Valencia: "there's no Internet". Marta, Ana, administration — everyone. In Bilbao, Jon confirms everything works there. Nobody remembers any change… until someone mentions that the Valencia router "updated itself" overnight (an automatic firmware update scheduled by the ISP).

No website opens ("server not found"). Email is down too. And — a curious detail contributed by an observant user — the intranet doesn't open by name either, but an old bookmark pointing to https://192.168.10.10 does work.

From Marta's PC:

1. The second ping is the hinge of the entire case: what does ping 1.1.1.1 answering in 9 ms prove?
2. What do the two nslookups tell you, combined? Be precise: which exact component is failing and which is healthy?
3. How does the clue "the intranet doesn't work by name but does by IP" fit in?
4. Which layer do you place the problem in, and what is the most likely root cause, given what changed overnight?
5. What permanent improvement would you propose when documenting? (Hint: remember how case C in lesson 06-03 ended.)

Step 1 — define and scope. It affects all of Valencia, "the whole Internet", with Bilbao healthy → the cause is in something shared in Valencia (router, DHCP, DNS, WAN egress). Known change: the router's firmware overnight.

Steps 2 and 3 — reproduce and refine the hypothesis. Here is the case's finesse: "there's no Internet" turns out to be false. ping 1.1.1.1 answers: there is cable, there is a switch, there is an IP, there is a gateway, there is NAT and there is WAN egress — layers 1 to 3 out to the Internet are intact. What doesn't work is the thing that turns names into addresses: the DNS query to the configured server (the router, 192.168.10.1) times out, yet the same query to 8.8.8.8 resolves instantly. Exact translation: the network is fine and the external resolver is fine; what has died is the Valencia router's DNS service. The intranet clue confirms it by another route: by IP it works (healthy network, healthy server), by name it doesn't (nobody resolves intranet.grupomeridiano.example — the internal DNS is the same router service). And it explains why "there's no Internet" for the user: without DNS, no URL opens; to a human, that is the Internet being down.

Step 4 — test. In the router's panel, the DNS forwarder service shows as stopped since the 4:12 firmware update (the router's logs confirm it — the "what changed" from step 1 was the cause, as it almost always is).

Steps 5 and 6 — apply and verify. The router's DNS service is restarted (and automatic updates at uncontrolled hours are disabled, rescheduled into a maintenance window with advance notice). Verification with the command that used to fail: nslookup www.proveedor-cloud.example against .10.1 resolves, websites open, the intranet is back by name. Confirmed with two users.

Step 7 — document. Root cause: the router's DNS service stopped after a firmware update — application layer (DNS), with the network beneath it intact. Permanent improvement: after case C in module 6, Meridiano left a single DNS server (the .10.1) in DHCP — today that decision came due: one dead service left the whole site "without Internet". A healthy secondary DNS (e.g. the ISP's resolver) is added to the DHCP options: with the primary down, machines would have taken a few seconds longer… but they would have worked. And the pocket lesson, forever: faced with "there's no Internet", separate connectivity from resolution — one ping to an IP and one nslookup are worth more than twenty reboots.

Modules used: 2 (DNS), 4 (what a ping validates, layer by layer), 5 (NAT was still doing its job), 6 (method, cross-checked nslookup).

Azahar, Alicante headquarters. First thing Tuesday, an electromedicine vendor installs a new network-connected ultrasound scanner in treatment room 2, to archive the images. The installer leaves it working and goes. "I gave it the IP we always use on installs", he remarks on the way out.

From 12:30, intermittent reports from all three sites: "the records program hangs for a while and then comes back on its own". Sometimes it works for minutes at a stretch; sometimes it cuts out mid-record. Rebooting the PC "sometimes fixes it" (and sometimes not — the classic of intermittent problems).

From the Alicante reception PC (172.20.40.21), a sustained ping to the server:

The same PC's ARP table, checked twice, three minutes apart:

And on the medical records server itself (Linux), the system log is screaming:

A quick capture on the server (module 6, with authorization) completes the picture:

1. What does it mean that the MAC associated with 172.20.40.10 changes between two arp -a checks?
2. Why are two replies to the same ARP Request the definitive proof? Which device is each MAC?
3. Explain the intermittency precisely: why does it work in bursts, and why does "rebooting sometimes fix it"?
4. Which layer(s) do you place the problem in? What is the root cause — the technical one and the process one?
5. What would you do to resolve it and to keep it from happening again?

Step 1 — define and scope. It affects all sites but a single service (records) and intermittently → the shared suspect is the server or its segment. What changed today? The ultrasound scanner install mid-morning; the reports start right after. The time correlation is the master clue.

Steps 2–4 — reproduce, hypothesis, test. The intermittent ping -t matches the app that "comes and goes". And the ARP table gives it away: one IP cannot have two MACs — if the entry for 172.20.40.10 flips from aa-4c-… to 00-1f-…, there are two devices claiming the same IP address. The capture is the irrefutable proof: to a single "who has .10?", two machines reply. The MAC aa-4c-52-… is the medical records server; 00-1f-5b-… turns out to be the freshly installed ultrasound scanner — with the static IP 172.20.40.10, the same as the server's, because the installer used "the usual one" without consulting the plan.

The mechanism of the intermittency, with what module 2 taught: every machine on the network stores the IP→MAC pair in its ARP cache. Depending on who answered last, each PC's cache points at the server (everything works) or at the scanner (packets "for the server" land on an ultrasound machine that knows nothing about records: hangs and timeouts)… until the entry expires, the question is asked again, and the winner can change. That is why each machine fails at different moments, and why rebooting "sometimes" fixes it: it flushes the ARP cache and reruns the lottery. Nothing is "broken": there are two neighbors with the same street number, and the mail carrier delivers to a different one each time.

Steps 5 and 6 — apply and verify. The scanner's IP is changed to 172.20.40.12 (free in the plan's static range) and the cache is flushed where urgent (arp -d, or wait for expiry). Verification: ping -t to .10 for 15 minutes without a single loss, arp -a stable with the server's MAC, and the server log with no new duplicate warnings. All three sites confirm.

Step 7 — document. Technical root cause: duplicate IP address (a repeated static) — a layer 3 problem that manifests and gets diagnosed at layer 2 (ARP), right on the seam we practiced so much. Process root cause, the real one: a device was plugged into the network without consulting the addressing plan. Prevention: the VLSM plan from 07-05 gets printed and posted in the comms cabinet and included in the documentation handed to every vendor; static IPs are requested, not chosen. The technical fix closes the incident; the process fix prevents the next one.

Modules used: 2 (ARP and its cache), 5 (the addressing plan), 6 (sustained ping, capture, method).

A storm knocks out the Elche branch clinic's line on Sunday. First thing Monday, an ISP technician replaces the fiber equipment with a new "all-in-one" router and leaves with "the Internet working". Packing up, he remarks: "that old box in the cabinet — I've left it disconnected, it's not needed anymore".

Monday, 10:15, Elche calls: "the Internet works perfectly, but we can't open records from any machine. And the network printer has vanished from the PCs".

From an Elche PC:

In the comms cabinet: the new ISP router, with the branch clinic's switch plugged into its LAN ports… and the clinic's router (the one that maintains the VPN tunnel with Alicante and the plan's DHCP) powered off and unplugged on the shelf: the "old box that's not needed anymore".

1. Look at the ipconfig with your Elche plan in front of you (172.20.40.96/28). What is the first thing that jars, before even thinking about causes?
2. Where did that 192.168.1.x configuration come from? Why did the machines accept it without complaint?
3. Why does the Internet work beautifully while records and the printer have vanished? Where do the packets toward 172.20.40.10 go (and where do they die)?
4. What is the root cause, and at which layer was the problem born?
5. Propose the correct repair. What additional problem would appear if the clinic's router were simply plugged in behind the new ISP router, as is?

Step 1 — define and scope. A whole site, following a physical intervention this morning. The "what changed" is obvious; the question is what changed exactly. Bottom-up without a second thought: there were hands in the cabinet.

Steps 2 and 3 — reproduce and hypothesize. The ipconfig is the master clue for whoever knows the plan: an Elche PC must live in 172.20.40.97–.110, and this one has 192.168.1.34 — an address that does not exist in Azahar's plan. With the cabinet detail, the story reconstructs itself: the ISP technician plugged the branch clinic's switch into the LAN ports of his new router, which ships from the factory with its own DHCP (192.168.1.0/24). The PCs, renewing their lease in the morning, accepted the offer from the only DHCP present — DORA asks no loyalty questions: whoever answers first wins. And the clinic's router — the VPN tunnel endpoint, the gateway 172.20.40.97, the legitimate DHCP for the /28 — was left unplugged: as far as the network is concerned, Elche is no longer Elche; it is "one more household" hanging off a home router.

Step 4 — test (confirm the mechanism). The Internet works because the ISP router does NAT perfectly competently: for browsing, any network with an exit will do — "the Internet works" does not validate your network; it validates any network. But 172.20.40.10 is no longer "on the other side of the tunnel", because there is no tunnel: the tracert shows the packet entering 192.168.1.1, which has no route whatsoever to 172.20.40.0/24 → it sends it out its default route toward the ISP, where a private RFC 1918 destination dies without appeal (module 4, the route that disappears; module 5, addresses unroutable on the Internet). The "vanished" printer is the same phenomenon locally: it is still configured on 172.20.40.x and nobody shares a subnet with it anymore.

Steps 5 and 6 — apply and verify. The correct repair: restore the logical topology — the ISP router is set to bridge mode (or used purely as WAN access), the clinic's router goes back in its place as the LAN gateway (172.20.40.97), with the switch hanging off it and the VPN tunnel renegotiated with Alicante. The machines renew DHCP (ipconfig /renew) and recover their addresses from the plan.

Full verification: ipconfig (an address from the /28 ✔), tracert 172.20.40.10 crossing the tunnel in three hops (Elche gateway, Alicante router, server — the pattern you already saw in case B of module 6), records opening, printer visible. On question 5: plugging the clinic's router in behind the ISP router "as is" would create double NAT (192.168.1.x outside, 172.20.40.x inside): the LAN would work again, but the site-to-site VPN tunnel would be negotiating from behind a NAT it does not control — with the IPsec negotiation suffering or dropping, and every inbound service needing rules on two routers (module 5, lesson 05-03). Works-halfway is the worst kind of fix: bridge mode and a clean topology.

Step 7 — document. Root cause: an unauthorized physical topology change (layer 1 in origin) that replaced the site's gateway, DHCP and addressing (consequences at layers 2–3). Prevention: a topology sheet taped inside the cabinet ("this device does NOT get disconnected"), and every ISP intervention with Meridiano present or reviewed afterwards. Note for posterity in the knowledge base: the out-of-plan IP was the entire diagnosis; the rest was confirming it.

Modules used: 1 (topology), 2 (DHCP/DORA), 4 (routes and the default route), 5 (RFC 1918, NAT and double NAT), 6 (tracert, bottom-up).

The four cases share error patterns worth engraving in memory:

• Taking the symptom literally. "There's no Internet" was a dead DNS; "it has Internet but no records" was a mask; "the Internet works perfectly" hid an entire site off its network. The symptom is the investigation's starting point, never its conclusion.
• Diagnosing without the addressing plan in front of you. In cases 1, 3 and 4, the anomaly is only visible by comparing what is there with what should be there. A network without a documented plan cannot be diagnosed: it can only be guessed at.
• Ignoring the question "what changed?". An installer, an overnight firmware, an ultrasound scanner, an ISP technician: all four cases are born from a recent change. Correlation is not causation, but it is the best initial hypothesis there is.
• Underestimating intermittent problems. Case 3 is not caught with a one-off ping: it is caught with ping -t, two readings of arp -a and a capture. Instrumenting and waiting is diagnosis, not passivity.
• Verifying only half. "The Internet is back" does not close case 4; closing it means records + printer + tunnel + correct DHCP. Verify against the original symptom and against the plan.
• Fixing the technical issue and forgetting the process. Changing the scanner's IP takes a minute; getting the next vendor to ask for an IP instead of making one up is what prevents case 5. Documentation (step 7) is where an incident becomes an improvement.

The gym is closed — and with it, the course. It is worth looking back to see the full road: in module 1 you learned what a network is, its types and topologies; in module 2, the protocols that make it talk — Ethernet and ARP, IP, TCP and UDP, DNS, HTTP and company; in module 3, the seven-layer OSI map that orders it all; in module 4, the TCP/IP model that actually runs on every machine, with its routes and its sockets; in module 5, addressing end to end — binary, masks, subnetting, VLSM, NAT and IPv6; in module 6, the diagnostic tools and the method that governs them; and in this module 7 you turned all of it into fluency, first topic by topic and today against complete incidents, with no labels and no safety net.

Look at what you can already do, because it is no small thing: read any machine's configuration and spot at a glance what doesn't add up; design a small organization's addressing from scratch, VLSM plan included; follow a packet in your head from the initial ARP to the final 200 OK; interpret ping, traceroute, arp, nslookup, ss and a traffic capture; and — what truly sets you apart — diagnose with method, isolating the layer, finding the root cause and documenting it. In this module's first lesson we said that if you can only reason about the network you know by heart, you don't know how to reason about networks yet; after solving the problems of a clinic that didn't exist when you started the course, that bar has been cleared.

What now? Three paths, all compatible. Practice in a lab: simulators like Packet Tracer or GNS3, or a couple of old routers and a free afternoon, let you break and fix networks without anyone calling angry; open Wireshark often — every capture teaches something. Certify what you've learned if your career calls for it: this course leaves you a solid base for preparing entry- and intermediate-level networking certifications. And go deeper wherever it pulls you: network security (firewalls, VPNs in depth, traffic analysis), systems administration, or the IPv6 and cloud world where everything you've learned recombines. Networks have that rare quality: invisible when they work, fascinating when they don't.

Marta and Jon will keep opening the intranet every morning without suspecting the choreography of layers that makes it possible, and in Azahar's waiting room nobody will ever know that the patients' Wi-Fi lives in its own subnet for a very good reason. But you know — and you know exactly why. That is what finishing a networking course means. Congratulations, and may your ARP tables always be stable.