Did you bring paper? We meant it at the end of the last session: this is the longest and most calculation-heavy session of the module, the most mathematical muscle of the course. It trains the whole of module 5 in one go: binary conversions, classifying addresses at a glance, the 5-step method, subnetting, a complete VLSM design from start to finish — for Clínica Azahar, which is finally getting its own addressing plan —, reading NAT tables, and IPv6. House rule: everything is worked out by hand, with the weights table and the 256 trick; the calculator is allowed only for checking. Subnet calculators do exist in the real world, yes — but whoever can't do the math also can't spot when the calculator (or the colleague, or the inherited documentation) got it wrong.

1. Warm-up: conversions and masks
2. Classifying addresses
3. The 5-step method
4. Subnetting: when fixed length isn't enough
5. Complete VLSM design: Clínica Azahar
6. NAT: reading the table and reasoning out what the outside sees
7. IPv6: reading, abbreviating and classifying

• Solve before you look at the solution, which sits right below each statement. In this session more than any other: reading a finished calculation produces the false feeling of knowing how to calculate.
• Write down every step. The goal is not to hit the right number: it is for your procedure to be so systematic you can trust it at 3 a.m. during a migration.
• Verify in binary when in doubt. The jump trick solves 95% of cases; the bitwise AND is the court of appeal.
• 📌 marks which module 5 lesson to review if you slip. Difficulty grows section by section: don't jump to VLSM without having sweated the 5-step method.

1. Convert to binary, octet by octet and using the successive subtraction method, the address 203.0.113.194 (the public IP the ISP has just assigned to Clínica Azahar's router in Alicante — it will stay with us all session).
2. Convert to dotted decimal, by adding weights, the address 10101100.00010100.00101000.00001010. Keep the result: you will see it again.

📌 Review if you struggled: lesson 05-01.

1. With the weights table 128-64-32-16-8-4-2-1:

2. Adding weights per octet:

Result: 172.20.40.10. It is private (172.20 falls inside 172.16.0.0/12) and — spoiler — it will be the address of Azahar's medical records server when we design their network in exercise 7. Good numbers come back around.

Frequent mistakes: in octet 194, forgetting that after subtracting 128 and 64 there are 2 left, and "padding" with zeros to the end without placing the 2's bit. When you finish a conversion, add up the weights of your ones and check you recover the original number — it costs 5 seconds and catches almost every slip.

1. For each candidate, say whether it is a valid mask and, if so, its CIDR prefix: (a) 255.255.248.0 (b) 255.224.255.0 (c) 255.255.255.224 (d) 255.255.191.0.
2. Write in dotted decimal the /30 and /23 masks, and work out how many usable hosts each one allows.

📌 Review if you struggled: lesson 05-02.

1. A valid mask is contiguous ones on the left, contiguous zeros on the right — no mixing:
   • (a) Valid: 255.255 is 16 ones, and 248 = 11111000 adds 5 → /21.
   • (b) Invalid: 255.224.255.0 has zeros (the last three bits of 224) followed by ones (the 255 in the third octet). The ones are not contiguous.
   • (c) Valid: 24 ones + 224 = 11100000 → /27.
   • (d) Invalid: 191 = 10111111 — there is a zero embedded between ones. No mask octet can be 191; only 0, 128, 192, 224, 240, 248, 252, 254 and 255 exist.
2. The math:

The /30 with its 2 hosts is the classic for point-to-point links between routers — we will use it in Azahar's plan. The /23 shows up when a /24 runs out of room and merges with its neighbor.

Classify each address: is it public, private (RFC 1918) or special (say which)? And is it assignable to a machine as presented? Where a mask is given, take it into account.

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

Frequent mistakes: numbers 3 and 8 get missed when classifying "from memory" without looking at the mask. .31 and .96 are perfectly valid hosts in a /24; they are broadcast and network in a /27 and a /28. No address can be classified as network/broadcast/host without its mask.

Jon's PC has 192.168.20.7 under Bilbao's new plan: mask /27.

1. Work through the 5 steps: host bits, usable hosts, network, broadcast and usable range. Also write the mask in decimal.
2. An absent-minded technician configures a visiting laptop with 192.168.20.40/27. Is it in Jon's subnet? And would it be if Bilbao were still on /24?

📌 Review if you struggled: lesson 05-02.

1. The 5 steps:

Jon (.7) is a valid host in the range, with the gateway at .1. Everything squares with the sizing from lesson 05-02.

2. For .40: the multiple of 32 at or below 40 is 32 → its network is 192.168.20.32/27, not Jon's. They are not in the same subnet: the laptop would see the gateway .1 as "outside its network" and nothing would work. With /24 the answer flips completely: both would be in 192.168.20.0/24 and would talk directly. Same question, different mask, different world.

The cloud provider where Azahar stores its nightly backups internally uses the address 10.20.147.200/22 for the backup server. Work through the full 5 steps and verify the network address with the binary AND.

📌 Review if you struggled: lesson 05-02.

Notice that 10.20.147.255 is not the broadcast of "a class C 10.20.147": it is just another host… no, wait: in this /22 it is the broadcast, but 10.20.145.255 and 10.20.146.255, which look like broadcasts, are valid, assignable hosts in the 144–147 block. That is the mental trap of masks that cross octets: the in-between .255s are ordinary addresses.

Frequent mistakes: applying the jump in the fourth octet out of habit. The jump is applied in the interesting octet — the one where the mask is neither 255 nor 0 —, and every octet to its right goes to 0 (network) or 255 (broadcast).

Clínica Azahar is finally renumbering its network. Meridiano (who runs their IT) reserves the block 172.20.40.0/24 and gathers the requirements — gateway included in every count:

A technician proposes "let's split it the easy way: all subnets equal". Prove with numbers that fixed-length subnetting cannot satisfy this commission within the /24: try the prefix that yields enough subnets and the one that yields enough hosts.

📌 Review if you struggled: lesson 05-02.

6 subnets are needed and the largest requires 37 addresses. Let's try both routes:

Conclusion: with fixed length, either hosts are left over and subnets run out, or the other way round. Azahar's needs are unequal (from 37 addresses down to 2), and that is exactly what VLSM exists for: a tailored mask for each subnet. Which is the next exercise.

Frequent mistakes: forgetting to count the gateway (and answering that Alicante "only" needs 36), or solving route A with 2 bits because "6 is close to 4". Powers of 2 don't negotiate: 6 subnets require 8.

With the requirements from exercise 6, design the complete VLSM plan over 172.20.40.0/24:

1. Choose each subnet's prefix.
2. Assign the blocks in the correct order and work out for each one: network, mask, usable range, broadcast and gateway (use the first usable address as the gateway; the medical records server must land on 172.20.40.10).
3. Verify that each block starts at a multiple of its jump and state how much space is left free.

📌 Review if you struggled: lesson 05-02 (VLSM section).

1. Choosing prefixes — for each need, the smallest block whose 2^h − 2 covers it:

The Torrevieja decision is the kind of judgment VLSM asks of you: the /29 is mathematically correct and operationally suffocating (the first new tablet forces a renumbering). Reasonable headroom > optimizing to the bit.

2. Assign largest to smallest, each block starting where the previous one ends (and on a multiple of its jump):

Worked calculation for the first two (the rest follow the same pattern):

The medical records server lands on 172.20.40.10, inside Alicante's static range — the address you converted in exercise 1.

3. Verification and free space:

Frequent mistakes: assigning the blocks in the order of the requirements list instead of largest to smallest — if the Wi-Fi's /27 is placed first and the /26 after it, the /26 would have to start at .32, which is not a multiple of 64, and a hole would have to be left. Big first: it's not fussiness, it's arithmetic.

Over the plan from exercise 7, answer with reasoning:

1. Which subnet does 172.20.40.100 belong to, and what is it (host, network, broadcast)?
2. Is 172.20.40.95 assignable?
3. A physio's tablet in Alicante (172.20.40.40/26) queries the medical records server (.10). Direct delivery or via gateway? And the Elche PC 172.20.40.98/28?
4. A patient in the waiting room (172.20.40.70/27) tries to open the medical records server. What does their device decide, and what should the Alicante router decide?

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

1. Multiples of 16 in the area: 96, 112. The one ≤ 100 is 96 → it belongs to 172.20.40.96/28 (Elche), range .97–.110: it is a valid host in Elche.
2. No: it is the broadcast of the Wi-Fi block (172.20.40.64/27 → broadcast .95).
3. The tablet: 40 AND /26 → network .0; the server: 10 AND /26 → network .0. Same subnet → direct delivery (ARP + frame, no router). The Elche PC: 98 AND /28 → network .96 ≠ .0 → via gateway .97, and from there over the /30 tunnel to Alicante.
4. The patient's device computes: 70 AND /27 → network .64; the server is on network .0 → different → it sends to the gateway .65. Up to here, pure layer 3. But the Alicante router must have a rule blocking waiting room → internal network: the patients' Wi-Fi being its own subnet exists precisely so that policy can be applied. Addressing separates; the firewall decides. (Medical records reachable from the waiting-room Wi-Fi is the kind of headline no clinic wants to star in.)

The Alicante router (public IP 203.0.113.194, the one from exercise 1) shows this NAT table in the middle of the morning:

1. The appointments portal (198.51.100.60) logs the connections it receives. How many Azahar addresses does it see, and which?
2. A TCP packet arrives from outside with destination 203.0.113.194:40002. What does the router do with it, step by step?
3. A TCP packet arrives from outside with destination 203.0.113.194:443. What does the router do, and why?
4. What is each internal machine plausibly doing? (Hint: .21 is the reception PC, .40 a tablet, .10 the server.)
5. When an Elche PC queries the medical records server, does a row appear in this table?

📌 Review if you struggled: lesson 05-03.

1. Just one: 203.0.113.194. The first two rows (reception and tablet) go to the portal, but both leave translated to the same public IP with different ports (40001 and 40002). To the portal, "all of Clínica Azahar" is one address — the essence of PAT.
2. Step by step: the router looks up external port 40002 in the table → finds the tablet's row → rewrites the destination 203.0.113.194:40002 → 172.20.40.40:49802 → recalculates checksums → delivers the packet on the LAN to the tablet. The translation is undone transparently.
3. It looks up 443 as an external port in the table: no row (nobody inside initiated that connection with that external port) and there is no DNAT rule for 443. It drops it. That is NAT's "pseudo-firewall": unsolicited inbound traffic dies at the router.
4. A plausible reading: reception (.21) is using the appointments portal over HTTPS and resolving a name via DNS (the UDP:53 row against 192.0.2.53); the tablet (.40) is also on the appointments portal; the server (.10) holds an outbound HTTPS connection to 198.51.100.25 — say, uploading the backup or downloading updates. Fine print: the server showing up as the source of an outbound connection is normal; servers are clients of other servers too.
5. No. Elche → medical records travels through the site-to-site VPN tunnel with the private addresses intact end to end (172.20.40.98 → 172.20.40.10). NAT only acts at the border with the Internet; internal traffic between sites is not translated.

At Meridiano Valencia (public IP 203.0.113.50), an infected laptop on the guest Wi-Fi fires thousands of abusive requests at an online service. The service responds by banning "the attacker's IP". Result: five minutes later, nobody in Valencia — not Marta, not Ana, not the server — can use that service.

1. Which address did the service ban, and why does it affect everyone?
2. Can the external service tell the guilty laptop apart from Marta? Can Meridiano? With what?
3. Bilbao keeps accessing the service without any trouble. Why?

📌 Review if you struggled: lesson 05-03.

1. It banned 203.0.113.50 — the only address it sees. With PAT, Valencia's ~20 machines (corporate and guest VLANs included) share that public IP: banning "one" is banning everyone. Sharing an IP is sharing a reputation.
2. The external service, no: to it, all connections arrive from the same address (at most it can tell source ports apart, which don't identify machines in any stable way). Meridiano, yes: the router's NAT table (and its timestamped logs) maps each external connection to the internal private IP that created it. This is exactly why router logs are kept: 203.0.113.50:41207 at 10:32:15 → row → 192.168.x.x, the culprit.
3. Bilbao reaches the Internet through its own router with its own public IP — a different NAT border. The ban on Valencia's IP doesn't touch it. (And incidentally: if Bilbao's Internet traffic went through the VPN and exited via Valencia, it would be banned — egress topology matters.)

1. Compress to canonical form: 2001:0db8:00f0:0000:0000:0000:0000:0a2f
2. Compress to canonical form (careful, two runs of zeros): 2001:0db8:0000:0000:00aa:0000:0000:0001
3. Expand to all 8 groups: 2001:db8:5a00:113::1:20
4. Is 2001:db8::40::7 valid? Why?

📌 Review if you struggled: lesson 05-04.

4. Invalid: it contains two ::. It would be ambiguous — how many groups does each one hide? With 8 total groups and 4 visible there are 4 hidden, but they could split 1+3, 2+2 or 3+1: three different addresses. That is why the standard allows only one ::.

Classify each address (type and scope) and give its IPv4 "mental equivalent":

1. fe80::be24:11ff:fe9a:3c01
2. ::1
3. 2001:db8:5a00:10:d4a1:8c2e:90bb:41f7
4. fd12:3456:789a::10
5. ff02::2
6. ::

📌 Review if you struggled: lesson 05-04.

The nuance that marks out whoever has truly understood IPv6: seeing an fe80:: in an ip addr is not a problem (unlike a 169.254.x.x, which always is). And looking for "the broadcast address" of an IPv6 subnet is looking for something that doesn't exist.

The ISP delegates the prefix 2001:db8:5a00::/56 to Azahar.

1. How many /64 subnets fit in that /56?
2. Propose a /64 for each subnet of the plan from exercise 7 (Alicante wired, waiting room, Elche, Torrevieja), choosing readable subnet groups.
3. Do you need to size how many hosts fit in each one? And the two /30 tunnels — do they need a "small" block?

📌 Review if you struggled: lesson 05-04.

1. Subnet bits: 64 − 56 = 8 → 2⁸ = 256 /64 subnets. (Meridiano's /48 gave 65,536; a /56, typical for a small business, gives 256 — plenty for 3 sites.)
2. With the /56, the final octet of the fourth group is what gets enumerated:

The entire plan fits in four lines, no jumps, no 2^h − 2, no broadcast. Compare it with the sweat of exercise 7: that difference is IPv6. 3. No: each /64 has 2⁶⁴ addresses — the question "how many hosts fit?" loses its meaning. And the tunnels can be /64s too (e.g. 2001:db8:5a00:f1::/64 and :f2::/64): there is no scarcity to justify the /30's tailored fit. In IPv6 you count subnets, not hosts.

A recap of the stumbles that came up most (if you fell into several, that's normal; if you're still falling into them next week, review):

• Classifying without the mask. Network, broadcast or host is a verdict on the pair address+mask (exercises 3, 4, 8). Asking for the mask is the professional's number one reflex.
• Forgetting the −2 and the gateway when sizing (exercises 6 and 7): 2^h combinations, 2^h − 2 hosts, and the router takes one of them.
• VLSM in arrival order instead of largest→smallest: it produces misaligned blocks and holes (exercise 7).
• "Starts with 172, it's private": only from 172.16 to 172.31 (exercise 3). The second octet decides.
• Expanding IPv6 by padding on the right: 113 is 0113, not 1130 (exercise 11). Restored zeros go in front.
• Tip: verify every plan by adding up block sizes (≤ 256 in a /24?) and checking that each network is a multiple of its jump. Two checks, thirty seconds, zero overlaps.
• Tip: keep your solution to exercise 7. The Azahar plan you just designed is, literally, the stage on which things will break in the next lesson.

Weights session complete — the toughest in the gym. You have converted binary to decimal and back without a calculator, classified addresses with and without traps, run the 5-step method with the boundary in any octet, proved with numbers why fixed length doesn't work for Azahar and designed their complete VLSM plan (which is now your plan), read a NAT table the way the router reads it and reasoned out what the outside sees — and what it cannot see —, and closed with IPv6: compressing, expanding, classifying and planning in four lines what in IPv4 cost a page of arithmetic.

One last session of the course remains, and it is unlike all the others: in Case Studies there are no more sections by topic, no hints about which lesson to review. There will be symptoms, command outputs and users waiting — like in real life — and you will have to draw on the whole course at once: module 6's method, today's addressing, the protocols, the layers. The scenarios will sound familiar: Meridiano… and the Azahar network you just designed. Nothing ruins a good addressing plan quite like putting it into production.