By the end of module 5 you knew how to design the addressing of a network like Grupo Meridiano's end to end. But a well-designed network fails too: Marta can't reach the intranet, a ping gets lost halfway, DNS resolves strangely. In this module we are going to turn what you know into a diagnostic method, and the first step is putting the toolkit in order. The tools in this lesson have already made scattered appearances throughout the course (ping in module 2, arp -a with Ethernet, nslookup with DNS, ss with sockets, ip route with TCP/IP); now we sharpen them: which options matter, how to read their outputs like a professional and — above all — when to use each one. We will always work Windows and Linux in parallel, because at Meridiano (and at almost any company) both coexist: Marta's and Ana's PCs are Windows, the intranet server (192.168.10.10) is Linux.

1. Checking your own configuration: ipconfig /all vs ip addr + ip route
2. ping in depth: options, TTL, loss and jitter
3. traceroute/tracert: seeing the path hop by hop
4. arp -a: confirming layer 2
5. nslookup and dig: interrogating DNS with precision
6. netstat/ss: an operational recap
7. curl: the application-layer probe
8. Final table: symptom → first tool

Before blaming the network, look at your own configuration. It is the equivalent of checking that the car has fuel before calling the tow truck. On Windows, the command is ipconfig /all (the /all matters: without it you won't see the MAC, the DHCP server or the DNS servers).

On Marta's PC, in Valencia:

A line-by-line reading, in the order a professional looks at it:

• IPv4 Address: is it the expected one? 192.168.10.21 is Marta's DHCP reservation (tied to her MAC 5c:26:0a:4b:91:d3, as we saw in module 2). If a 169.254.x.x showed up here (APIPA, module 5), the diagnosis is nearly done: DHCP didn't answer.
• Subnet Mask: /24, correct. Remember module 5's misconfigured /25 mask: a wrong mask produces very confusing asymmetric failures.
• Default Gateway: without it, there is no way out of the local network. Empty or wrong = Jon's case in module 3.
• DNS Servers: if the IP and the gateway are fine but "the Internet doesn't work", this field is the usual suspect.
• DHCP Enabled / lease: tells you whether the IP is dynamic and when it expires. Useful for knowing whether an ipconfig /release + /renew makes sense.

On Linux, the same information is split across two commands we already introduced in module 4. On the intranet server:

• state UP and LOWER_UP: the interface is administratively up and has physical link (cable/carrier signal). If LOWER_UP is missing, you are looking at a layer 1 problem — Ana's cable from module 3.
• inet 192.168.10.10/24: IP and mask in CIDR notation, on a single line.
• default via 192.168.10.1: the default route, i.e. the gateway.
• DNS on Linux is checked separately: cat /etc/resolv.conf (or resolvectl status on systems with systemd-resolved).

That order is no accident: it is "layer 1 first" (module 3) applied to your own machine.

ping (module 2) sends ICMP Echo Requests and waits for Echo Replies. It is the connectivity tool par excellence, but its output says far more than "responds / doesn't respond".

Key difference between systems: Windows sends 4 packets and stops; Linux sends indefinitely until you press Ctrl+C.

Continuous ping (-t) is gold for intermittent problems: you leave it running while you reproduce the failure. And the size + don't-fragment options are exactly what we used in module 4 to diagnose the MTU problem on the VPN with Bilbao.

Marta pings the intranet and Jon's PC in Bilbao:

The expert reading:

• TTL=64 from the intranet: recall from module 2 that every router subtracts 1 from the TTL. The typical initial values are 64 (Linux), 128 (Windows) and 255 (network equipment). A TTL of 64 with nothing subtracted tells you two things: the server is on your own network (0 hops) and it is probably Linux.
• TTL=126 from Bilbao: 128 − 126 = 2 hops → Jon's PC is Windows (it started at 128) and there are 2 routers in between (Valencia's and Bilbao's, through the VPN tunnel). The TTL lets you infer hops and operating system without touching the destination.
• Times: <1 ms on the LAN is normal; ~40 ms to Bilbao over the VPN, reasonable. Look at the fourth packet: 112 ms. That variation between times is called jitter, and it is what ruins video calls and VoIP even when the average looks fine.
• Packet loss: 0% is what you expect on a LAN. A sustained 2–5% already degrades TCP noticeably (retransmissions) and wrecks real-time traffic. We will see it "in person" in lesson 06-02.

And the most important warning of all: "Request timed out" does NOT prove the host is down. Many firewalls (including Windows' own default on "public" networks) filter ICMP: the host is alive and serving, but doesn't answer pings. We saw this in module 3 with the "closed port vs dead host" case. Practical rule: a ping that responds confirms connectivity; a ping that doesn't respond is only a clue to be cross-checked (for instance, with curl against the actual service, below).

A new tool. When a ping fails "halfway there", you want to know where the route breaks. tracert (Windows) and traceroute (Linux) show you every intermediate router.

How it works is a brilliant idea built on module 2's TTL:

1. It sends a packet with TTL=1. The first router receives it, subtracts 1, hits 0, discards it… and sends back an ICMP "Time Exceeded" with its own IP as the sender. First hop identified.
2. It sends another with TTL=2: it dies at the second router, which gives itself away the same way.
3. Repeat with TTL=3, 4, 5… until the packet reaches the destination, which replies normally.

Marta's trace toward Bilbao (over the VPN) and toward the Internet:

How to read it:

• -d (Windows) / -n (Linux) disables reverse DNS resolution for each hop: the trace runs much faster, and when diagnosing that is almost always what you want.
• Toward Bilbao there are only 3 hops: the VPN tunnel encapsulates the traffic, so every Internet router physically sitting between Valencia and Bilbao is invisible — the tunnel behaves like a virtual cable between .10.1 and .20.1. It matches what we deduced from the ping's TTL=126 (2 routers).
• Toward the Internet you see the gateway, the ISP (10.140.2.1, a private address inside the carrier's network — CG-NAT, module 5) and public hops.
• The asterisks * at hop 4 do not mean a fault: that router simply doesn't answer the probes (by policy, or because its control plane deprioritizes them), but it forwards the traffic — the proof is that hop 5 responds. Worry when the asterisks appear at one hop and at every hop after it to the end: there the route really does break, and the last hop that responded is your best clue to where the problem is.
• A technical detail that sometimes matters: Windows probes with ICMP Echo; Linux, by default, with UDP to high ports (use traceroute -I to force ICMP). Some firewalls treat each type differently, so the same trace can differ between systems.

When to use traceroute? When end-to-end connectivity fails or is slow and you need to locate the segment: if the trace from Valencia to Bilbao dies after 192.168.10.1, the problem is in the VPN or beyond; if not even hop 1 shows up, the problem is local.

You already know ARP from module 2: it translates IPs into MACs within the local network. As a diagnostic tool, arp -a answers a very specific question: "has my machine managed to talk at layer 2 with that neighbor?"

• There is an entry with a MAC for the gateway (.10.1) and the intranet (.10.10): ARP resolution worked, so layer 1 and layer 2 up to those machines are confirmed. If a ping to .10.10 failed but its ARP entry existed and was recent, the problem would be above layer 2 (a firewall, for example).
• On Linux, ip neigh also shows the state: REACHABLE (confirmed), STALE (old, will be revalidated) or FAILED/INCOMPLETE.
• An incomplete entry (Linux: INCOMPLETE; Windows: the entry simply never appears after attempting the ping) means the question "who has 192.168.10.10?" was asked and nobody answered: the host is powered off, unplugged or on another VLAN (remember: Meridiano's guest VLAN 20 doesn't see ARP from the corporate VLAN 10).
• An important nuance: ARP only works for your own subnet. For 192.168.20.7 you will never see its MAC in Valencia; you will see traffic headed to your gateway's MAC.

Field trick: arp -a immediately after a failed ping to a neighbor is the fastest way to separate "layer 2 problem" from "host that filters ICMP".

nslookup appeared in module 2 with the A/AAAA/CNAME/MX record types. As a diagnostic tool, its value lies in two abilities: asking for specific record types and asking a specific server, bypassing your local configuration.

Interpretation — and this is a pattern you will see a thousand times:

• The first two lines of each query tell you who you are asking. The first query uses the configured DNS (Meridiano's router, which resolves the internal zone).
• Adding an IP at the end (... 8.8.8.8) forces the query to that server. That Google doesn't know intranet.grupomeridiano.example here is normal: it is an internal name that only exists in the company's DNS. But this technique is the key to answering "is the problem my DNS or the name in general?": if your DNS fails and 8.8.8.8 resolves, the problem is your DNS server, not the domain.
• For a specific type: nslookup -type=MX grupomeridiano.example.

On Linux, the professionals' tool of choice is dig, which is more detailed:

• The 3600 is the record's TTL (yes, another TTL, distinct from IP's!): the seconds the answer may live in caches. It explains the classic "I changed the DNS but some users go to the old server and others to the new one": caches holding the old record will keep serving it until its TTL runs out.
• Syntax for a specific server in dig: dig @8.8.8.8 grupomeridiano.example MX.
• On Windows, ipconfig /displaydns shows the local DNS cache and ipconfig /flushdns empties it — the first remedy when you suspect a stale cached answer.

These two we worked through in depth in lesson 04-04 (sockets, LISTEN/ESTABLISHED/TIME_WAIT, EADDRINUSE); here we just pin down their role in the toolkit: they answer "is the service listening, and who is connected?". The invocations you should have in muscle memory:

Mnemonic for ss -tlnp: tcp, listening, numeric, processes. If a curl to a server fails, the check on the server side is always this one: without a socket in LISTEN, there is nothing to connect to. The fine detail (states, queues, TIME_WAIT) is in 04-04.

Everything above checks layers 1–4. But "the intranet is down" can be a layer 7 failure with every lower layer in perfect shape. curl makes real HTTP/HTTPS requests from the terminal (it ships with Linux and with Windows 10+), and with -v (verbose) it shows you each phase separately — exactly the DNS→TCP→TLS→HTTP flow we dissected in module 4:

The diagnostic power lies in where the output stops:

Notice that Connection refused (an immediate RST: there is a host, there is no service) versus a timeout (nobody answers) is the same "closed port vs dead host" distinction from module 3 — curl serves it to you pre-labeled.

• Concluding "host down" because it doesn't answer pings. Firewalls filter ICMP all the time. Always cross-check with the actual service: curl to the application's port.
• Forgetting the /all in ipconfig. Without it you don't see DHCP, DNS or the MAC — which is exactly what usually matters.
• Panicking over stray asterisks in a traceroute. A silent hop with later hops responding is cosmetic. What matters is the point from which everything is asterisks to the end.
• Ignoring the TTL in ping replies. It's free information: hops to the destination and a hint about the remote operating system.
• Testing DNS only against the configured server. A query to a second server (nslookup name 8.8.8.8) separates "my DNS is failing" from "the domain is failing" in seconds.
• Looking in arp -a for the MAC of a machine on another subnet. ARP doesn't cross routers; for Bilbao you will only ever see your gateway's MAC.
• Running a single ping and deciding. Intermittent problems demand ping -t (or -c 100) while watching loss and jitter, not one lone ping.

1. From Marta's PC, ping 192.168.10.10 returns replies with TTL=64, and ping 192.168.20.1 returns replies with TTL=254. Reason through each case: how many routers are in between, and what hint do you have about the kind of system responding?
2. Ana can't open https://intranet.grupomeridiano.example. She runs curl -v and the output stops after * Trying 192.168.10.10:443... with an immediate Connection refused. Her colleague declares: "the server is down, it isn't even powered on". Is he right? What exactly does that message indicate, and what command would you run on the server to confirm it?
3. A tracert -d 192.168.20.7 from Valencia shows: hop 1 192.168.10.1 OK; hops 2 through 30, all asterisks. On another day, the same trace showed hop 2 192.168.20.1 and hop 3 the destination. Which segment would you flag as broken, and why is the healthy hop 1 a valuable clue?

1. Intranet, TTL=64: the typical initial TTLs are 64, 128 or 255. Receiving exactly 64 means 0 routers in between (it is on the same subnet — consistent: .10.21 and .10.10 share the /24) and suggests a Linux/Unix system (initial 64). Bilbao router, TTL=254: it started at 255 (usual for network equipment) and 1 was subtracted once → 1 router in between (Valencia's, .10.1; the destination itself doesn't count its own hop). Note how the same received TTL value is interpreted relative to the most likely initial value.
2. He is not right. Connection refused means the host responded — with an RST: there is a live machine at 192.168.10.10, but no process is listening on port 443 (service stopped, or listening on another port). If the server were powered off, the symptom would be a timeout (nobody answers), not an immediate refusal. Confirmation on the server: ss -tlnp | grep 443 — if there is no LISTEN line, the intranet's nginx needs to be started/checked. It is module 3's "closed port vs dead host" distinction.
3. The break is after the Valencia gateway and before the Bilbao router: that is, in the VPN tunnel (or in the Internet connection carrying it). The healthy hop 1 is valuable because it rules out the entire local segment: Marta's PC, the cabling, the switch and the gateway all work; there is no point checking anything on the Valencia LAN. Unlike a stray asterisk, here the asterisks run from hop 2 to the very end: the route genuinely breaks. Next step: check the VPN tunnel status on the .10.1 router.

Your toolkit is now in order: ipconfig/ip addr + ip route for your own configuration (layer 1 first), ping read with an expert eye (TTL, loss, jitter, and its great limitation: filtered ICMP), traceroute to locate the failing segment by recycling the TTL trick, arp -a as layer 2 confirmation, nslookup/dig to interrogate DNS with a surgeon's precision, ss/netstat for the sockets, and curl -v as the application-layer probe that splits DNS, TCP, TLS and HTTP into visible phases. With the symptom → tool table you have the opening reflex for almost any support call. But all these utilities share one limit: they tell you that something fails and where, but not always why — they work on summaries and inferences. When you need the whole truth, you have to go down to the level where nothing can lie: seeing the packets one by one. That — Wireshark, tcpdump and traffic analysis, legal and ethical framework included — is the next lesson.