You have the toolkit (06-01) and the microscope (06-02). But tools alone don't resolve incidents: without a method you fall into "diagnosis by hunch" — rebooting things at random, changing three parameters at once, fixing the symptom without understanding the cause (which will come back). This lesson turns everything you know into a systematic method: the three layered approaches and when to use each, a 7-step procedure that works the same for a lost ping as for a full outage, a decision tree with the exact command for every check, and — most valuable of all — three real Grupo Meridiano incidents solved start to finish, with the output of every command, so you can watch the method breathe. It is the lesson that closes module 6 and, with it, the theoretical part of the course.

1. Why a method is needed
2. The three layered approaches: bottom-up, top-down, divide and conquer
3. The systematic method in 7 steps
4. The decision tree: "the network isn't working"
5. Case A: "Ana has no network"
6. Case B: "Bilbao can't reach the intranet, but browses fine"
7. Case C: "the intranet is slow... only sometimes"
8. Documenting: the step nobody does and everybody is grateful for

A network incident is a huge search space: dozens of components (cable, switch, VLAN, IP, DHCP, routes, VPN, DNS, firewall, service, application) and the fault can be in any of them. Trying things at random has exponential cost; a layered method reduces it to an ordered walk where each check rules out an entire block of causes. On top of that, the method provides two things intuition doesn't:

• Reproducibility: two technicians with the same method reach the same conclusion and can hand the incident over mid-way.
• Evidence: every step leaves a command output that proves what was ruled out — indispensable for escalating (to the ISP, to the VPN provider) without the problem bouncing back to you.

The good news: you almost have the method already. The OSI and TCP/IP models you studied were not decorative theory, they were the map for diagnosis; module 4's "funnel" and module 3's "layer 1 first" were its first sketches.

Given the map of layers, there are three ways to walk it:

The third is the professionals' favorite because a single successful ping validates layers 1, 2 and 3 at a stroke up to that destination: half the map ruled out with one command. That is why the decision tree below pivots on it. And "layer 1 first" (module 3) still stands as the golden exception: if there is any physical clue (an unlit LED, "Media disconnected", building work, desk moves), start bottom-up even if the symptom looks application-level — checking a cable costs 10 seconds.

The approaches say where to look; the 7 steps say how to work the incident end to end:

1. Define the problem and its scope. "The network is down" is not a defined problem. Ask until you get: what exactly fails, since when, what changed and — the most profitable question in all of diagnosis — who is affected?: one user or everyone? one site or both? one service or all of them? Each answer trims the map: if only Ana fails, the cause is at her desk or her segment; if all of Valencia fails but Bilbao browses, look at the electronics or Valencia's uplink; if both sites fail against the intranet but browse fine, look at the .10.10 server.
2. Reproduce the failure. Seeing it with your own eyes (or with a command) saves you from chasing inaccurate descriptions. If it is intermittent, leave monitoring in place (ping -t, a capture) until you catch it.
3. Form a hypothesis. With the scope and the reproduction, pick the most likely cause and the approach (bottom-up/top-down/divide). A hypothesis is stated so it can be falsified: "DHCP is not serving addresses", not "something with DHCP".
4. Test the hypothesis with the tool that confirms or refutes it — changing only one thing at a time. If you refute it, go back to step 3 with what you learned (what got ruled out is information too).
5. Apply the fix. With a rollback plan if at all possible (write down the previous value before changing it).
6. Verify that the original problem is gone and that you haven't broken anything else. Verify with the user and with the command that used to fail.
7. Document. Symptom, root cause, fix, evidence. We develop this at the end — it is the step that turns a painful incident into reusable knowledge.

For the generic report from a workstation, this is the ordered checklist — from layer 1 upward — with the exact command at each node. Memorize it: it is the whole of module 6 in one diagram.

Two usage nuances: if the scope (step 1 of the method) already tells you everyone is affected, don't start at one user's desk — go to what's shared (router, DHCP, DNS, server). And if the destination is at the other site, insert the "route/VPN?" node after the gateway: tracert toward the remote IP, as in case B.

Step 1 — define and scope. Monday, 9:05. Ana (Valencia) calls: "I have nothing, no intranet, no Internet". Scoping questions: Marta, two desks away, is working normally → a single Valencia user is affected. Changes? On Friday afternoon the desks in her area were rearranged. Scope + physical change decide the approach: bottom-up.

Step 2 — reproduce. On Ana's PC:

Reproduced, with half a diagnosis thrown in: there is link (otherwise it would say "Media disconnected" — layer 1 ruled out despite the desk move), but the IP is APIPA (module 5): the PC asked for DHCP and nobody answered. With no valid IP and no gateway, "having nothing" is consistent.

Step 3 — hypothesis. DHCP down on the .10.1 router? Quick scope cross-check: ipconfig /all on Marta's PC shows a lease renewed at 8:47 → DHCP works for others. Refined hypothesis: the problem is between Ana and the DHCP; and since DHCP runs on the VLAN 10 router, the concrete suspicion: when the desks were recabled, Ana's PC ended up plugged into a switch port assigned to VLAN 20 (guests) — on that VLAN her DORA exchange (module 2) never reaches the corporate DHCP.

Step 4 — test. On the switch, the port behind Ana's new wall jack (port 14):

Port 14 is on VLAN 20. Hypothesis confirmed: on Friday, Ana's patch cable got plugged into a guest jack.

Steps 5 and 6 — apply and verify. Port 14 is reassigned to VLAN 10 (or the patch cable is moved to a corporate jack; the first option is chosen, and the previous value is written down). On Ana's PC:

An IP from the dynamic range (.100–.199), correct gateway, intranet reachable. Ana confirms. Step 7 comes at the end of the lesson.

Step 1 — define and scope. Jon (Bilbao): "I can't open the intranet since this morning; the Internet works perfectly". Checked with another colleague in Bilbao: same → the whole Bilbao site, only toward Valencia resources, Internet intact. In Valencia everything works, intranet included. This scope speaks volumes: Bilbao's LAN is healthy (they browse), the server is healthy (Valencia uses it) → suspicion lands straight on the inter-site link: the VPN. Approach: divide and conquer along the route.

Step 2 — reproduce. From Jon's PC (.20.7):

The reading (06-01): hop 1 responds — everything up to his gateway is fine — and the route dies right after 192.168.20.1, on the tunnel segment. Asterisks to the very end: a real break, not a shy router.

Step 3 — hypothesis. Either the VPN tunnel is down, or the Bilbao router has lost its route to 192.168.10.0/24 (module 4: with no route, those packets leave via the default toward the Internet, where an RFC 1918 private address goes nowhere — which is exactly why "the Internet works perfectly" while Valencia is unreachable).

Step 4 — test. On the Bilbao router:

Confirmed twice over: the tunnel has been DOWN since 6:12, and with it down, the 192.168.10.0/24 via Tunnel1 route has vanished from the table. The router's log shows that at 6:10 Bilbao's ISP renewed the site's public IP, and the Valencia end was still waiting on the old one (recall from module 5 how much NAT and dynamic IPs complicate things).

Steps 5 and 6 — apply and verify. The tunnel negotiation is restarted with the new IP (and a permanent improvement is noted for step 7: switch the tunnel identification to a dynamic DNS name instead of a fixed IP). Verification from Jon's PC:

The trace crosses the tunnel again in 3 hops and the API responds: verified at layer 3 and at the application layer.

Step 1 — define and scope. Several Valencia users, over two weeks: "the intranet sometimes takes forever to load; then it's fine again". It affects several users, a single application, intermittently. Intermittent problems are the ones that punish hunch-based diagnosis the hardest — and where the method shines brightest.

Step 2 — reproduce (or monitor until you catch it). It can't be reproduced on demand, so it gets instrumented: on Marta's PC a loop is left measuring the API every minute with curl (the -w option, which prints per-phase timings — the stopwatch version of 06-01's -v), logging to a file. The next day, the data:

Instrumented reproduction is worth gold: the slowness is not in TCP, nor TLS, nor the server (those phases are constant): it is ~4 exact seconds of DNS, in bursts. That round number smells of timeout + retry: the resolver waits for a server that isn't answering and, after the deadline expires, asks the next one.

Step 3 — hypothesis. Meridiano's DHCP hands out two DNS servers. Hypothesis: the first one fails intermittently; when it fails, every resolution pays the timeout before falling back to the secondary. Step 4 — test, first by looking at the configuration and then with the microscope (06-02) — an authorized capture on Marta's PC, filter dns:

There is the whole movie: three attempts to the primary .10.2 (a test machine someone configured as the primary DNS in DHCP two weeks ago... and which gets switched off now and then) with no answer, and at the 4-second mark the system asks .10.1, which answers in 2 ms. It matches the curl -w bursts to the millisecond. Hypothesis confirmed with packet evidence.

Steps 5 and 6 — apply and verify. The DHCP DNS option is corrected (primary .10.1, .10.2 removed), renewal is forced (ipconfig /renew + /flushdns on the affected machines, or wait for the lease cycle). The curl -w monitor runs for another 48 h: no measurement above 0.06 s. Verified — with data, not with "it seems fine now".

Step 7 is the cheapest (10 minutes) and the one with the highest return. What to record for each incident, using case C as the example:

Why it pays off, coldly:

• Next time it takes 5 minutes: the symptom "burst slowness of ~4 s" will be linked to "primary DNS timeout" in the team's knowledge base.
• It reveals patterns: three misassigned-VLAN incidents in two months (case A) are not three accidents: they are a recabling procedure that's missing.
• The root cause prevents recurrence: without it, case B would have been "fixed" by rebooting the router — until the ISP's next IP renewal. Documenting forces you to distinguish I fixed the symptom from I understood the cause.
• It protects the team: faced with "the intranet has been slow on your watch for two weeks", the record proves what was done, when, and with what evidence.

• Skipping step 1 and going straight to the commands. Two scoping questions (who? since when/what changed?) save more time than any tool.
• Changing several things at once. If you touch the VLAN, the cable and the DHCP and something improves, you don't know which one it was — and you may have introduced a fresh fault. One change, one verification.
• Confusing correlation with cause. "I rebooted the switch and it came back" doesn't prove it was the switch (maybe the DHCP lease renewed at the same time). Root cause demands evidence, not coincidence.
• Closing without verifying with the command that used to fail (and with the user). "It should work now" is not a closure.
• Not noting the previous state before changing something. Without a rollback plan, one failed attempt becomes two incidents.
• Chasing intermittent problems with one-off tests. A lone ping at 12:00 doesn't catch a 9:43 failure. Instrument and wait: ping -t, curl -w loops, scheduled captures.
• Treating the layered model as dogma. The approaches are heuristics: if there is a strong clue (building work, yesterday's change), jump straight to it. The method exists to order the search, not to slow it down.

1. A report comes in at 9:00: "the intranet isn't working". Before touching a single command, write the three scoping questions you would ask and, for each of the following answer combinations, say where you would start looking: (a) it fails only for Marta, nobody else; (b) it fails for all of Valencia and all of Bilbao, but everyone browses the Internet; (c) it fails for all of Bilbao, and only Bilbao.
2. In case A, after seeing the APIPA on Ana's PC, a technician proposes as the fix "give her a static IP: 192.168.10.50, /24 mask, gateway .10.1". Show that this "fix" would most likely appear to work partially or not at all — reason through exactly what would happen with the port still on VLAN 20 — and explain why, even if it had worked, it would still be a poor resolution of the incident by the method's standards.
3. Design the diagnostic plan (steps 1–4 of the method, without solving it) for this symptom: "from the laptop in the Valencia meeting room, connected to the guest Wi-Fi, the intranet can't be opened; from the corporate Wi-Fi, it can". Include the most likely hypothesis given Meridiano's network design and the command that would confirm it.

1. Questions: Who is affected? (one user, one site, everyone?), what exactly fails and what works? (only the intranet, or Internet/other services too?), since when, and what changed?. Answers: (a) a single user → the cause is at Marta's desk or her segment: start on her machine (ipconfig /all, ping to the gateway and the intranet). (b) Both sites fail only against the intranet and everything else works → the only thing common to that symptom is the .10.10 server (or its web service): go straight to it (ping 192.168.10.10 from Valencia, and ss -tlnp on the server — dead host or closed port?). (c) Only Bilbao, and only toward Valencia → the inter-site segment: VPN/routes, as in case B (tracert -d 192.168.10.10 from Bilbao to see where it dies).
2. With the port on VLAN 20, the static IP 192.168.10.50 is useless: VLANs separate layer 2 domains (module 3), so Ana's ARP requests asking for .10.1 or .10.10 would never reach VLAN 10 — arp -a would show incomplete entries and the pings would fail just the same (perhaps with the added confusion of conflicts if VLAN 20 uses a different plan). In other words: the proposal doesn't even attack the cause (port on the wrong VLAN), only the visible symptom (missing IP). And even if it had worked, it would violate the method: no confirmed hypothesis and no root cause (why did DHCP stop serving Ana?), it introduces an undocumented exception (a static IP outside the addressing plan and the reservations, a future source of conflicts with the DHCP range) and it guarantees a repeat with the next machine plugged into that wall jack.
3. Step 1 (define/scope): it affects any device on the guest Wi-Fi (check with a second device), only toward the intranet (verify the Internet does work from the guest network), always or since a specific date (did it ever work?). Step 2 (reproduce): from the laptop on the guest network, ipconfig /all (expected: an IP from the guest network, not 192.168.10.x) and curl -v https://intranet.grupomeridiano.example, noting which phase fails. Step 3 (hypothesis): the guest Wi-Fi lands on VLAN 20, deliberately isolated from the corporate VLAN 10 — guests not reaching the intranet is not a fault but Meridiano's security design working as intended (most likely with router rules allowing guests→Internet but blocking guests→VLAN 10). Step 4 (test): ping 192.168.10.10 and tracert from the guest network (expected: blocked or cut at the router) and an immediate cross-check of the same curl from the corporate Wi-Fi (works). With the hypothesis confirmed, the "fix" is not technical but procedural: whoever needs the intranet must use the corporate network; if access from the guest network were genuinely needed, that would be a policy change to decide and document, not a quick hack.

Module 6 is now complete: the utilities sharpened one by one (06-01), the packet microscope with its legal framework (06-02) and, in this lesson, the method that governs them — the three layered approaches and when to use each, the 7 steps from define to document, the decision tree with its command per node, and three Meridiano incidents (Ana's APIPA that ended in a VLAN, the VPN tunnel that took Bilbao down, the intermittent DNS caught with instrumentation and a capture) solved start to finish. Notice what has happened over the course of the module: ARP, TTL, DORA, APIPA, VLANs, routes, sockets, the handshake... everything learned in modules 1 through 5 has stopped being syllabus and become diagnostic parts. You now have knowledge and method. What remains is fluency, and that is only earned by training: module 7 is exactly that — the course's gym, with exercises for every block and integrated practical cases in which to consolidate everything you now know how to do.