Second gym session, and we add weight: the protocols from module 2. Everyday logic is no longer enough here — you have to read frames, follow sequence numbers, interpret ping and arp outputs, and reconstruct DNS and DHCP conversations. These are the muscles you will use most in your professional life: practically every network incident is diagnosed with what this lesson trains. We continue with Grupo Meridiano (Marta at 192.168.10.21, the server at .10.10, the router at .10.1, Jon in Bilbao at 192.168.20.7) and the odd cameo from Clínica Azahar.

• Solve in writing before looking at the solution — it sits right below each statement, so, discipline.
• With the console outputs, truly read them: field by field, as if they were on your screen at 9 in the morning with a user waiting. Speed will come on its own; precision first.
• If you get one wrong, review the lesson flagged with 📌 before continuing: later exercises assume the earlier ones have sunk in.

Marta presses Enter on https://intranet.grupomeridiano.example. Put the following stages of her request's encapsulation in order, first to last, and name the resulting data unit at each step:

• (a) The source and destination IP addresses are added.
• (b) The HTTP request is generated with its method and headers.
• (c) The signals are transmitted over the cable.
• (d) The source and destination ports and the sequence numbers are added.
• (e) The source and destination MAC addresses and the FCS are added.

📌 Review if you struggled: lesson 02-01.

Order: b → d → a → e → c. The application generates the data and each protocol wraps it in turn, like Russian dolls:

1. (b) HTTP creates the request → data.
2. (d) TCP slices it up and adds ports and sequence numbers → segment.
3. (a) IP adds network addresses → packet.
4. (e) Ethernet adds MACs and the FCS check → frame.
5. (c) The frame becomes signals → bits on the medium.

At the destination exactly the reverse happens (decapsulation): each layer removes "its" envelope and hands the contents to the next.

Frequent mistakes: placing IP before TCP. Mnemonic rule: the envelope that goes on first is the one that comes off last; HTTP is the contents, TCP the first envelope, IP the second, Ethernet the last and outermost.

An analyzer captures this frame on the Valencia network (simplified fields):

It is known that 3C:52:82:AA:21:07 is the network card in Marta's PC and 00:0C:29:5A:11:10 the one in the server.

1. Who is sending this frame and who is receiving it?
2. What does the Type field with value 0x0800 indicate?
3. What is the FCS for, and what does the receiver do if it doesn't add up?
4. Will the other PCs in the office see this frame, if the central device is a switch?

📌 Review if you struggled: lesson 02-02.

1. It is sent by Marta's PC (source MAC) toward the server (destination MAC). Watch the field order: in the frame, the destination comes before the source.
2. That the payload being carried is an IPv4 packet: the Type field declares which protocol travels inside, so the receiver knows who to hand it to.
3. The FCS (Frame Check Sequence) is a checksum (CRC) computed over the frame. The receiver recalculates it on arrival: if it doesn't match, the frame got damaged along the way and is silently discarded — the link layer does not retransmit; if those bytes mattered, TCP will recover them higher up.
4. No. The switch consults its MAC table and forwards the frame only out the port where 00:0C:29:5A:11:10 lives. That is what sets it apart from a hub, which would repeat it out every port.

Marta has just powered on her PC (empty ARP cache) and runs ping 192.168.10.10. Before the first ICMP goes out, her machine does something else. On her PC, arp -a shows before and after:

1. Describe, message by message, what happened between the ping and the first ICMP packet.
2. Who receives the ARP question and who answers it?
3. Why was the router .10.1 already in the cache before the ping?

📌 Review if you struggled: lesson 02-02.

1. The PC needs the MAC of 192.168.10.10 to build the frame, and doesn't have it. Sequence:
   • ARP Request: "Who has 192.168.10.10? Tell 192.168.10.21" — sent as a broadcast (destination MAC ff:ff:ff:ff:ff:ff), because it doesn't know who to ask.
   • ARP Reply: the server answers in unicast directly to Marta: "192.168.10.10 is at 00:0c:29:5a:11:10".
   • The PC stores the pair in its cache (that's why it shows up in the second arp -a) and can now send the ICMP echo request inside a properly addressed frame.
2. The question is received by every machine on the local network (it's a broadcast); it is answered only by the owner of the IP being asked about.
3. Because the PC had already talked to the router earlier (at boot: DHCP, first Internet connections, DNS...). Dynamic entries are learned through use and expire on their own after a while.

Frequent mistakes: thinking ARP "goes out to the Internet to ask". ARP never crosses routers: it is a local-network protocol. For remote destinations you don't ask for the remote IP but for the gateway's — which is exactly the next exercise.

Marta's PC (192.168.10.21, mask 255.255.255.0, gateway 192.168.10.1) sends a packet to each of these destinations. For each case state: is it a local or a remote destination?, which IP does ARP ask about?, and which destination IP and destination MAC will the frame leaving her network card carry?

1. The server 192.168.10.10.
2. Jon's PC, 192.168.20.7.
3. An Internet server, 93.184.216.34.

📌 Review if you struggled: lesson 02-03.

The machine applies the mask: anything starting with 192.168.10 is its network; everything else, remote.

The key idea sits in row 2: the destination IP never changes for the entire journey (it is the final destination), but the destination MAC is always the next hop's — it changes on every leg. The frame is the local delivery envelope; the packet, the letter that travels whole.

Frequent mistakes: answering that the frame toward Jon carries "Jon's MAC". Marta's PC cannot know it, nor would it be any use: MACs only make sense within the local network. If in an exam (or in Wireshark) you see a remote IP + the router's MAC, it means you got it.

Two pings are run from Marta's PC with this result:

1. In the first ping: how many routers has the reply crossed and how do you know? What operating system is the Bilbao router probably running?
2. What do the times (29–33 ms) tell you?
3. In the second ping: what does "Request timed out" mean and what causes are consistent with it? How would a "Destination host unreachable" differ?

📌 Review if you struggled: lessons 02-03 and 06-01.

1. The TTL arrives at 62. Typical initial values are 64 (Linux) and 128 (Windows); 62 is 2 hops below 64, so the reply has crossed 2 routers (Bilbao's on the way out and Valencia's on the way in, through the VPN tunnel) and the sender is in all likelihood a Linux box — what you'd expect from a router.
2. That there is about a 30 ms round trip to Bilbao, and a stable one (little variation between samples = little jitter). It is a healthy line for interactive traffic.
3. "Request timed out" = I sent the echo request and nobody answered anything: consistent with the machine .20.99 not existing, being switched off, or a firewall silently dropping the ICMP — ping alone cannot tell those causes apart. "Destination host unreachable" is different: someone actively replied (a router, or your own machine) saying it doesn't know how to get there or can't find the host on the local network; there is an explicit diagnosis, not silence.

Frequent mistakes: concluding "the machine doesn't exist" from timeouts. Silence has three explanations, and one of them (firewall) is a perfectly alive machine. Before passing sentence, cross-check another way (does it answer on another port? does it show up in the router's table?).

These three TCP segments between Jon's PC and the intranet server reached the analyzer out of order:

• Segment X: source 192.168.10.10:443 → destination 192.168.20.7:52144, flags SYN, ACK, seq=8800, ack=3501
• Segment Y: source 192.168.20.7:52144 → destination 192.168.10.10:443, flags ACK, seq=3501, ack=8801
• Segment Z: source 192.168.20.7:52144 → destination 192.168.10.10:443, flags SYN, seq=3500

1. Order them and justify the order with the sequence and ACK numbers.
2. Who is the client and who the server? What type of port does each use?
3. After the handshake, Jon sends his first segment with 200 bytes of data. What seq will it carry and what ack will the server return?

📌 Review if you struggled: lesson 02-04.

1. Order: Z → X → Y (SYN → SYN-ACK → ACK). The arithmetic proves it: Z proposes seq=3500; X answers with ack=3501 ("got your 3500, expecting 3501") and proposes its own seq=8800; Y confirms with ack=8801. Each ACK is "the next byte I expect", which is why it is always the other side's seq + 1 during the handshake.
2. Client: Jon's PC — it sends the first SYN and uses an ephemeral port (52144, picked at random for this connection). Server: the intranet on its well-known/service port (443, HTTPS), fixed and known in advance.
3. His first data byte is 3501, so he will send seq=3501 with 200 bytes (bytes 3501–3700). The server will confirm with ack=3701: the next byte it expects.

Frequent mistakes: believing the ACK confirms "segment number X". It confirms bytes, not segments: ack=3701 means "I have everything up to byte 3700". That nuance is what lets TCP detect and retransmit exactly what was lost.

For each Meridiano and Azahar application, choose TCP or UDP and justify it in one sentence:

1. Downloading a PDF contract from the file server.
2. The weekly Valencia–Bilbao video call.
3. The DNS query that precedes almost everything.
4. The GET /api/proyectos call to the intranet API.
5. Monitoring probes that every 10 seconds send an "I'm alive" from each machine in the clinic to a central dashboard.

📌 Review if you struggled: lesson 02-04.

1. TCP. A PDF with one corrupt byte is a broken PDF: integrity is non-negotiable here and latency is irrelevant.
2. UDP. Retransmitting a chunk of voice from 2 seconds ago makes no sense (it would arrive late); better to lose a frame and move on. Fluidity outranks integrity.
3. UDP. Tiny question, tiny answer: setting up and tearing down a TCP connection would cost more than the entire query. If it gets lost, the application simply asks again.
4. TCP. A truncated or corrupted JSON response is an application error; besides, HTTP (and the TLS protecting it) rely on TCP's reliable, ordered stream.
5. UDP. Minuscule, frequent, individually expendable messages: if one "I'm alive" gets lost, another arrives in 10 seconds. Keeping hundreds of TCP connections open for this would be a waste.

Frequent mistakes: reasoning "UDP = bad/unreliable, TCP = good". They are tools: UDP is not worse, it is cheaper, and there is traffic (voice, probes, DNS) where paying for TCP's reliability is paying for something that gets in the way.

Match each situation with its status code (200, 301, 403, 404, 500) and state in each case whether the problem — if there is one — lies on the client side or the server side:

1. Ana types /api/proyectoss (double s) and the intranet has no such route.
2. Marta's GET /api/proyectos request returns the expected JSON.
3. The intranet has moved the manuals to another URL and redirects automatically to the new one.
4. Jon, without admin permissions, tries to get into /admin.
5. A bug in the intranet's code blows up the request while querying the database.

📌 Review if you struggled: lesson 02-05.

1. 404 Not Found — 4xx family: the error is in the client's request (that route doesn't exist).
2. 200 OK — 2xx family: success.
3. 301 Moved Permanently — 3xx family: a redirect; not an error but an "it's somewhere else, go there" that the browser follows on its own.
4. 403 Forbidden — 4xx: the server understands you perfectly, but you don't have permission. Compare with 404: here the route exists; what's missing is authorization.
5. 500 Internal Server Error — 5xx family: the request was fine; it is the server that failed. The client can't fix it no matter how much it retries.

The rule to have tattooed: 4xx → check your request; 5xx → the problem is on the other side. It steers a diagnosis in seconds.

Ana visits www.clinicaazahar.example for the first time (the clinic's public website, which Meridiano maintains for them). Neither her PC nor the DNS server her machine uses has anything cached. Afterwards, nslookup shows:

1. Describe, in order, every step of the resolution, from the browser to obtaining the IP.
2. What type of DNS record was queried?
3. What does "non-authoritative answer" mean?
4. If Ana comes back two minutes later, does the whole process repeat?

📌 Review if you struggled: lesson 02-05.

1. Step by step:
   1. The browser checks the machine's local cache: empty.
   2. The PC asks its configured DNS server (the router, 192.168.10.1, which acts as DNS for the office).
   3. It doesn't have it either, so it walks the hierarchy: it asks a root server (which refers it to the .example TLD servers), then the TLD (which refers it to the authoritative server for the clinicaazahar.example domain), and finally the authoritative one, which answers: www.clinicaazahar.example → 203.0.113.80.
   4. The router caches the answer and returns it to Ana's PC, which caches it too. The browser can now open the connection to 203.0.113.80.
2. An A record: name → IPv4 address. (For IPv6 it would be AAAA; an alias would be CNAME; mail, MX.)
3. That whoever is answering (the router) is not the authoritative server for the domain: it is serving a cached or recursive copy. That is the everyday normal; only the authoritative server gives the "official" answer.
4. No. The answer is cached (on the PC and on the router) and is served from there until its time-to-live expires. That is why the first visit to a site is always a touch slower than the following ones — and why DNS changes "take a while to show up".

A new laptop is plugged into the Valencia network and within a few seconds it has the address 192.168.10.101. That same day, Marta's PC reboots and gets, as always, 192.168.10.21.

1. Order and describe the 4 messages the new laptop exchanged with the DHCP server (the router .10.1), indicating which travel as broadcasts.
2. Besides the IP, what other three parameters at minimum did DHCP hand over, and what is each one for? (Think back to exercises 4 and 9.)
3. Why did the laptop get .10.101 while Marta always gets .10.21, if both use DHCP?

📌 Review if you struggled: lesson 02-05.

1. The DORA sequence:
   1. Discover — the laptop, which has no IP yet, shouts as a broadcast: "any DHCP server out there?".
   2. Offer — the router offers it a free address from its range (.10.100–.199): "I offer you 192.168.10.101".
   3. Request — the client, still broadcasting, formally requests that offer (that way, if there were several servers, they all learn which one was accepted).
   4. Acknowledge — the server confirms and starts the rental contract (the lease). The client's messages travel as broadcasts because it still has no network identity to speak from in unicast.
2. At minimum: the subnet mask (255.255.255.0 — without it, it couldn't decide local/remote, exercise 4), the gateway (192.168.10.1 — without it, it couldn't leave the network), and the DNS server (without it, it couldn't resolve names, exercise 9). An IP without those three companions is a car without a steering wheel.
3. Because Marta has a MAC reservation: the DHCP server has it written down that "to the MAC of Marta's PC, always hand out 192.168.10.21". Same DORA mechanics, fixed outcome. It is the way to give out stable addresses (to her PC, to the printer) without giving up DHCP's centralized management.

Frequent mistakes: confusing a DHCP reservation with a manually configured static IP. The result looks similar (a fixed IP), but the reservation is administered on the server — one single place, no touching the machine — which is why it is usually the preferred option on managed networks.

If you got this far by solving (and not just reading), you have just exercised the backbone of networking: encapsulating in order, reading a frame and knowing who is talking to whom, understanding ARP as the local network's town crier, separating the destination IP (end of the journey) from the destination MAC (next hop), extracting hop counts and operating systems from a humble TTL, reconstructing a handshake with its seq/ACK arithmetic, choosing a transport with good judgment, translating HTTP codes into culprits, narrating a complete DNS resolution and reciting DORA, gifts included. The next session works a different muscle group: OSI model exercises, where you will practice the layer language professionals use to understand each other — and the classic table exam you will sooner or later run into.