// CHAPTER 01
Why Subnetting Exists
Broadcast domains, the cost of a flat network, and what RFC 917 solved
// REAL-WORLD SCENARIO
Before subnetting existed, a company receiving a Class B allocation (e.g., 172.16.0.0/16) placed all 65,534 hosts on one flat broadcast domain. Every ARP request hit every host. Every DHCP Discover hit every host. Every NetBIOS name query hit every host. By 1983, networks with more than a few hundred devices were functionally unusable — the broadcast storm from normal operation consumed most of the available bandwidth. Dr. Jeff Mogul at Stanford published RFC 917 in 1984, proposing subnetting: take the single large allocation and divide it using a "subnet mask" into smaller, router-separated sub-networks. One flat /16 (one broadcast domain, 65,534 hosts) becomes 256 routed /24 subnets (256 broadcast domains of 254 hosts each). Broadcasts no longer propagate across the entire company. RFC 950 (1985) formalized the subnet mask mechanism. It became required in RFC 1122 (1989). Modern networking is built on it.
Subnetting is the process of dividing a larger IP network into smaller sub-networks by extending the network portion of the address — borrowing bits from the host portion to create more networks, each with fewer hosts. The mathematical operation is simple: the subnet mask ANDed with the IP address yields the network address, and the boundary where the network portion ends is where the subnet is "cut."
Why Subnetting Still Matters in 2024
Broadcast domain segmentation: ARP, DHCP, OSPF hello packets, and other broadcast/multicast traffic are contained within their subnet. A switch with 1,000 ports and no subnetting delivers every ARP flood to all 1,000 devices. Subdivided into /24 subnets (254 hosts each), an ARP flood reaches only 253 other hosts.
Security enforcement: Routers between subnets create packet inspection boundaries. Firewall rules, ACLs, and security group policies operate between subnets. A flat network cannot be selectively restricted — every host can reach every other host directly. Subnets are the granularity at which security policy is applied in nearly every enterprise, cloud, and container environment.
Address efficiency: A department with 30 devices gets a /27 (30 hosts) rather than a /24 (254 hosts). The saved addresses serve other subnets. In RFC 1918 private space this matters less — but in cloud environments (AWS, GCP, Azure), VPC CIDR blocks are finite and subnetting determines how many services can be deployed.
Routing hierarchy and summarization: Hierarchically allocated subnets enable route aggregation. A site with 20 /24 subnets from 10.5.0.0/20 can advertise one summary route (/20) to the rest of the network instead of 20 individual entries. This reduces routing table sizes by orders of magnitude.
🧠 Subnetting is the #1 Tested Skill in Network Engineering Interviews
Across Cisco CCNA/CCNP/CCIE, CompTIA Network+, AWS Solutions Architect, and nearly every network engineer technical interview, subnetting questions appear. Not because they're artificially hard, but because they test binary fluency — the foundation of all network addressing. Engineers who can subnet in their heads (no calculator) demonstrate genuine understanding of IP address structure. The technique is straightforward once you internalize the binary relationship: everything is powers of 2, block sizes are always powers of 2, subnet boundaries are always multiples of the block size.
// CHAPTER 02
The Binary Mechanics of Subnetting
Borrowing bits, block sizes, and subnet boundaries from first principles
Subnetting is pure binary arithmetic. To subnet a /24 network, you take the last 8 bits (the host portion) and decide how many to "donate" to the network portion. Each donated bit:
— doubles the number of available subnets
— halves the number of hosts per subnet
— halves the block size (the address range each subnet covers)
Subnetting a /24 — bit borrowing visualization
Original /24:
11000000.10101000.00000001 | 00000000
←─────── 24 network bits ────────→ ← 8 host →
Borrow 1 → /25: ...00000001.0 | 0000000 (2 subnets, 126 hosts, block 128)
Borrow 2 → /26: ...00000001.00 | 000000 (4 subnets, 62 hosts, block 64)
Borrow 3 → /27: ...00000001.000 | 00000 (8 subnets, 30 hosts, block 32)
Borrow 4 → /28: ...00000001.0000 | 0000 (16 subnets, 14 hosts, block 16)
Borrow 5 → /29: ...00000001.00000 | 000 (32 subnets, 6 hosts, block 8)
Borrow 6 → /30: ...00000001.000000 | 00 (64 subnets, 2 hosts, block 4)
Borrow 7 → /31: ...00000001.0000000 | 0 (RFC 3021 point-to-point, 2 usable)
Borrow 8 → /32: all bits = network, 0 hosts (host route)
The Block Size: The Most Useful Mental Tool
The block size is the total number of addresses in each subnet, including network and broadcast. It equals 2^(host bits) = 2^(32 - prefix). For a /26, block size = 2^6 = 64. For a /27, block size = 2^5 = 32.
The critical insight: all subnets of a given prefix must start at addresses that are multiples of their block size. This is subnet boundary alignment. A /26 (block 64) must start at 0, 64, 128, or 192 in the relevant octet. A /27 (block 32) at 0, 32, 64, 96, 128, 160, 192, 224. This is not arbitrary — it flows directly from the binary AND operation used to compute network addresses.
Why alignment is mandatory — binary AND verification
/26 at a VALID boundary (192.168.1.64):
IP: 11000000.10101000.00000001.01000000 (192.168.1.64)
Mask: 11111111.11111111.11111111.11000000 (/26)
AND: 11000000.10101000.00000001.01000000 = 192.168.1.64 ✓ (= itself)
/26 at an INVALID boundary (192.168.1.70):
IP: 11000000.10101000.00000001.01000110 (192.168.1.70)
Mask: 11111111.11111111.11111111.11000000 (/26)
AND: 11000000.10101000.00000001.01000000 = 192.168.1.64 ✗
→ 192.168.1.70 is NOT a network address for /26 — it's a host in 192.168.1.64/26.
A router configured with 192.168.1.70/26 will calculate the wrong subnet.
Core Formulas
Given original prefix /n and borrowing k bits to create /{n+k} subnets:
Subnetting formulas
Number of subnets = 2^k
Hosts per subnet = 2^(32 - n - k) - 2 [subtract network + broadcast]
Block size = 2^(32 - n - k) [= hosts + 2]
Subnet mask = 255.255.255.{256 - block_size} [for /25–/30 in 4th octet]
For /29 (borrowing 5 bits from /24):
k = 5 → subnets = 2^5 = 32
host bits = 32-24-5 = 3 → hosts = 2^3 - 2 = 6
block = 8 → mask = 255.255.255.248
The "256 - block_size" trick works only for prefixes in the 4th octet (/25–/30).
For 3rd-octet prefixes (/17–/24), apply to the 3rd octet instead.Full /24 Subnetting Reference
All subnets derivable from a /24
Prefix Mask Block Subnets Hosts Boundaries (4th octet)
/25 255.255.255.128 128 2 126 0, 128
/26 255.255.255.192 64 4 62 0, 64, 128, 192
/27 255.255.255.224 32 8 30 0,32,64,96,128,160,192,224
/28 255.255.255.240 16 16 14 0,16,32,...,224,240
/29 255.255.255.248 8 32 6 0,8,16,...,248
/30 255.255.255.252 4 64 2 0,4,8,...,252
/31 255.255.255.254 2 128 2 (P2P) 0,2,4,...,254
/32 255.255.255.255 1 256 0 (host) 0,1,2,...,255
SUBNET CALCULATOR
Enter a base network and choose a subnet prefix to see how subnetting divides the address space.
| # | Network | Broadcast | First Host | Last Host | Hosts |
|---|
| 1 | 10.0.0.0/24 | 10.0.0.255 | 10.0.0.1 | 10.0.0.254 | 254 |
| 2 | 10.0.1.0/24 | 10.0.1.255 | 10.0.1.1 | 10.0.1.254 | 254 |
| 3 | 10.0.2.0/24 | 10.0.2.255 | 10.0.2.1 | 10.0.2.254 | 254 |
| 4 | 10.0.3.0/24 | 10.0.3.255 | 10.0.3.1 | 10.0.3.254 | 254 |
| 5 | 10.0.4.0/24 | 10.0.4.255 | 10.0.4.1 | 10.0.4.254 | 254 |
| 6 | 10.0.5.0/24 | 10.0.5.255 | 10.0.5.1 | 10.0.5.254 | 254 |
| 7 | 10.0.6.0/24 | 10.0.6.255 | 10.0.6.1 | 10.0.6.254 | 254 |
| 8 | 10.0.7.0/24 | 10.0.7.255 | 10.0.7.1 | 10.0.7.254 | 254 |
| … 248 more subnets not shown |
// CHAPTER 03
Mental Subnetting: The Four-Step Method
Solve any subnet question in under 10 seconds without a calculator
// REAL-WORLD SCENARIO
A CCIE written exam has 100 questions in 2 hours. At 72 seconds per question, you cannot open a subnet calculator. When the question says "10.0.0.0/8 is subnetted into /20s — which subnet contains host 10.5.100.50?", you need the answer in under 8 seconds. The mental method: /20 → interesting octet is 3rd (prefix 17-24 = 3rd octet territory; prefix 25-32 = 4th octet territory; prefix 9-16 = 2nd octet territory; prefix 1-8 = 1st). Block size in 3rd octet = 2^(24-20) = 16. 100 ÷ 16 = 6 remainder 4. Network = 6 × 16 = 96. Subnet: 10.5.96.0/20. Done. Eight seconds.
Step 1 — Find the Prefix
Given a host count requirement, find the minimum host bits that satisfy hosts + 2 ≤ 2^h. Then prefix = 32 − h.
Finding the right prefix for a given host count
Hosts needed → minimum 2^h → prefix
2 → 2^2=4 → /30 (2 usable hosts)
6 → 2^3=8 → /29 (6 usable)
14 → 2^4=16 → /28 (14 usable)
30 → 2^5=32 → /27 (30 usable)
50 → 2^6=64 → /26 (62 usable)
60 → 2^6=64 → /26 (62 usable)
100 → 2^7=128 → /25 (126 usable)
200 → 2^8=256 → /24 (254 usable)
500 → 2^9=512 → /23 (510 usable)
1000 → 2^10=1024 → /22 (1022 usable)
2000 → 2^11=2048 → /21 (2046 usable)Step 2 — Identify the Interesting Octet
The "interesting octet" is the octet where the prefix boundary falls — where some bits are network and some are host. Prefixes /1–/8 are interesting in the 1st octet, /9–/16 in the 2nd, /17–/24 in the 3rd, /25–/32 in the 4th.
Identifying the interesting octet
Prefix Interesting octet Example
/8 1st 10.x.x.x — whole network is "10"
/16 2nd 172.16.x.x — block increments in octet 2
/20 3rd 10.5.96.0 — block increments in octet 3
/24 3rd (last bit) 192.168.5.0 — whole 3rd octet = network
/26 4th 192.168.1.64/26 — block in 4th octet
/30 4th 10.0.0.4/30 — tiny P2P blocks in 4th octet
Step 3 — Find the Block Size in the Interesting Octet
Block size in the interesting octet = 2^(bits left after the prefix in that octet). For /26 in the 4th octet: 32 − 26 = 6 host bits. Block = 2^6 = 64. For /20 in the 3rd octet: 24 − 20 = 4 bits. Block in 3rd octet = 2^4 = 16 (meaning subnet boundaries in the 3rd octet are 0, 16, 32, 48 ... etc).
Step 4 — Find Which Subnet Contains the Host
Take the interesting octet value from the IP address. Divide by block size (integer division). Multiply back. That's your network address in that octet. Broadcast = network + block − 1 in that octet.
Mental method worked examples
Example 1: Which subnet is 192.168.1.100 in for /26?
Interesting octet: 4th. Block = 64.
100 ÷ 64 = 1, rem 36. Network = 1×64 = 64.
→ Network: 192.168.1.64/26. Broadcast: 192.168.1.127. Hosts: .65–.126
Example 2: Which subnet is 10.5.100.50 in for /20?
Interesting octet: 3rd. Block in 3rd = 2^(24-20) = 16.
100 ÷ 16 = 6, rem 4. Network = 6×16 = 96.
→ Network: 10.5.96.0/20. Broadcast: 10.5.111.255. Hosts: .96.1–.111.254
Example 3: Which subnet is 172.16.250.10 in for /12?
Interesting octet: 2nd. Block in 2nd = 2^(16-12) = 16.
16 ÷ 16 = 1, rem 0. Network = 1×16 = 16.
→ Network: 172.16.0.0/12. Broadcast: 172.31.255.255.
(All of 172.16.x.x–172.31.x.x is within this /12 block.)
SUBNETTING QUIZ
Mental subnetting — solve without a calculator.
Question 1 / 6Score: 0
192.168.5.200/26 — what is the network address?
192.168.5.0
192.168.5.192
192.168.5.200
192.168.5.128
// CHAPTER 04
VLSM — Variable Length Subnet Masking
Different prefix lengths for different needs — the universal standard
// REAL-WORLD SCENARIO
A company gets 192.168.0.0/22 (1022 usable addresses) and must connect: Engineering (120 users), Sales (60 users), Servers (30 machines), HR (14 users), Management VLAN (6 switches), and 2 router point-to-point links (2 endpoints each). If you use fixed-length /25 subnets (126 hosts each): you get 8 subnets × 126 hosts = 1008 possible assignments. But the router links use only 2 of their 126 slots each — wasting 248 addresses on router cables. VLSM assigns exactly what each segment needs: /25 for Engineering, /26 for Sales, /27 for Servers, /28 for HR, /29 for Management, /30 for each router link. Total allocated: 252 of 1022 addresses. Total wasted: only 8 (alignment gaps) rather than hundreds.
VLSM (Variable Length Subnet Masking) allows different subnets within the same address space to use different prefix lengths. This has been standard practice since OSPF version 2 (1991) introduced classless routing updates. Fixed-length subnetting — where every subnet is the same size — still appears in coursework but is considered wasteful in any production environment.
The VLSM Design Process: Largest First
The cardinal rule: always allocate the largest subnet first. Starting with the smallest leaves insufficient contiguous space for larger subnets (which have stronger alignment requirements). A /25 must start at 0 or 128 in the 4th octet — if you've already placed small subnets at 0 and 4 and 8, there may be no valid /25 boundary remaining.
VLSM allocation procedure
Base: 192.168.0.0/22 (1024 total, 1022 usable)
1. Sort requirements largest to smallest:
Engineering: 120 hosts → /25 (126 usable), block 128
Sales: 60 hosts → /26 (62 usable), block 64
Servers: 30 hosts → /27 (30 usable), block 32
HR: 14 hosts → /28 (14 usable), block 16
Management: 6 hosts → /29 (6 usable), block 8
Router link A: 2 hosts → /30 (2 usable), block 4
Router link B: 2 hosts → /30 (2 usable), block 4
2. Allocate sequentially from 192.168.0.0:
192.168.0.0/25 → Engineering (0–127, usable 1–126)
192.168.0.128/26 → Sales (128–191, usable 129–190)
192.168.0.192/27 → Servers (192–223, usable 193–222)
192.168.0.224/28 → HR (224–239, usable 225–238)
192.168.0.240/29 → Management (240–247, usable 241–246)
192.168.0.248/30 → Router link A (248–251, usable 249–250)
192.168.0.252/30 → Router link B (252–255, usable 253–254)
3. Verify: 128+64+32+16+8+4+4 = 256 addresses used (192.168.0.0/24 range)
Remaining: 192.168.1.0/24 through 192.168.3.255 (768 addresses) for future growth
VLSM PLANNER
Base: 192.168.0.0/22 (1022 usable). Allocated largest-first using VLSM.
Click any row to see the allocation detail and efficiency.
SegmentNeededPrefixAllocated BlockHosts
Engineering120/25192.168.0.0/25126
Sales60/26192.168.0.128/2662
Servers30/27192.168.0.192/2730
HR14/28192.168.0.224/2814
Management6/29192.168.0.240/296
Router link A2/30192.168.0.248/302
Router link B2/30192.168.0.252/302
Remaining
768 addresses free
VLSM Alignment Verification
After allocating each subnet, verify: does the network address divide evenly by the block size? If not, the subnet is misaligned — there is a gap in the allocation or an overlap.
Alignment check
Check 192.168.0.128/26 (block 64):
128 ÷ 64 = 2 with remainder 0 ✓ — valid boundary
Check 192.168.0.192/27 (block 32):
192 ÷ 32 = 6 with remainder 0 ✓ — valid
What if we tried to start the /28 at 230 instead of 224?
230 ÷ 16 = 14 remainder 6 ✗ — invalid. Nearest valid: 224 or 240.
⚠ Non-contiguous VLSM creates routing black holes
VLSM relies on contiguous sequential allocation. If you assign 192.168.0.0/25, then jump to 192.168.0.200/27 without assigning 192.168.0.128/26, the range 192.168.0.128–199 is unallocated but potentially covered by a summary route. Packets to those addresses are delivered to the router advertising the summary but have no more-specific route — they are silently dropped. Always allocate sequentially from the base network.
// CHAPTER 05
Supernetting and Route Aggregation
Combining contiguous subnets into one summary prefix — reducing routing table size
The reverse of subnetting is supernetting — combining multiple smaller prefixes into one larger aggregate prefix for routing advertisement. This reduces routing table entries and is essential for scalable network design. A router advertising one /20 covers 16 /24 subnets with one table entry rather than 16.
Requirements for Valid Summarization
For networks to be summarized into a single prefix: (1) they must be contiguous in binary — no gaps; (2) the set must be a power-of-2 multiple (1, 2, 4, 8, 16...) starting at a boundary aligned to the summary prefix's block size; (3) the summary prefix must exactly cover the aggregate — no more, no less — or you'll advertise address space you don't own.
Finding the Summary Route via Binary
Write all network addresses in binary, aligned. Find the rightmost bit position where all addresses agree. The summary prefix length is that position. The summary network address uses all the common bits, with the remaining bits set to 0.
Route summarization examples
Example 1: Summarize four /24s
10.4.0.0/24: ...00000100.00000000
10.4.1.0/24: ...00000100.00000001
10.4.2.0/24: ...00000100.00000010
10.4.3.0/24: ...00000100.00000011
↑↑ last two bits differ
Common prefix in 3rd octet: 000001xx — 6 bits agree.
Total: 16 + 6 = /22. Summary: 10.4.0.0/22 ✓
Example 2: Summarize 192.168.8.0/24 and 192.168.9.0/24
3rd octet: 00001000 (8) vs 00001001 (9)
↑ differs at bit 0
Common: 0000100x — 7 bits. Total: 16+7 = /23. Summary: 192.168.8.0/23 ✓
Example 3: Can we summarize 192.168.8.0/24 and 192.168.10.0/24?
3rd octet: 00001000 (8) vs 00001010 (10)
↑ differs at bit 1
Summary would be /22 (covering .8, .9, .10, .11).
BUT .9 and .11 are not in our list — advertising /22 claims space we don't own.
→ These cannot be cleanly summarized. They need separate route entries.Discontinuous Summarization: A Dangerous Trap
A summary route that covers address space you don't control is actively harmful. If your router advertises 10.4.0.0/22 but only controls 10.4.0.0/24 and 10.4.3.0/24 (not .1 or .2), traffic to 10.4.1.x and 10.4.2.x will reach your router (following the summary) but find no more-specific route — packets are blackholed. Always verify that a summary prefix covers exactly the networks you're advertising and no more.
Supernetting and CIDR on the Internet
BGP relies on supernetting for scalability. An ISP with 100 customer /24 allocations from the contiguous block 203.0.0.0/16 advertises one /16 to the global BGP table instead of 100 /24s. This is why internet BGP tables have ~900K entries rather than tens of millions. Each entry in the DFZ (Default-Free Zone) table represents a prefix where further aggregation is impossible — either due to multi-homing (customer announcing its /24 from two ISPs to control inbound routing) or non-contiguous historical allocations.
// CHAPTER 06
Subnetting Across Octets
When the interesting octet is not the fourth — /8, /16, and cross-boundary subnets
// REAL-WORLD SCENARIO
A CCIE candidate stalls on the exam question: "10.0.0.0/8 is subnetted with mask 255.248.0.0 — how many subnets, and which subnet contains host 10.25.100.50?" Students who memorized /25–/30 tables hit a wall here. But the method is identical. The mask 255.248.0.0 = /13. Interesting octet: 2nd (prefix between /9 and /16 falls in the 2nd octet). Block in 2nd octet = 2^(16-13) = 8. Subnets from /8 to /13 = 2^(13-8) = 32. Host 10.25.100.50: 2nd octet = 25. 25 ÷ 8 = 3, rem 1. Network in 2nd octet = 3 × 8 = 24. Subnet: 10.24.0.0/13. Broadcast: 10.31.255.255. Problem solved.
The four-step mental method works identically for any prefix length — the only variable is which octet is "interesting." Prefixes /9–/16 affect the 2nd octet; /17–/24 affect the 3rd octet.
Cross-octet subnetting examples
/16 subnets from 10.0.0.0/8:
Interesting: 2nd octet. Block in 2nd = 2^(16-16) = 1.
Subnets: 10.0.0.0/16, 10.1.0.0/16, ..., 10.255.0.0/16 (256 subnets)
/20 subnets from 172.16.0.0/16:
Interesting: 3rd octet. Block in 3rd = 2^(24-20) = 16.
Subnets: 172.16.0.0/20, 172.16.16.0/20, ..., 172.16.240.0/20 (16 subnets)
Host 172.16.35.10: 35 ÷ 16 = 2 rem 3. Network = 2×16 = 32. → 172.16.32.0/20
/12 subnets from 10.0.0.0/8:
Interesting: 2nd octet. Block in 2nd = 2^(16-12) = 16.
Subnets: 10.0.0.0/12, 10.16.0.0/12, 10.32.0.0/12, ..., 10.240.0.0/12 (16 subnets)
/23 subnets from 192.168.0.0/16:
Interesting: 3rd octet. Block in 3rd = 2^(24-23) = 2.
Subnets: 192.168.0.0/23, 192.168.2.0/23, ..., 192.168.254.0/23 (128 subnets)
Each covers two consecutive 3rd-octet values (.0+.1, .2+.3, etc.)
The /24 as a Boundary Anchor
The /24 is a special case: the prefix boundary falls exactly at the end of the 3rd octet, so the entire 4th octet is host space. This makes /24s the most intuitive subnet to work with — the 3rd octet identifies the network (e.g., "the 10.1.5 subnet"), the 4th octet identifies the host. Most IT practitioners and documentation use /24 as the default subnet size because of this clean boundary. It's not always the right choice (wasteful for small segments, undersized for large ones), but it's the cognitive baseline.
// CHAPTER 07
/31 and /32: Special Prefix Cases
RFC 3021, host routes, loopbacks, and when 'no broadcast' matters
/30 — The Classical Point-to-Point Subnet
Before RFC 3021, every routed link between two network devices was assigned a /30 — the smallest "normal" subnet with 2 usable host addresses. Block size 4: addresses .0 (network), .1 (router A), .2 (router B), .3 (broadcast). The network and broadcast are "wasted" in the sense that they can never be assigned to a host, but this was accepted as the minimum overhead for a routed link.
/31 — RFC 3021 Point-to-Point (No Network/Broadcast)
RFC 3021 (2000) recognized that the network and broadcast addresses serve no purpose on a strictly point-to-point link — there are only two devices, and neither ARP nor broadcast is needed. A /31 contains exactly 2 addresses, and RFC 3021 explicitly permits both to be assigned to hosts. This saves 2 addresses per link compared to /30.
In a large ISP with 10,000 router links, the difference between /30 and /31 is 20,000 addresses — an entire /18 recovered. Cisco IOS (since 12.2), Juniper JunOS, Arista EOS, and all modern router platforms support /31 on point-to-point interfaces. The only constraint: the connected host must also support /31 (no legacy equipment expecting a broadcast address on point-to-point links).
/30 vs /31 on router interfaces
# /30 — classical approach
interface GigabitEthernet0/0
ip address 10.0.0.1 255.255.255.252 ! .1 is router A, .2 is router B
! Network: 10.0.0.0, broadcast: 10.0.0.3 — both wasted
# /31 — RFC 3021
interface GigabitEthernet0/0
ip address 10.0.0.0 255.255.255.254 ! .0 is router A, .1 is router B
! No network/broadcast — both addresses usable
# IPv6 equivalent (/127, RFC 6164)
interface GigabitEthernet0/0
ipv6 address 2001:db8::1/127 ! .0 and .1 both usable
/32 — Host Routes
A /32 is a single IP address with no subnet context. It identifies one specific interface. Uses: loopback interfaces on routers (Loopback0 with /32 IP, used as the OSPF router ID and stable management address — never goes down even if physical interfaces fail), policy routing to override normal routing for a specific host, BGP network statements to advertise exactly one IP, and VPN endpoint addressing. A /32 is also used in security contexts: a /32 ACL entry matches exactly one host with no possibility of matching adjacent hosts accidentally.
/32 host routes in routing tables
# Cisco — inject specific host route
ip route 10.10.10.50 255.255.255.255 10.0.0.1
# This /32 overrides any less-specific route (e.g., 10.10.10.0/24) via LPM
# Loopback0 — router management IP as /32
interface Loopback0
ip address 10.255.255.1 255.255.255.255 ! Router ID, always up
# Routing table result:
# C 10.255.255.1/32 is directly connected, Loopback0
# → Reachable even when all physical interfaces flap
// CHAPTER 08
Subnetting in IPv6
128-bit addresses, the /64 standard, and why address exhaustion is mathematically impossible
IPv6 subnetting follows identical binary logic to IPv4 — the only difference is the address is 128 bits instead of 32. But this quantitative difference produces a qualitative change in how subnetting is practiced. IPv6 is so address-rich that conservation is unnecessary — the design philosophy shifts from "how do we fit these devices into this limited space" to "how do we allocate clearly and document well."
The Fixed /64 Boundary
The standard IPv6 LAN subnet is /64 — always. This is not arbitrary: SLAAC (Stateless Address Autoconfiguration, RFC 4862) requires a /64 prefix for its EUI-64-based address generation. When a host generates a SLAAC address, it takes the 64-bit network prefix from the Router Advertisement and appends a 64-bit Interface Identifier derived from the MAC address. This only works if the prefix is exactly /64. Breaking this convention (using /65 or /48 for LANs) requires DHCPv6 only — no SLAAC.
A /64 has 2^64 = 18.4 × 10^18 possible addresses per subnet. Every /64 assigned to a home or office LAN has more addresses than there are humans on Earth. IPv6 address conservation is a non-concept at the /64 level.
IPv6 Prefix Hierarchy
IPv6 allocation hierarchy
IANA → RIR: /12 to /23 blocks
RIR → ISP: typically /32 per ISP
ISP → Customer: typically /48 per site (residential may get /56 or /64)
Customer → LAN: /64 per subnet (SLAAC standard)
P2P links: /127 (RFC 6164 — same motivation as /31 in IPv4)
Loopbacks: /128 (equivalent of /32)
Example: Customer gets 2001:db8:abcd::/48
Available /64 subnets: 2^(64-48) = 2^16 = 65,536
First LAN: 2001:db8:abcd:0001::/64
Second LAN: 2001:db8:abcd:0002::/64
DMZ: 2001:db8:abcd:0010::/64
Management: 2001:db8:abcd:00ff::/64
...and 65,531 more available
EUI-64 Interface Identifier Generation
SLAAC uses the MAC address to generate the 64-bit interface identifier. Process: take the 48-bit MAC, insert FF:FE in the middle (making it 64 bits), then flip the 7th bit of the first byte (the Universal/Local bit). This is EUI-64.
EUI-64 generation
MAC address: 00:1A:2B:3C:4D:5E
1. Split: 00:1A:2B | 3C:4D:5E
2. Insert FF:FE in middle: 00:1A:2B:FF:FE:3C:4D:5E
3. Flip bit 7 of first byte:
00 = 00000000 → flip bit 7 → 00000010 = 02
4. Interface identifier: 02:1A:2B:FF:FE:3C:4D:5E
Formatted as IPv6: 021a:2bff:fe3c:4d5e
With network prefix 2001:db8:abcd:1::/64:
SLAAC address: 2001:db8:abcd:1:021a:2bff:fe3c:4d5e
∞ IPv6 Has More Addresses Than Atoms on Earth
IPv6 provides 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. That's 340 undecillion. For comparison, the estimated number of atoms on Earth is 1.33 × 10^50 — about 10^8 times fewer than IPv6 addresses. Every star in the observable universe could have a trillion networks, each with a trillion devices, and IPv6 would still have room. The /64 per LAN approach "wastes" 18 quintillion addresses per subnet intentionally — simplicity of SLAAC and future-proofing are worth more than address conservation at these scales.
// CHAPTER 09
Subnetting in Cloud and Container Environments
AWS VPC CIDR, Azure VNet, GCP, Kubernetes pod networks
AWS VPC Subnetting
An AWS VPC is assigned a CIDR block between /16 and /28. This VPC CIDR is then divided into subnets, each placed in a specific Availability Zone. AWS enforces a 5-address reservation in every subnet: .0 (network address), .1 (VPC router), .2 (DNS server), .3 (future AWS use), and the last address (broadcast). A /24 AWS subnet therefore has 256 − 5 = 251 usable addresses, not the traditional 254.
AWS subnet planning
VPC: 10.0.0.0/16 (65,536 total addresses)
AZ us-east-1a:
Public subnet: 10.0.0.0/24 (251 usable for EC2, ELB)
Private subnet: 10.0.1.0/24 (251 usable for app tier)
Data subnet: 10.0.2.0/24 (251 usable for RDS, ElastiCache)
AZ us-east-1b:
Public subnet: 10.0.10.0/24
Private subnet: 10.0.11.0/24
Data subnet: 10.0.12.0/24
AZ us-east-1c:
Public subnet: 10.0.20.0/24
Private subnet: 10.0.21.0/24
Data subnet: 10.0.22.0/24
Reserved for services:
VPC Endpoints: 10.0.100.0/24 (PrivateLink, Interface endpoints)
Transit Gateway: 10.0.200.0/28 (/28 minimum for TGW attachment subnets)
Lambda: 10.0.201.0/24 (Lambda VPC networking ENIs)
Remaining: 10.0.3.0 → 10.0.9.255 etc. — growth headroom
Kubernetes Pod and Service CIDR
Kubernetes uses three separate CIDR ranges: the node network (actual IP addresses of nodes in the VPC/datacenter), the pod CIDR (virtual IPs assigned to pods by the CNI plugin), and the service CIDR (virtual IPs for Kubernetes Services, not routable outside the cluster). These must not overlap with each other or with the node network.
Kubernetes network planning
# kubeadm init example
kubeadm init --pod-network-cidr=10.244.0.0/16 # Pod CIDR (flannel default)
--service-cidr=10.96.0.0/12 # Service CIDR (kube-proxy)
# Node network: 192.168.1.0/24 (actual machines, not pods)
# Per-node pod subnet (kubelet assigns each node a /24 from pod CIDR):
# Node 1: 10.244.0.0/24 — up to 254 pods
# Node 2: 10.244.1.0/24 — up to 254 pods
# Node 3: 10.244.2.0/24 — up to 254 pods
# /16 pod CIDR gives: 2^8 = 256 nodes × 254 pods = 65,024 total pods
# For larger clusters: use /14 (1024 nodes) or /12 (4096 nodes)
# Common mistake: pod CIDR overlaps with VPC CIDR
# If VPC is 10.0.0.0/8 and pod CIDR is 10.244.0.0/16 → OVERLAP → pods
# can't reach AWS services that use 10.x.x.x addresses
Docker Default Network
Docker creates a default bridge network at 172.17.0.0/16 on every installation. Containers on the bridge network get IPs from 172.17.0.0/16. If your enterprise uses 172.17.x.x for internal systems, Docker containers cannot reach those systems — same-subnet destination, Docker routes to the local bridge instead of through the host gateway. Fix: change Docker's default bridge network to a range not used by your infrastructure ("bip": "192.168.200.1/24" in /etc/docker/daemon.json).
// CHAPTER 10
Classless Routing Protocols and Subnet Masks in Updates
Why RIPv1 broke VLSM and how OSPF, EIGRP, BGP fixed it
Subnetting and VLSM only work if routing protocols carry subnet mask information in their routing updates. Classful protocols (RIPv1, IGRP — both obsolete) assume all subnets have the same prefix length as the class default. They don't include mask information in updates. Classless protocols (RIPv2, OSPF, EIGRP, IS-IS, BGP) include the subnet mask in every routing update — enabling VLSM.
Classful vs classless routing update behavior
Network: 10.0.0.0/8 subnetted with VLSM:
10.1.0.0/16 — Site A
10.2.0.0/24 — Server VLAN
10.3.0.0/30 — Router P2P link
RIPv1 (classful) update would send:
→ "10.0.0.0" (no mask) — receiver assumes /8 per Class A default
→ ALL subnets collapse to one entry: loses granularity, can't build
accurate routing table, breaks VLSM
OSPF (classless) LSA (Link State Advertisement) includes:
→ 10.1.0.0 255.255.0.0 (/16 preserved)
→ 10.2.0.0 255.255.255.0 (/24 preserved)
→ 10.3.0.0 255.255.255.252 (/30 preserved)
→ Each subnet is individually reachable
BGP NLRI (Network Layer Reachability Information):
prefix: 10.4.0.0/22 length: 22 ← explicit prefix length in every advertisementThis is why RIPv1 and IGRP are not just obsolete — they are actively incompatible with VLSM. Any network using variable-length subnets requires a classless routing protocol. All modern networks use OSPF, EIGRP, or BGP for dynamic routing. RIPv2 (classless) works for simple networks but scales poorly. OSPF is the dominant enterprise interior protocol; BGP handles all inter-domain (internet) routing.
// CHAPTER 11
Practical Subnetting: Enterprise Network Design
Real allocation decisions, growth planning, and point-to-point addressing
// REAL-WORLD SCENARIO
A medium enterprise has 8 office sites, a data center, and AWS cloud presence. The network architect receives 10.0.0.0/8 from the RFC 1918 pool. Day 1 decision: how to allocate this. Option A — just start assigning /24s as needed: within 2 years there are 47 disconnected /24s across multiple second-octet ranges, no summarization possible, routing table at HQ has 47 entries for internal subnets, adding a new site requires checking all existing allocations for conflicts. Option B — hierarchical design: each site gets a /16 (sites 1–8: 10.1–10.8), data center gets 10.100.0.0/16, cloud gets 10.200.0.0/16, each floor/VLAN gets /24 from its site's /16. Site routers advertise one /16 each. HQ routing table has 10 entries for internal networks. Option B takes one afternoon to plan. Option A fixes cost months.
Enterprise Hierarchical Address Plan
Enterprise address plan — hierarchical allocation
Organization: 10.0.0.0/8 (16.7M addresses)
│
├── Site 1 (HQ): 10.1.0.0/16 → advertises /16 to WAN
│ ├── VLAN 10 — Servers: 10.1.1.0/24 (static: .1–.50, DHCP: .100–.200)
│ ├── VLAN 20 — Users: 10.1.2.0/23 (DHCP pool: 510 hosts)
│ ├── VLAN 30 — VoIP: 10.1.4.0/24 (IP phones, DSCP EF)
│ ├── VLAN 40 — Guest: 10.1.5.0/24 (isolated, internet only)
│ ├── VLAN 50 — Mgmt: 10.1.6.0/27 (switches, APs, printers)
│ ├── VLAN 60 — DMZ: 10.1.7.0/28 (web servers, reverse proxies)
│ └── P2P links: 10.1.255.0/24 (carved into /31s: .0, .2, .4...)
│
├── Site 2 (Branch): 10.2.0.0/16 → advertises /16 to WAN
│ └── (same VLAN structure, different second octet)
│
├── Data Center: 10.100.0.0/16
│ ├── Production: 10.100.1.0/23
│ ├── Staging: 10.100.3.0/24
│ ├── Storage (iSCSI): 10.100.100.0/24
│ └── OOB management: 10.100.200.0/24
│
├── Cloud (AWS VPC): 10.200.0.0/16
│ └── (AZ subnets: 10.200.1.0/24, 10.200.2.0/24 per AZ)
│
└── Future expansion: 10.10.0.0/16 — 10.99.0.0/16 (reserved)
Point-to-Point Link Addressing Strategy
Every routed link between network devices requires addressing. Best practice is to carve these from a dedicated /24 block (e.g., 10.1.255.0/24) using /31 pairs. This keeps P2P link addresses separate from user/server ranges and simplifies ACLs (allow management access to 10.1.255.0/24 = allow access to all P2P link addresses at this site).
Growth Planning: Subnet Utilization Thresholds
Monitor subnet DHCP utilization. Common thresholds: alert at 70% (plan expansion), critical at 85% (expansion required), take action at 90%. When a DHCP scope is exhausted, no new devices can join the network without manual intervention. A /24 with 254 usable addresses that hits 90% means only ~25 addresses remain — a single team onboarding event can exhaust it.
Re-addressing a subnet is expensive: DHCP scope change, gateway IP change (if migrating to a larger network), update all static assignments, update DNS reverse records, update firewall rules and ACLs referencing the old prefix. The cost of proactively using /23 instead of /24 at deployment is nearly zero; the cost of re-addressing 500 hosts 18 months later is enormous.
// CHAPTER 12
Subnetting Tools and Automation
Python ipaddress module, ipcalc, and infrastructure-as-code subnet management
Python — The ipaddress Module
Python ipaddress module — full capabilities
import ipaddress
# Parse and analyze a network
net = ipaddress.IPv4Network('10.0.4.0/22', strict=True)
print(net.network_address) # 10.0.4.0
print(net.broadcast_address) # 10.0.7.255
print(net.netmask) # 255.255.252.0
print(net.num_addresses) # 1024
print(list(net.hosts())[0]) # 10.0.4.1 (first host)
print(list(net.hosts())[-1]) # 10.0.7.254 (last host)
# Check if an IP is in a network
ip = ipaddress.IPv4Address('10.0.5.100')
print(ip in net) # True
# Subnet a /22 into /24s
for subnet in net.subnets(new_prefix=24):
print(f"{subnet} — {subnet.num_addresses - 2} usable hosts")
# Supernet
a = ipaddress.IPv4Network('10.4.0.0/24')
b = ipaddress.IPv4Network('10.4.1.0/24')
c = ipaddress.IPv4Network('10.4.2.0/24')
d = ipaddress.IPv4Network('10.4.3.0/24')
summary = ipaddress.collapse_addresses([a, b, c, d])
print(list(summary)) # [IPv4Network('10.4.0.0/22')]
# Check overlap
x = ipaddress.IPv4Network('10.0.0.0/16')
y = ipaddress.IPv4Network('10.0.5.0/24')
print(x.overlaps(y)) # True (y is a subset of x)
# VLSM planning helper
def plan_vlsm(base: str, requirements: list[int]):
pool = ipaddress.IPv4Network(base)
available = list(pool.subnets(new_prefix=32))
idx = 0
for needed in sorted(requirements, reverse=True):
bits = (needed + 2 - 1).bit_length()
prefix = 32 - bits
# align to block size
block = 2 ** bits
start_num = (idx // block + (1 if idx % block else 0)) * block
subnet = ipaddress.IPv4Network(f"{available[start_num]}/{prefix}", strict=False)
print(f"/{prefix} for {needed} hosts: {subnet}")
idx = start_num + blockCLI Tools
CLI subnetting utilities
# Linux — ipcalc (human-readable breakdown)
ipcalc 192.168.10.0/26
# sipcalc — more detailed, supports VLSM planning
sipcalc -s 24 10.0.0.0/22 # shows all /24 subnets in a /22
# nmap network sweep (implicit subnet discovery)
nmap -sn 10.0.0.0/24 # ping sweep of /24
# Verify routing for specific destination
ip route get 10.5.100.50 # shows which subnet/interface handles this IP
# Show all subnets on a Linux host
ip addr show # all interfaces with prefix lengths
ip route show # all routes including connected subnets
// CHAPTER 13
Worked Practice Problems
Five complete problems from CIDR basics to VLSM design — with full solutions
Practice problem set — complete solutions
───────────────────────────────────────────────────────────────────
PROBLEM 1: Network identification
Host: 172.16.200.130, Mask: 255.255.255.192
Find: network, broadcast, first/last host, prefix
/26 → block size 64.
200 ÷ 64 = 3 remainder 8. Network = 3×64 = 192.
Network: 172.16.200.192/26
Broadcast: 172.16.200.255 (192 + 64 - 1)
First: 172.16.200.193
Last: 172.16.200.254
Usable: 62 hosts
───────────────────────────────────────────────────────────────────
PROBLEM 2: Cross-octet subnet
Host: 10.25.100.50, Prefix: /13
Find: network and broadcast addresses.
/13 → interesting octet: 2nd. Block in 2nd = 2^(16-13) = 8.
2nd octet = 25. 25 ÷ 8 = 3 rem 1. Network 2nd octet = 3×8 = 24.
Network: 10.24.0.0/13
Broadcast: 10.31.255.255 (3rd and 4th octets all-1s, 2nd = 24+8-1=31)
───────────────────────────────────────────────────────────────────
PROBLEM 3: Number of subnets
Network: 192.168.50.0/24 subnetted into /28.
How many subnets? How many total addresses? Hosts per subnet?
Bits borrowed = 28-24 = 4. Subnets = 2^4 = 16.
Block = 16. Hosts per subnet = 16-2 = 14.
Total addresses = 16×16 = 256 (= original /24 ✓)
───────────────────────────────────────────────────────────────────
PROBLEM 4: VLSM design
Given: 172.20.0.0/24
Requirements: LAN A: 100 hosts, LAN B: 50 hosts, LAN C: 25 hosts,
WAN link 1: 2 hosts, WAN link 2: 2 hosts.
LAN A: 100+2=102 → 2^7=128 → /25. Block 128. → 172.20.0.0/25
LAN B: 50+2=52 → 2^6=64 → /26. Block 64. → 172.20.0.128/26
LAN C: 25+2=27 → 2^5=32 → /27. Block 32. → 172.20.0.192/27
WAN 1: 2+2=4 → 2^2=4 → /30. Block 4. → 172.20.0.224/30
WAN 2: 2+2=4 → 2^2=4 → /30. Block 4. → 172.20.0.228/30
Remaining: 172.20.0.232 – 172.20.0.255 (24 addresses for future)
───────────────────────────────────────────────────────────────────
PROBLEM 5: Route summarization
Networks: 192.168.32.0/24, 192.168.33.0/24, 192.168.34.0/24, 192.168.35.0/24
Can they be summarized? If yes, what is the summary prefix?
3rd octet binary: 32=00100000, 33=00100001, 34=00100010, 35=00100011
Common bits: 001000xx — 6 common bits.
Summary prefix: 16 + 6 = /22. Summary: 192.168.32.0/22.
Verify: block = 1024. 32.0 → 35.255 = exactly 4×256=1024 addresses. ✓
All four /24s are contiguous and the block starts at /22-aligned boundary
(32 is a multiple of 4 in the 3rd octet for a /22). ✓
// CHAPTER 14
Common Misconceptions
Subnetting errors that appear in production and in interviews
✗ Common Mistake — A larger prefix number means a larger network
Prefix length and network size are inversely related. /24 is larger than /28. /16 is larger than /24. The prefix number counts network bits — more network bits means fewer host bits means a smaller subnet. When someone says "I need a bigger subnet," they mean a smaller prefix number (e.g., change /25 to /24 to double the host space). The confusion often comes from everyday language where "bigger number = more" — in subnetting it's the opposite for the prefix count.
✗ Common Mistake — Subnets can start at any convenient address
Subnet boundaries must be aligned to their block size. A /26 (block 64) must start at a multiple of 64: 0, 64, 128, or 192. A /27 (block 32) at multiples of 32. If you configure a subnet at a non-boundary address (e.g., 192.168.1.70/26), the router calculates the network address as 192.168.1.64 (ANDing .70 with the /26 mask) — your configured "network" address is wrong. This causes routing failures where the router silently forwards or drops packets based on the correctly-calculated subnet, not your intended one.
✗ Common Mistake — The network and broadcast addresses are wasted due to poor design
The reservation of network and broadcast addresses is intrinsic to the subnet model, not a design flaw. The network address identifies the subnet in routing entries. The broadcast address is used for subnet-wide Layer 2 broadcast delivery (ARP, DHCP, OSPF hello on broadcast networks). These serve real purposes. RFC 3021 /31s only eliminate them for point-to-point links specifically because P2P links have no use for broadcast — it's a special case opt-in, not evidence of a general waste.
✗ Common Mistake — VLSM requires special hardware or configuration
VLSM is purely a design and protocol concept. Any modern router and any classless routing protocol (OSPF, EIGRP, RIPv2, BGP) supports VLSM — these protocols include subnet mask information in routing updates. The router hardware doesn't need to know or care. Only classful protocols (RIPv1, IGRP — both obsolete since the early 2000s) are incompatible with VLSM. Every production network deployed today uses VLSM.
✗ Common Mistake — Discontinuous subnets can always be summarized if they share some bits
Summarization requires contiguous address space and an exact coverage boundary. 192.168.8.0/24 and 192.168.10.0/24 share bits but are not contiguous — 192.168.9.0/24 is the gap. A summary 192.168.8.0/22 would cover .8, .9, .10, .11 — but you don't own .9 and .11. Advertising that summary claims address space you don't control, potentially causing other organizations' traffic to be routed to you and dropped. Always verify that a candidate summary route covers exactly your address space and nothing more.
✗ Common Mistake — AWS /24 subnets give 254 usable hosts like normal subnets
AWS reserves 5 addresses per subnet (network, router, DNS, future, broadcast) compared to the standard 2 (network, broadcast). A /24 in AWS provides 256 − 5 = 251 usable addresses, not 254. For smaller subnets the impact is proportionally larger: a /28 (16 total, standard = 14 usable) becomes 16 − 5 = 11 usable in AWS. This matters when provisioning subnets for services that need a specific minimum host count. The AWS minimum subnet size is /28.
// CHAPTER 15
Interview Questions
What network engineering interviews actually test about subnetting
BeginnerHow many subnets and hosts per subnet does /27 create from a /24?
Bits borrowed = 27 − 24 = 3. Subnets = 2³ = 8. Host bits remaining = 32 − 27 = 5. Hosts per subnet = 2⁵ − 2 = 30. Block size = 32. Subnet mask = 255.255.255.224. Boundaries in 4th octet: 0, 32, 64, 96, 128, 160, 192, 224.
BeginnerA host has IP 192.168.50.130/26. What is its network address, broadcast, and usable range?
/26 → block 64. 130 ÷ 64 = 2, rem 2. Network = 2 × 64 = 128. Network address: 192.168.50.128/26. Broadcast: 192.168.50.128 + 64 − 1 = 192.168.50.191. First host: .129. Last host: .190. Usable hosts: 62.
IntermediateExplain VLSM and design a subnet scheme for: 100 hosts, 50 hosts, 25 hosts, and 2 point-to-point router links. Base network: 192.168.0.0/24.
VLSM uses different prefix lengths for different subnets to match actual host requirements. Allocate largest first: 100 hosts → /25 (126 usable), 50 hosts → /26 (62 usable), 25 hosts → /27 (30 usable), each P2P link → /30 (2 usable). Allocation: 192.168.0.0/25 (100-host LAN, .1–.126), 192.168.0.128/26 (50-host LAN, .129–.190), 192.168.0.192/27 (25-host LAN, .193–.222), 192.168.0.224/30 (link A, .225–.226), 192.168.0.228/30 (link B, .229–.230). Total: 128+64+32+4+4 = 232 of 256 addresses. Remaining: 192.168.0.232–.255 (24 addresses for future).
IntermediateHow do you find the summary route for 4 contiguous /24s: 10.4.0.0, 10.4.1.0, 10.4.2.0, 10.4.3.0?
Write the 3rd octet in binary: 0=00000000, 1=00000001, 2=00000010, 3=00000011. The last 2 bits differ; the first 6 bits (000000) agree. Total prefix = 16 + 6 = /22. Summary: 10.4.0.0/22. Verification: block size for /22 is 2^10 = 1024. Starting at 10.4.0.0, the /22 covers 10.4.0.0–10.4.3.255 = exactly the four /24s. The starting address (0 in the 3rd octet) is a multiple of 4, satisfying /22 boundary alignment.
SeniorDesign a multi-site enterprise address plan using 10.0.0.0/8 that enables route summarization at each layer. Support 16 sites, each with up to 16 buildings, each with up to 16 VLANs.
Three-level hierarchy: (1) Site level: allocate 16 sites from /8 using /12 blocks (2^(12-8) = 16 allocations). Site 1 = 10.0.0.0/12, Site 2 = 10.16.0.0/12 … Site 16 = 10.240.0.0/12. Each site router advertises one /12 to the WAN. (2) Building level: each site's /12 divided into /16 per building (2^(16-12) = 16 buildings per site). Site 1 Building 1 = 10.0.0.0/16, Building 2 = 10.1.0.0/16. Each building distribution switch advertises one /16 to the site router. (3) VLAN level: each /16 divided into /20 per VLAN cluster (2^(20-16) = 16 VLANs per building). 10.0.0.0/20 = VLAN cluster 1 (containing /24 subnets 10.0.0.0–10.0.15.255). Core routing sees at most 16 summary routes (one per site). Site sees at most 16 (one per building). Result: WAN routing table has 16 entries total for all internal traffic; adding a new VLAN anywhere adds zero entries to the WAN routing table.
PhDWhy does VLSM require classless routing protocols, and what breaks if you use RIPv1 with VLSM subnets?
Classless routing protocols include subnet mask information in every routing update (OSPF LSAs, EIGRP DUAL updates, BGP NLRI). This allows each subnet with a different prefix length to be advertised independently and correctly. RIPv1 (classful) omits mask information from updates — when a router receives "update for 10.1.0.0," it has no mask, so it assumes the Class A default (/8). All subnets of 10.0.0.0/8 collapse to one entry. The router believes all of 10.0.0.0/8 is reachable via this one update — but it cannot distinguish between 10.1.0.0/16, 10.2.0.0/24, and 10.3.0.0/30. Traffic destined for 10.3.0.1 routes to the right next-hop (10.0.0.0/8 matches), but once it arrives at the subnet edge, the router knows 10.3.0.0/30 (from its directly connected interface) but sent a classful /8 update outward — so remote routers have no specific route. Result: routing loops, unreachable subnets, or traffic blackholed at the wrong boundary. RIPv2 (1993) added mask fields to updates, enabling VLSM. OSPF has always been classless. This is why RIPv1 and IGRP were obsoleted — they are structurally incompatible with modern variable-length subnet design.
🎯 Key Takeaways
- ✓Subnetting borrows bits from the host portion: each borrowed bit doubles subnet count and halves host count. Block size = 2^(host bits) — all subnet boundaries are multiples of the block size.
- ✓Mental method: (1) find prefix from host count; (2) identify interesting octet; (3) block size in that octet = 2^(bits left); (4) network = (interesting octet ÷ block) × block.
- ✓The four-step method works for any prefix — /26 in 4th octet, /20 in 3rd octet, /12 in 2nd octet. The approach is identical; only the interesting octet changes.
- ✓VLSM allocates different prefix lengths to different subnets — always largest first to avoid alignment conflicts. Alignment rule: subnet start address must be divisible by block size.
- ✓Route summarization requires contiguous address space at an aligned boundary — discontinuous networks cannot be summarized without advertising address space you don't own.
- ✓/30 is the classical P2P link subnet (2 usable hosts); /31 (RFC 3021) eliminates network/broadcast for P2P, saving 2 addresses per link; /32 is a host route for loopbacks.
- ✓IPv6 uses fixed /64 per LAN (SLAAC requires it), /127 for P2P, /128 for loopbacks. A /48 allocation provides 65,536 /64 subnets — more than any organization will ever need.
- ✓AWS reserves 5 addresses per subnet (not 2), so a /24 gives 251 usable hosts. Kubernetes pod and service CIDRs must not overlap each other or the node/VPC network.
- ✓VLSM requires classless routing protocols (OSPF, EIGRP, RIPv2, BGP). RIPv1 and IGRP are classful — they omit subnet masks from updates and cannot distinguish VLSM subnets.
- ✓Hierarchical address planning enables route summarization: sites advertise /16 summaries to WAN, buildings advertise /20 to site — scaling to thousands of subnets with tens of routing table entries.