DEV Community: yuanke215

I Wasted Half My /24s Before I Learned VLSM

yuanke215 — Wed, 14 Oct 2026 09:47:53 +0000

I ran an office network. The engineering floor had 60 machines, marketing had 25, finance had 15, and the executive floor had 4. Each team "just needs its own subnet," so I handed out four fresh /24s. That's 4 x 254 usable addresses — more than 1,000 — for a building with about 100 machines total. I was using roughly 10% of what I allocated and calling it good practice.

The same scene repeats everywhere: a /24 with 20 devices on it, a /26 holding 15, a VLAN with a printer and a door controller. Each one feels harmless, until you actually run out of address space and have to renumber the whole floor.

The fix is VLSM — Variable Length Subnet Masking. And it's a one-sentence rule once you see the word.

The one-sentence rule

VLSM means different subnets inside the same network can use different prefix lengths, so each subnet is sized to what it actually contains — instead of forcing every subnet to share the same width.

Without VLSM, if you're working inside 192.168.0.0/24, every subnet you carve out of it has the same size. Two /25s, each 126 usable addresses. A team of 15 gets 126 addresses and the other 111 sit idle. Then you run out of /24s and wonder where all the space went.

With VLSM, you mix the sizes freely: one /26 (62 usable) for engineering's 60 machines, a /27 (30 usable) for the 25-person team, another /27 (30 usable) for the 15-person team, and a /28 (14 usable) for the executive floor — all carved from a single /24.

A worked example (this is the whole trick)

Let's split 192.168.10.0/24, which gives 254 usable addresses, into four segments: 60 devices, 25 devices, 15 devices, and 4 devices.

For each, round the host count up to the next power of two, then subtract 2 for the network and broadcast addresses, then pick the prefix that matches:

Segment	Prefix	Addresses	Usable hosts	Assign to
192.168.10.0	/26	64	62	Engineering (60)
192.168.10.64	/27	32	30	Marketing (25)
192.168.10.96	/27	32	30	Finance (15)
192.168.10.128	/28	16	14	Exec (4)

Add up the usable hosts: 62 + 30 + 30 + 14 = 136 total — still barely half of the 254 the /24 could hold, but every team gets only as much as it needs.

The subtle part: VLSM doesn't mean "make every subnet as small as possible." It means "choose each subnet's size from the same /24 based on its need."

A quick reference for picking the prefix

You don't want to redo the subtraction every time you plan a segment, so here's the lookup I actually use:

Hosts needed	Block	Prefix	Usable
2	4	/30	2
6	8	/29	6
14	16	/28	14
30	32	/27	30
62	64	/26	62
126	128	/25	126
254	256	/24	254

To read it: "I need room for 60 machines" → 60 fits in the 64-size block → that's a /26, giving 62 usable.

That's the whole skill: memorize the "next power of two minus 2" ladder, and VLSM becomes table lookup instead of head-scratching.

When you should NOT use VLSM

Routing gets more complicated. Every width you mix in means the router carries more entries.
Future growth is harder. If "25 devices" becomes "80 next quarter," you're renumbering that subnet.
The next person has to read your mind. The cleverest allocation is the hardest to maintain.
You're still learning the basic power-of-two math. Flat equal-sized subnets are a fine starting point.

Build the plan without doing arithmetic in your head

When you're laying out several real segments, the subtraction slips — a /26 becomes a /28, or two blocks overlap. I keep a VLSM calculator that takes the network and the list of host counts, and returns a minimal, non-overlapping layout, showing the network, usable range, and hosts for each segment side by side. It's free, runs entirely in the browser, and makes the plan verifiable instead of vibes.

For the longer reasoning — why variable-length works and a fuller worked example — I've written it up in VLSM explained.

The takeaway is short: the /24 you give to a 4-person team isn't "playing it safe" — it's burning the exact thing that eventually runs out. VLSM keeps one clean address budget, gives each segment only what it needs, and leaves room for the next request. It stopped me from asking for "another /24 for five people," and it'll save your address space the same way.

An IPv4 Admin's First Hour with IPv6 Subnets

yuanke215 — Mon, 12 Oct 2026 14:07:25 +0000

If you've spent a decade in IPv4, the first time you look at an IPv6 subnet you'll feel a strong urge to do something deeply wrong: try to carve it up "efficiently."

Here's the trap. After years of VLANs and squeezing every last usable host out of a /24, the instinct is burned in — address space is precious, allocate it sparingly, never waste a bit. So someone hands you a /64, which contains more addresses than the entire IPv4 internet, and your hand reaches for the subnet calculator before your brain catches up.

Stop. That is the wrong tool for this job, and the mistake you are about to make is one of the most common (and most expensive to undo) things an IPv4 network admin does when they first touch IPv6.

Why your VLSM instinct is wrong on IPv6

In IPv4, subnetting exists to conserve a scarce resource. Every /24 you waste is a /24 you cannot give to the next department, so you subnet down to the last bit, allocating the tightest prefix that fits.

IPv6 inverts that logic. A /64 from your ISP's allocation is not waste — it is the expected minimum size. And here is the detail that catches most people: the /64 is not an abstraction. For most hosts it is a hard requirement.

This comes down to SLAAC, the Stateless Address Autoconfiguration mechanism. When an IPv6 host joins a network, it does not wait for a DHCP lease the way most IPv4 hosts do. It listens for a Router Advertisement, reads the 64-bit network prefix it contains, and then builds its own address by combining that prefix with a 64-bit interface identifier (often derived from its hardware address).

The "64" in /64 is not a coincidence. An IPv6 address is 128 bits, split exactly in half: 64 bits of network, 64 bits of interface. If you assign a prefix longer than /64 (a /72, an /80, anything carved further), a host cannot run SLAAC at all — there are not enough bits left to construct its own interface identifier. Devices that depend on SLAAC will simply fail to configure, and you'll spend an afternoon diagnosing "why won't anything on this segment get a network address" before realizing you handed it a /72.

So the mental model you need is almost the exact reverse of your IPv4 habits:

IPv4	IPv6
Default subnet is /24	Default subnet is /64
Subnetting conserves a scarce resource	Subnetting rarely needs to conserve
You split to the smallest usable size	You almost never go below /64 for a segment
Host address usually comes from DHCP	Host usually builds its own (SLAAC)
Being wrong wastes addresses	Being wrong breaks connectivity

The three traps IPv4 admins catch first

Trap 1: Treating /64 as "wasteful" and subnetting below it. You cannot make a /64 into two /65s and call it more efficient — you've just broken SLAAC for every client that needs it. If you have a real need for smaller segments, those prefixes are for router-to-router links, loopbacks, and special cases, not for a normal LAN with hosts.

Trap 2: Assuming the interface portion is a meaningful "host number." In IPv4 you look at the last octet and think "host 5." In IPv6 the interface identifier is an arbitrary 64-bit value, often randomized for privacy (which is why a device's address can change after a reboot). You cannot plan around stable, sequential host numbers the way you did with IPv4.

Trap 3: Trying to "save addresses" the way you saved a /24. You are not conserving anything. If your ISP gives you a single /64 and you need multiple networks, the real fix is a renumbering plan or a larger allocation from your provider — not cramming multiple LANs into one /64 and calling it subnetting.

What a correct IPv6 plan actually looks like

Here is the shape of an IPv6 deployment that doesn't blow up on you:

Your ISP allocates a /48 or /56 — the "normal size" block, big enough to be boring.
You split that into one /64 per VLAN, exactly the way you'd give each VLAN its own /24 in IPv4.
Each segment gets a clean, memorable prefix from your allocation (for example 2001:db8:1::/64 for the office LAN, 2001:db8:2::/64 for the server segment).
You let SLAAC handle host addressing. Servers that need DHCPv6 can get static or DHCP-assigned addresses, but the subnet boundary stays /64.

The rule of thumb that makes this click: in IPv6, /64 is your /24. It is the default, the boring, the correct choice. When someone asks "what prefix should I use for this segment," the overwhelming answer is /64 — and the interesting part of your job is deciding which /64, not how small it can be.

Check your work with a calculator

The math slips fast when you're new — you transpose a /64 and a /56, or you're not sure whether 2001:db8:1::/64 includes the range you think it does. I built an IPv6 subnet calculator that takes an IPv6 address and prefix and returns the network address, first and last usable addresses, and the total /64 count — handy for verifying a segment against your plan.

For the full mental shift — why the /64 is required, the SLAAC rule, and a worked example — I wrote it up in IPv6 Subnetting for IPv4 Network Admins. It's the page I wish I'd had the first time I planned an IPv6 office.

The one-sentence version: stop trying to be efficient with IPv6. The address space is not the thing you're fighting; clean routing is. Embrace the /64, assign one per segment, let SLAAC do the rest, and your first hour with IPv6 subnets goes from a pile of confusion to a boring, correct default.

The Hash You Pick Matters: MD5, SHA-1, SHA-256, and What Each Is Still Good For

yuanke215 — Tue, 06 Oct 2026 14:23:09 +0000

You download a 2 GB ISO from a mirror you have never heard of, the page shows a long checksum, and you skip it. Six months later, that same image is implicated in a supply-chain incident and your team spends a weekend rebuilding machines.

Checksums exist precisely to catch this. But the first question is not "how do I verify a hash" — it is "which hash am I supposed to be looking at, and is that hash still trustworthy?"

What a hash actually is

A hash function takes any input — a text string, a firmware image, a password — and produces a fixed-size fingerprint. Same input, same fingerprint. Change one bit of input and the fingerprint changes completely (or it should). MD5 always outputs 128 bits, SHA-256 always outputs 256 bits, regardless of input size.

The properties that matter:

Deterministic: the same bytes always produce the same digest.
Preimage resistant: given a digest, you cannot reconstruct the input.
Collision resistant: you cannot find two different inputs with the same digest (this is the one that has been broken for old algorithms).

The family tree, and what it means in practice

Algorithm	Output	Status	Use today
MD5	128-bit / 32 hex	Collision-broken (since 2004–2008)	Legacy checksums, dedup, cache keys — never security
SHA-1	160-bit / 40 hex	Collision-broken (2017 SHAttered)	Deprecated; avoid for anything new
SHA-256	256-bit / 64 hex	Secure	Default choice: downloads, TLS, Git, certificates
SHA-384 / SHA-512	384/512-bit	Secure	High-security contexts, longer hashes for HMAC

The nuance that surprises people: MD5 is not "useless" — it is useless for security. It is still perfectly fine for spotting accidental corruption, deduplicating files, or as a cache key. The breakage is about deliberately constructing a collision, which is an attack, not an accident.

Meanwhile SHA-1's collision break (two different PDFs with the same hash, demonstrated in 2017) means it is now publicly deprecated: browsers, Git, and operating systems have been migrating away from it for years.

Where hashes actually protect you day to day

1. Download integrity — the one you should do every time.
Every official Linux ISO page, every tool release on GitHub, publishes the SHA-256 checksum. Verifying takes seconds:

# Official download from the project's checksum file
sha256sum downloaded-file.iso
# compare the output against the published value

import hashlib

h = hashlib.sha256()
with open('download.iso', 'rb') as f:
    for chunk in iter(lambda: f.read(65536), b''):
        h.update(chunk)
print(h.hexdigest())

If the digest matches, the bytes you have are byte-for-byte identical to what the maintainer published. That is not the same as "safe" (you also need the checksum itself to come from a trusted channel) but it kills the entire class of "corrupted or swapped download" accidents.

2. Passwords — where you should NOT use these.

Here is the biggest hash misconception: passwords should not be hashed with MD5 or SHA-256 at all. They are fast, and fast is exactly what an attacker wants when brute-forcing. Password storage needs deliberately slow, salted functions: bcrypt, argon2, or scrypt. If you see a tutorial storing passwords as plain MD5 or SHA-256, it is teaching a vulnerability.

3. File dedup and change detection.

Hashes are the cheapest reliable "did this change" signal: config-drift checks, backup deduplication, registry of golden files. Collision risk is not a concern here because the input is not adversarial.

4. Git, signatures, containers.

Git commit IDs are SHA-1 (being slowly moved to SHA-256); software packages are signed with SHA-256 and then cryptographically signed; container images get digest pins. Same idea everywhere: a short fingerprint that is expensive to fake.

A 30-second way to sanity-check your own values

When you are debugging a mismatch — "the docs say the hash is X, but I keep getting Y" — the first thing to check is whether your tool produces the same digest for the exact same bytes. A hash calculator that runs MD5, SHA-1, SHA-256, SHA-384 and SHA-512 locally in the browser is handy for this: paste the string, check the output, and confirm whether the discrepancy is in the input (trailing newline, BOM, whitespace) or in the algorithm (mixing MD5 and SHA-256). The page never sends your data to a server, so it is safe for things like API keys and config snippets.

A trailing newline is the classic silent killer: echo "hello" | sha256sum and printf "hello" | sha256sum give different digests. Always verify with the exact bytes of the file — sha256sum on the file itself, not a copy-paste of its contents.

Rules of thumb

For anything security-related (signatures, TLS, authentication): use SHA-256 or stronger. Never MD5, never SHA-1.
For accidental-corruption detection (backups, downloads you wrote yourself): MD5 is still fine, but just use SHA-256 — it costs the same and removes the question entirely.
For passwords: bcrypt/argon2/scrypt, with a salt. Do not roll your own.
When a checksum mismatch appears: re-download first, then check the algorithm, then check for extra bytes (newline/BOM) — in that order.
Never trust a checksum served from the same server as the file, for anything that matters. Get it from the official channel.

The habit of verifying hashes costs 30 seconds and prevents the nastiest category of "I downloaded something once, and it was wrong" incidents. Start with the next big download you do this week — and notice how many releases still publish an old MD5 instead of SHA-256. That is a signal about the project's security posture all by itself.

Stop Storing IP Addresses as Strings: The Integer Trick That Makes Your Queries 10x Faster

yuanke215 — Tue, 06 Oct 2026 14:19:46 +0000

Your log table has 80 million rows. The client_ip column is a VARCHAR(15), indexed, and every analytics query that filters by IP range takes three seconds. The DBA shrugs: "that's just how IPs are stored."

It isn't. An IPv4 address is a 32-bit unsigned integer — 192.168.1.1 is literally 0xC0A80101 is literally 3232235777. Every time you store it as a string, you pay the price in storage, index size, and range-query performance. And you pay it again on every single query.

The number hiding inside every IPv4 address

An IPv4 address is four octets, each 8 bits, concatenated into one 32-bit number:

192.168.1.1

octet 1: 192 = 11000000
octet 2: 168 = 10101000
octet 3:   1 = 00000001
octet 4:   1 = 00000001

32-bit value = 11000000101010000000000100000001
decimal      = 3232235777

The math: 192 × 256³ + 168 × 256² + 1 × 256 + 1 = 3232235777.

That single integer is all the information in the address. Everything else — dotted decimal, hex, the network and host portions — is a view of those same 32 bits.

What string storage costs you

Concern	`VARCHAR(15)`	`INT UNSIGNED`
Storage per row	15 bytes (or more with utf8mb4)	4 bytes
Index size	large, poor locality	compact, sequential
Range query (`BETWEEN`)	string comparison, lexicographic surprises	native integer comparison
Membership check	regex/full scan territory	`BETWEEN` on an index

The lexicographic trap is the sneaky one. SELECT ... WHERE client_ip BETWEEN '10.1.0.1' AND '10.1.0.255' looks right but string comparison orders '10.1.0.255' < '10.1.1.0' — while '10.2.0.1' < '10.1.0.255' is also true, so a naive lexicographic range silently includes 10.2.x.x addresses. Every "why is my IP filter returning junk" ticket traces back to this.

Doing it right in MySQL

-- Store the integer, index it, done
CREATE TABLE access_log (
    id        BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    client_ip INT UNSIGNED NOT NULL,          -- 4 bytes, not 15
    ...
    INDEX idx_client_ip (client_ip)
);

-- Insert
INSERT INTO access_log (client_ip) VALUES (INET_ATON('192.168.1.1'));

-- Range query: every address in 192.168.1.0/24
SELECT * FROM access_log
WHERE client_ip BETWEEN INET_ATON('192.168.1.0') AND INET_ATON('192.168.1.255');

-- Read it back
SELECT INET_NTOA(client_ip) FROM access_log;

INET_ATON and INET_NTOA are built into MySQL and MariaDB, use the index, and are deterministic. The only migration cost is one schema change and one bulk update:

ALTER TABLE access_log MODIFY client_ip INT UNSIGNED NOT NULL;
UPDATE access_log SET client_ip = INET_ATON(client_ip); -- careful: needs a plan for live tables

(For live tables, do it in a staged fashion: add a new column, backfill in batches, swap, drop the old one.)

What about PostgreSQL, Python, and IPv6?

PostgreSQL has first-class INET and CIDR types that sort and index properly — use them, they beat both TEXT and naive integer storage.
Python: ipaddress module handles conversions cleanly:

import ipaddress

ip = ipaddress.ip_address('192.168.1.1')
print(int(ip))          # 3232235777
print(ipaddress.ip_address(3232235777))  # 192.168.1.1

# Whole subnet bounds as integers — trivial to turn into a BETWEEN query
net = ipaddress.ip_network('192.168.1.0/24')
print(int(net.network_address), int(net.broadcast_address))

IPv6: 128 bits, so the string-vs-int tradeoff is even worse. Store as BINARY(16) (or a DECIMAL(39,0) / VARBINARY in engines without one) — never as 39-character text if you can avoid it.

When you actually need the dotted form

Application logs and debugging always want 192.168.1.1. Conversion at read time is cheap: INET_NTOA on the way out costs microseconds per row, far less than the string storage costs you on every write and every range scan.

If you are doing this conversion by hand — subnet to bounds, or bounds back to dotted decimal — the IP Address Converter on IPCalcPlus converts IPv4 addresses between dotted decimal, binary, hex, octal, and integer formats and expands a CIDR block to its integer range. That is the exact arithmetic you would otherwise do twice for each subnet in a migration script. No data leaves the browser, so you can throw your real production ranges at it.

A checklist for your next migration

Identify every VARCHAR column that stores an IP (logs, user sessions, rate-limit tables, firewall rules).
Pick the type: MySQL/MariaDB → INT UNSIGNED; PostgreSQL → INET; IPv6 needs → BINARY(16).
Rewrite all queries touching that column to use the integer form — BETWEEN on the index instead of LIKE '10.0.%' or string comparison.
Backfill with staged updates; measure EXPLAIN before/after on the hottest query.
Never let an ORM sneak a string back in — cast at the boundary, not in the query.

The 15 minutes this migration takes will pay for itself the first time a range filter returns the right rows — fast. Integer IP storage is the kind of change that looks like a micro-optimization and behaves like a bugfix: it fixes correctness (string ordering) and performance (index scan) at the same time.

Your Firewall Speaks CIDR, Your Vendor Speaks IP Ranges

yuanke215 — Mon, 05 Oct 2026 14:56:57 +0000

A vendor sends you the access list to whitelist: "allow 203.0.113.16 through 203.0.113.79."

Cool. You paste it into your security group and the console politely refuses. Firewalls, cloud security groups, route tables, and ACLs all want CIDR blocks — a network address and a prefix length — not a start and end address.

So how many blocks is that range, exactly? And why can't it ever be one?

Why one range means several blocks

A CIDR block is rigid in two ways:

It always spans a power of two number of addresses (/24 = 256, /23 = 512...).
It always starts at an aligned boundary — a /22 starts at an address whose low 10 bits are zero, a /21 at an address whose low 11 bits are zero, and so on.

Real-world ranges don't respect either rule. 203.0.113.16 - 203.0.113.79 spans 64 addresses (a power of two, good), but it starts at .16, which is only aligned for blocks of 16 addresses. A single /26 at 203.0.113.0 would cover the whole range — but also 16 addresses you were not authorized to allow. Over-permissive by 25%.

The only exact representation is a split. This particular range decomposes into:

CIDR block	Covers	Addresses
`203.0.113.16/28`	.16 – .31	16
`203.0.113.32/27`	.32 – .63	32
`203.0.113.64/28`	.64 – .79	16

Three blocks, 64 addresses, union exactly equals the range. That's the firewall-safe answer.

The algorithm: greedily take the biggest legal block

The standard decomposition walks the range from its start, and at each step takes the largest block that satisfies both constraints:

def ip_to_int(ip):
    a, b, c, d = (int(x) for x in ip.split("."))
    return (a << 24) | (b << 16) | (c << 8) | d

def int_to_ip(n):
    return ".".join(str((n >> s) & 0xFF) for s in (24, 16, 8, 0))

def low_bit_align(v):
    """Largest power-of-two block size aligned at v."""
    if v == 0:
        return 32
    k = 0
    while v % 2 == 0:
        v //= 2
        k += 1
    return k

def floor_log2(n):
    k = 0
    while n >= 2:
        n //= 2
        k += 1
    return k

def range_to_cidr(start, end):
    blocks = []
    cur = start
    while cur <= end:
        size = min(low_bit_align(cur), floor_log2(end - cur + 1))
        count = 1 << size
        blocks.append((int_to_ip(cur), 32 - size, count))
        cur += count
    return blocks

for net, pfx, count in range_to_cidr(ip_to_int("203.0.113.16"), ip_to_int("203.0.113.79")):
    print(f"{net}/{pfx}  ({count} addresses)")

Each iteration is capped by two limits:

Alignment limit — how big a block can start here. low_bit_align counts the trailing zero bits of the current address: 203.0.113.16 ends in four zero bits (16 = 10000 in binary's low positions), so at most a 16-address block can start there.
Span limit — how big a block fits before the range's end. The largest power of two not exceeding the remaining addresses.

Take the smaller cap, emit the block, jump past it, repeat. Because each step grabs the biggest legal block, the result is the minimum number of CIDR blocks — no other exact cover uses fewer.

The staircase effect

When a range starts and ends on ragged boundaries, the output looks strange at first:

10.0.0.1  -  10.0.0.254   →

10.0.0.1/32
10.0.0.2/31
10.0.0.4/30
10.0.0.8/29
10.0.0.16/28
10.0.0.32/27
10.0.0.64/26
10.0.0.128/26
10.0.0.192/27
10.0.0.224/28
10.0.0.240/29
10.0.0.248/30
10.0.0.252/31
10.0.0.254/32

Fourteen blocks for 254 addresses! That's not a bug — it's the shape of an exact cover when you exclude the network address (10.0.0.0) and the broadcast address (10.0.0.255) from an otherwise tidy /24. The small blocks nibble the ragged start, big blocks eat the middle, and small blocks finish the ragged tail.

Compare that with the clean version: 10.20.0.0 - 10.23.255.255 decomposes to a single 10.20.0.0/14... if the addresses align. They do here, which is why designing ranges on power-of-two boundaries from day one saves everyone pain later.

Where this conversion actually pays off

Security group and firewall rules — the vendor-scope case above. Exact blocks mean you never allow more than you intended.
Route summarization — merging site ranges into the shortest prefix list keeps routing tables small.
Cloud migrations — moving 10.20.0.0 - 10.23.255.255 into AWS VPC subnets requires an exact decomposition before you can type a single subnet CIDR.
IPAM imports — spreadsheets record ranges; DHCP scopes, monitoring systems, and ACLs want prefixes.

The math is small enough to write yourself (you just saw the whole algorithm), but when you're staring at a migration spreadsheet with forty ranges, an IP range to CIDR converter that prints the block list with masks and address counts saves an afternoon of manual binary arithmetic — and unlike a firewall, it won't silently truncate your scope if you get an octet wrong.

Rules of thumb

If your range's length is a power of two and the start is aligned, you get exactly one block. Everything else splits.
Blocks never overlap in a correct decomposition — they tile the range edge to edge.
The block count explodes only at ragged boundaries. Round your allocations to power-of-two boundaries and future conversions collapse to a single line.
Always verify the union covers your range exactly — an extra address in a firewall rule is a security incident waiting for an auditor.

Next time a vendor sends you a range, you'll know in thirty seconds whether it's one clean block, a three-block staircase, or a fourteen-block monster — and exactly what to paste into that security group.

The Subnet Overlap Nobody Saw Coming (and the 30-Second Check That Catches It)

yuanke215 — Mon, 05 Oct 2026 14:47:06 +0000

Two offices merge. Both teams have been happily using 10.34.x.x for years. The network team stitches the sites together with a new VPN tunnel, updates the firewall, and goes home.

Three days later the help desk floods with tickets: the build server answers pings but not SSH, a printer works on Tuesdays, and one department swears the CRM "loads eventually, if you refresh five times."

Nothing is on fire. Everything is intermittent. Welcome to the worst failure mode in subnetting: overlapping subnets.

The case that started it

Site A was assigned 10.34.12.0/23. That block covers:

10.34.12.0  -  10.34.13.255   (512 addresses)

Site B, allocated by a different admin in a different year, got 10.34.13.0/24:

10.34.13.0  -  10.34.13.255   (256 addresses)

On paper both allocations look fine, and neither admin ever saw the other's spreadsheet. But B's entire /24 is inside A's /23. Every one of B's 256 addresses is claimed twice.

Once the tunnel comes up, packets for 10.34.13.x have two valid destinations. The routing table picks whichever route was installed last, ARP caches fight over the same targets, and traffic lands on whichever site the router currently prefers. Intermittent, direction-dependent, and maddening to troubleshoot.

The math is simpler than the debugging

Two subnets overlap exactly when their address intervals share at least one address. Forget prefix lengths — expand both blocks into a start and end address and compare intervals:

overlap(A, B)  =  start(A) <= end(B)  AND  start(B) <= end(A)

That's it. It works for equal prefixes, different prefixes, a /23 versus a /24, or a single host versus a whole /8.

In Python, the whole check fits on a napkin:

def ip_to_int(ip):
    a, b, c, d = (int(x) for x in ip.split("."))
    return (a << 24) | (b << 16) | (c << 8) | d

def mask_of(prefix):
    return (0xFFFFFFFF << (32 - prefix)) & 0xFFFFFFFF

def block_span(ip, prefix):
    base = ip_to_int(ip) & mask_of(prefix)
    return base, base + (1 << (32 - prefix)) - 1

def overlaps(a_ip, a_pfx, b_ip, b_pfx):
    a_start, a_end = block_span(a_ip, a_pfx)
    b_start, b_end = block_span(b_ip, b_pfx)
    return a_start <= b_end and b_start <= a_end

print(overlaps("10.34.12.0", 23, "10.34.28.0", 23))  # False - 3,584 apart, fine
print(overlaps("10.34.12.0", 23, "10.34.13.0", 24))  # True  - the incident above

When the blocks do not overlap, the same numbers tell you how much room is left between them — useful when you're about to hand out the next slice.

Three mistakes I keep seeing

1. Comparing prefixes instead of intervals. "It's a /23 and a /24, so they're different" is not a safety check. Nested prefixes overlap by definition. So do 10.34.13.0/24 and 10.34.13.128/25.

2. Trusting the network address someone typed. 10.34.12.7/23 and 10.34.12.0/23 are the same block — the network address is where the mask says it is, not where the host octets happen to sit. Always normalize before comparing.

3. Assuming private space is infinite and therefore safe. RFC 1918 gives you a lot of room, but mergers are exactly when two orgs discover they both carved up 10.x.x.x differently:

Block	Range	Addresses	Typical owner
`10.0.0.0/8`	10.0.0.0 – 10.255.255.255	16,777,216	Large enterprises
`172.16.0.0/12`	172.16.0.0 – 172.31.255.255	1,048,576	Mid-size networks, Docker defaults
`192.168.0.0/16`	192.168.0.0 – 192.168.255.255	65,536	Home and small office

One more trap: 100.64.0.0/10 is not private. RFC 6598 reserved it for carrier-grade NAT, and mobile carriers hand addresses from it to millions of devices. It looks internal (it isn't globally routed), but it isn't yours to subnet either. If you inherit an address plan using that block, treat it as someone else's shared space, not a free pool.

The 30-second pre-flight check

Before any allocation goes into the IPAM tool, run the interval check against every existing block in the same region:

Normalize the new block to its true start and end address.
Compare intervals against all neighbors — different prefix lengths included.
If anything overlaps, stop and re-plan. If nothing does, note the gap so the next allocation starts cleanly.

You can do this in a REPL, in a spreadsheet, or in a tool built for exactly this job — I keep a private IP range calculator bookmarked for the check, because it also tells me which RFC 1918 block (or special range like CGNAT, link-local, or loopback) an address falls into, which catches the third mistake in the same pass.

Why overlap is worse than a full outage

A hard outage gets paged immediately and fixed loudly. An overlap fails quietly: it usually doesn't break the path the monitoring probes use, so dashboards stay green while a subset of hosts flips between destinations. The failure surface is routing order, ARP timing, and DHCP lease renewals — all nondeterministic from the help desk's point of view.

That's why prevention is the whole game. The check costs 30 seconds before deployment; the incident costs a week of packet captures after.

401 vs 403 vs 404: The Status Code Mistakes That Break APIs

yuanke215 — Sun, 27 Sep 2026 03:11:16 +0000

Originally published at ipcalcplus.com.

Every API review I've ever done contains at least one of these bugs: a login failure that returns 500, a rate limit that returns 400, a "resource not found" that returns 403 for security reasons and confuses every client developer for the next two years.

Status codes are the API's contract with its clients. Break the contract and your consumers write defensive code around your bugs — code that then breaks when you fix the bug. This is a guide to the codes that actually matter, the distinctions people get wrong, and the two codes almost nobody uses correctly.

The two-second mental model

First digit = who broke it:

2xx — it worked
3xx — go somewhere else
4xx — the client broke it
5xx — the server broke it
1xx — hold on, I'm not done (mostly invisible; the one you'll see is 101 during a WebSocket upgrade)

That's the whole taxonomy. Everything interesting is in the distinctions within 4xx and 3xx.

401 vs 403: the distinction clients depend on

The most misused pair in REST.

401 Unauthorized actually means unauthenticated. The server does not know who you are. The client's correct response: acquire credentials (log in, refresh the token, add the API key) and retry.

403 Forbidden means authenticated but not allowed. The server knows exactly who you are and is declining to serve you. The client's correct response: give up. Retrying with the same credentials will produce the same answer.

When you return 403 for missing credentials, clients can't tell "I need to log in" from "I'm not permitted," and their retry logic breaks. The memorable version:

401 = "who are you?"
403 = "I know who you are, and no."

One deliberate exception: many APIs return 404 for resources the caller isn't allowed to know exist — a private repo is "not found" rather than "forbidden," so the API doesn't leak which IDs are valid. That's a legitimate design choice; document it, because it's the opposite of what clients expect.

404 vs 410, and the SEO angle nobody mentions

404 Not Found is the most famous code and the most expensive one to misuse on the web. The nuance: 410 Gone means "this used to exist and was deliberately removed." Search engines treat 410 as a stronger signal than 404 — a 404 page may come back, a 410 page won't, so it gets deindexed faster.

The related rule that preserves years of SEO work: when a URL moves permanently, 301 (or 308 for endpoints where the method must not change, like POST endpoints). A redesign that maps old URLs to 404 instead of 301 drops your search traffic within weeks — I've watched it happen, and the fix is always the same retrospective: export the old URL list, redirect everything, verify each target returns 200.

Within redirects, the pair that matters:

301 vs 302: permanent vs temporary. 301 transfers ranking to the new URL; 302 does not. Browsers convert POST to GET after a 301.
307 vs 308: same meanings, but method and body are preserved. For APIs, 307/308 are usually the correct choice; for public web pages, 301 remains the standard.

The pair everyone underuses: 202 and 204

Two codes that make APIs honest:

202 Accepted — "I received your request and will process it, but it isn't done." If your POST enqueues a job for async processing, 202 is the truthful answer. Returning 200 when the work hasn't happened yet means your client thinks the email was sent when it's actually still in a queue that will retry at 3 AM.

204 No Content — "succeeded, and there's nothing to return." The clean response for DELETE, or any operation with no meaningful body. 204 also carries a subtle contract: the response must have no body. Returning 200 with an empty string is what most APIs do, and it forces clients to handle two shapes for the same outcome.

The general principle behind both: return the code that describes what actually happened, not the code that makes the client happy. Fake-200 APIs push complexity downstream into consumer code, where it multiplies.

4xx codes that are worth their tokens

429 Too Many Requests — you're rate limiting. Include a Retry-After header; well-behaved clients honor it, and your effective load drops immediately.
422 Unprocessable Entity — syntactically valid JSON, semantically wrong data (email field contains a phone number). Many APIs collapse this into 400, which forces clients to parse the error body to learn what kind of failure it was.
415 Unsupported Media Type — you sent XML to a JSON endpoint. Distinct from 400, and trivially cheap to check.
451 Unavailable For Legal Reasons — the takedown code, named after Fahrenheit 451. You'll rarely return it, but you should know why your favorite site vanished in some region.

When the server is lying: 502, 503, 504

The 5xx trio behind every "is it just me?" incident:

502 Bad Gateway — your proxy (nginx, the load balancer) reached the backend and got garbage back, or nothing. Usually means the backend crashed or is misconfigured. Read the proxy's error log, not just the app log.
503 Service Unavailable — deliberately refusing: overloaded, or in maintenance. This is the "back off" signal, and the right response from a circuit breaker.
504 Gateway Timeout — the backend is up but too slow. Different fix from 502: this one is about timeouts and slow queries, not crashes.

The debugging shortcut: 502/504 mean "the proxy couldn't talk to the app" and 503 means "the app or the operator chose to say no." Three different log files, three different fixes — which is why "the site is down" tickets get resolved so much faster when the first question asked is which exact 5xx.

A debugging workflow that works

Reproduce with curl, capture headers, not just the body
4xx? It's the request — validate payload, URL, auth header, Content-Type
5xx? It's the server — application log first, proxy log second
Read the response headers: Retry-After, Location, WWW-Authenticate, Allow usually contain the actual fix
Fix minimally, redeploy, retest with the exact same request

The habit that pays compound interest: save the full headers of every interesting failure. The status code names the problem class; the headers usually name the problem.

If you want a searchable list of all this while you work — including the lesser-known codes and which fix goes with which — I keep a free HTTP status code reference and a longer 1xx-to-5xx guide at IPCalcPlus. Both run entirely in the browser, no signup. The Port Checker is next to it for the other half of "is it the network or the app" debugging.

Which wrong status code do you see most often in the wild? My vote: 500 for expired tokens.

Five Cron Fields, One Trap: The Scheduling Bug Nobody Expects

yuanke215 — Sun, 27 Sep 2026 03:05:27 +0000

Every backend eventually grows a cron job. Backups at 2 AM, digests at 8 AM, health checks every five minutes. And every team eventually hits the same wall: the schedule that fires at a time nobody asked for, in a timezone nobody configured, on a day-of-week nobody intended.

Cron syntax is five fields. It fits on a sticky note. The bugs do not come from the syntax — they come from the three places where different implementations disagree with each other. This is a field guide to all of it.

The five fields, in one breath

 ┌───────────── minute (0-59)
 │ ┌───────────── hour (0-23)
 │ │ ┌───────────── day of month (1-31)
 │ │ │ ┌───────────── month (1-12 or JAN-DEC)
 │ │ │ │ ┌───────────── day of week (0-6 or SUN-SAT; 7 = Sunday too)
 * * * * *  command

Four operators cover 99% of real expressions:

* — every value in the field
, — list: 6,18 in hours = 6 AM and 6 PM
- — range: MON-FRI
/ — step: */15 in minutes = every 15 minutes

One subtlety worth internalizing: */15 starts at the field's zero (0, 15, 30, 45), but 5/15 starts at 5 (5, 20, 35, 50). The start value shifts the whole sequence — this is the difference between "aligned" and "offset" intervals, and it matters when you are spreading load across workers.

The trap: day-of-month OR day-of-week

Here is the bug I have now seen three times in production, always from a competent engineer, always written down as "cron is weird."

The expression 0 0 1 * 1 looks like it means "midnight on the first of the month, if it's a Monday."

In standard Unix cron, it means "midnight on the first of the month AND midnight on every Monday." The relationship is OR, not AND. That job fires ~48 times a year instead of ~1.

The rule, straight from the Vixie cron man page: when both the day-of-month and day-of-week fields are restricted (neither is *), the job runs when either matches. To get true AND logic you need Quartz-style syntax (0 0 1 ? * 1, where ? means "no specific value") or a guard in the script itself.

This single rule explains most "my cron job runs at the wrong time" mysteries. If your target platform is Quartz, Spring, or Jenkins, check their docs — most treat the two day fields differently from Unix cron, which is exactly why the bug survives code review: it worked on the engineer's machine, and their machine was running a different scheduler.

The L, W, and # extensions (and where they get you fired)

Modern schedulers — Quartz, Spring, AWS EventBridge, Kubernetes — support three extensions beyond classic cron:

L — last: 0 0 L * * = last day of the month; 0 0 * * 5L = last Friday
W — nearest weekday: 0 0 15W * * = weekday closest to the 15th
# — nth weekday: 0 0 * * 1#3 = third Monday

These are genuinely useful for monthly report jobs. They are also silently invalid in classic Vixie cron — the daemon treats them as syntax errors. Copy an L expression from a Quartz tutorial into /etc/cron.d/ and your job simply never runs. No warning, no email, just silence.

The portability rule: know your target before you copy the expression. The quick reference:

Platform	Fields	L/W/#	Timezone
Unix crontab	5	no	system
Quartz / Spring	6-7	yes	JVM
Kubernetes CronJob	5	yes	node (or `timeZone`)
AWS EventBridge	6	yes	UTC
GitHub Actions	5	no	UTC

Timezone and DST: the silent schedule-shifters

Two production incidents waiting to happen:

1. UTC defaults in the cloud. "0 9 * * " means 9 AM in *the scheduler's timezone. On GitHub Actions and AWS EventBridge, that is UTC. Your 9 AM daily report for the New York office goes out at 5 AM local. Nobody notices for a week because 5 AM email is just "early," until someone checks timestamps during a debugging session.

2. Daylight saving transitions. A job scheduled inside the spring-forward hour (e.g., 2:30 AM in a US timezone) does not run at all that day — the wall-clock time never happens. During fall-back, a job in the repeated hour runs twice. If "runs exactly once per day" is a billing or audit requirement, that's a defect. The standard fix: schedule critical jobs in UTC, or outside DST transition windows.

The general principle: for anything with an external SLA (backups, billing, cert renewal), write the cron expression in UTC and document that it is UTC. For anything user-facing, use a scheduler that supports explicit timezones and set it deliberately.

Six expressions worth memorizing

You will type these for the rest of your career:

0 2 * * * — nightly at 2 AM (backups, the classic low-traffic window)
*/5 * * * * — every 5 minutes (health checks, watchdogs)
0 9 * * MON-FRI — weekday mornings (reports, digests)
15 4 * * 0 — Sunday 4:15 AM (log rotation, cleanup)
0 */2 * * * — every 2 hours (syncs, cache refresh)
0 0 1 * * — first of the month (invoices, archives)

And the debug checklist when a job "didn't run": (1) is the daemon alive? (2) is the expression valid for this scheduler? (3) is the timezone what you think it is? (4) did a DST boundary swallow it? (5) check the scheduler's own log, not just your application log. In my experience the answer is (3) about half the time.

When I'm porting a schedule between platforms I run it through a free Cron Expression Generator first — it parses the expression, describes it in plain English, and shows the next 10 run times, so a UTC bug or an OR-logic trap is visible before it ships. It runs entirely in the browser. There's a longer reference writeup of everything above, including the full platform table, in the Cron Expressions Guide.

What's the worst scheduling bug you've shipped? Bonus points if the root cause was a timezone.

Stop Guessing Subnet Sizes: A Practical Mental Model for IPv4 Subnetting

yuanke215 — Sun, 27 Sep 2026 03:00:08 +0000

Most people learn subnetting as a pile of formulas: count the bits, subtract two, memorize the table. That works for exams, but it falls apart the moment you are standing in front of a real network with an IP like 10.0.5.130/27 and someone asks "what network is this on?"

This article is the version I wish someone had given me: a single mental model that turns every subnetting question into arithmetic you can do in your head, plus the three shortcuts that make it fast.

The one idea that makes subnetting click

An IPv4 address is 32 bits. A prefix like /26 means: the first 26 bits are the network, the last 6 bits are the host. That's it. Everything else follows from this sentence.

The consequences of those 6 host bits:

Total addresses in the subnet: 2^6 = 64
Usable hosts: 64 - 2 = 62 (the first address is the network ID, the last is the broadcast)

Notice you never needed the subnet mask 255.255.255.192. The prefix and the mask are the same statement in two languages — but the prefix form is the one that keeps the math obvious.

The block size shortcut (replaces binary math)

Here is the shortcut that removes binary from your daily life:

Block size = 256 minus the last non-255 octet of the mask.

/26 → mask ends in .192 → block = 256 - 192 = 64
/27 → .224 → block = 32
/28 → .240 → block = 16

Once you have the block size, subnets can only start at multiples of that block: 0, 64, 128, 192 for a /26. No exceptions. This is the single most useful fact in practical subnetting, because it means you can validate anyone's network design in seconds.

Worked example: which subnet is 10.0.5.130/27 on?

Block size = 32
List multiples: 0, 32, 64, 96, 128, 160...
130 falls between 128 and 160 → network is 10.0.5.128/27
Usable range: .129 to .158, broadcast .159

You just did the entire subnetting calculation — network address, usable range, broadcast — with nothing but subtraction.

Sizing: the question people actually get wrong

The exam question "how many hosts in a /28?" is easy. The real question is "I have 28 devices — which prefix do I pick?" And here people consistently fail in the same direction: too tight.

28 devices in a /27 (30 usable) = one printer installation from an outage
The rule I use: current need + 30-50% headroom, then round up to the next prefix

So 28 devices → aim for ~40 → /27 gives 30, not enough → /26 gives 62, take it. Wasted space is cheap. Re-numbering a live network is not.

Three mistakes that cause real outages

1. Misaligned boundaries. Someone configures 192.168.1.50/26 as a "new subnet." The mask zeroes the lower 6 bits, so the actual network is 192.168.1.0/26 — the same subnet as the engineering VLAN. The config "looks valid" but silently overlaps. Rule: every network address must be a multiple of the block size.

2. Mask mismatch after migration. You re-subnet a segment from /24 to /26, but one server keeps the old /24 mask. It ARPs for addresses outside its real subnet, fails, and the ticket says "network is slow" — because the truth (half the hosts are unreachable) is invisible to the application team. Change masks in a maintenance window, all devices, all at once.

3. Forgetting the two reserved addresses. .0 and .255 (or block edges on other prefixes) are not usable. A device handed a network or broadcast address fails in ways that depend on the OS — which means the symptom looks random.

When unequal subnets are the right answer

Equal subnets are a training exercise. Real networks have one 60-person department and three 8-person teams, and giving everyone a /26 wastes three quarters of your address space. The professional answer is VLSM (Variable Length Subnet Masking): allocate the biggest subnet first, then fit the smaller ones into what remains.

For a /24 with a 50-host engineering team, a 30-device guest network, and two small teams:

Need	Prefix	Network
Engineering (50)	/26	`192.168.1.0/26`
Guest (30)	/27	`192.168.1.64/27`
Team A (12)	/28	`192.168.1.96/28`
Team B (8)	/28	`192.168.1.112/28`

Everything fits in the bottom half, and the entire top half stays free for growth. Start big and work down — never the reverse, or you fragment the range.

Sanity-check any design in 60 seconds

Before you touch a router, verify three things:

Alignment — every network address is a multiple of its block size
No overlaps — sort subnets by network address; each broadcast must be below the next network address
Capacity — usable hosts ≥ current devices × 1.3

If all three pass, the design is sound. If any fails, you have just prevented an outage that would have been very hard to diagnose later — subnetting bugs don't show up as "subnetting bugs," they show up as "the network is weird."

If you want to verify any of these calculations without doing them by hand — or you inherited a network and want to reverse-engineer which subnet an address belongs to — I maintain a free Subnet Calculator that runs entirely in your browser (no signup, nothing leaves your device). There is also a CIDR converter for jumping between prefix and range notation, and a subnet mask cheat sheet worth pinning next to your terminal.

What's your subnetting horror story? The misaligned-boundary one in the comments section is guaranteed to be good.

Hosts needed	Block	Prefix	Usable
2	4	/30	2
6	8	/29	6
14	16	/28	14
30	32	/27	30
62	64	/26	62
126	128	/25	126
254	256	/24	254

Hosts needed	Block	Prefix	Usable
2	4	/30	2
6	8	/29	6
14	16	/28	14
30	32	/27	30
62	64	/26	62
126	128	/25	126
254	256	/24	254

Hosts needed	Block	Prefix	Usable
2	4	/30	2
6	8	/29	6
14	16	/28	14
30	32	/27	30
62	64	/26	62
126	128	/25	126
254	256	/24	254