Understanding CIDR and Why Your Routing Table Still Breaks Anyway
CIDR — Classless Inter-Domain Routing — is the system we use to allocate IP addresses and summarize routes instead of sticking to the old classful boundaries. It replaced A/B/C classes because that system ran out of address space in the early 1990s and nobody wanted to admit it at the time. A /24 isn't fundamentally different from a /27 anymore. The notation just tells you how many bits are the network portion, and everything else is host space. That's it. The practical side of working with CIDR is really about two things: efficient address allocation and route aggregation. When you hand out blocks, you want them aligned to their natural boundaries. A /22 needs to start on a multiple of 1024 in the fourth octet. If you assign 10.0.5.0/22 and then later try to fit another block inside that range, you've painted yourself into a corner. I've seen engineers do this repeatedly because they don't manually check the boundaries before clicking "create subnet" in whatever web GUI their vendor provides. Route aggregation works the same way. If you have four /24s that share the same top bits, you can summarize them into a single /22. Routers love this. It shrinks the routing table and reduces churn. The catch is that aggregation only works cleanly when your address assignments actually follow the boundaries. Mix misaligned subnets and your summary route either won't cover everything or will swallow addresses you didn't intend to include.
I ran into a specific edge case last year where a customer had a /20 they'd carved into twelve /24s for various departments, then asked if they could aggregate down to a /22 for their WAN link. The problem was their allocations weren't contiguous — Department A got .0 through .3, Department B had .8 through .11, and several blocks in between were empty or assigned to different sites. A /22 summary would have included three /24 ranges they hadn't actually been allocated. I walked them through-planning the assignments so the used blocks formed a clean power-of-two boundary, then recalculated the summary. It took about twenty minutes of spreadsheet work and prevented a routing leak that would have exposed half their internal subnets to the internet. There's a counter-intuitive thing about CIDR that beginners miss: smaller prefixes aren't automatically better. Everyone wants to hand out /24s because they're familiar. But if your users only need ten hosts per segment, a /28 gives you sixteen addresses and wastes six. Over a large deployment with hundreds of segments, that waste adds up fast. I calculate the overhead by multiplying the unused addresses per subnet by the number of subnets, then comparing against a /28 design. In a typical enterprise with two hundred segments, switching from /24 to /28 for user VLANs recovers roughly 1,400 addresses per /24 you downsize. That's not trivia — that's the difference between needing a new /20 allocation or fitting everything into what you already have. Another thing people don't think about is overlap detection. When you're handed a block and need to verify it doesn't collide with existing allocations, most tools will check direct containment. They'll tell you if 10.0.5.0/24 falls inside 10.0.0.0/16. But they won't reliably tell you if your new /23 overlaps with an existing /22 that happens to share some but not all of its range. I built a simple script that iterates through every bit position and checks for any intersection between two prefix ranges. It runs in under a second and catches the cases where the GUI validation passes but the actual address space is conflicted.
The tooling side is straightforward. Most network operating systems support CIDR natively now. Cisco IOS, Juniper JunOS, Arista EOS — they all accept prefix-length notation. The calculation itself is bitwise math. Take your IP address, AND it with the subnet mask, and you get the network address. A /24 mask is 255.255.255.0, which in binary is twenty-four 1s followed by eight 0s. This is basic computer science, but I've talked to senior engineers who still pull up a calculator for every subnet calculation instead of doing it mentally. That's a productivity tax you pay every single time you configure a new interface. There are legitimate downsides to CIDR that get glossed over in certification study materials. Supernetting — aggregating multiple blocks into one announcement — means that if one of your underlying /24s goes down, the aggregate route still propagates. Traffic keeps flowing to a router that can't reach the failed subnet. You lose granular failover visibility unless you run a separate monitoring path. This is why BGP path filters and more specific route injection exist. They add complexity that defeats the original purpose of simplification. For home labs and small office setups, CIDR overhead isn't worth worrying about. A single /24 handles everything and you're done. The real pain shows up at scale — fifty or more subnets, multiple sites, dynamic routing protocols doing reconvergence every time someone misconfigures an advertisement. That's when the alignment rules and aggregation strategy matter, and that's also when most documentation stops being useful because it assumes ideal conditions.
Get the Full Details
