101
0/228
Loading content...
In the previous page, we learned that address aggregation combines multiple networks into a single summarized prefix. But there's a critical constraint we touched on briefly: the networks must be contiguous—numerically adjacent with no gaps in the address space.\n\nThis isn't an arbitrary limitation; it's a fundamental mathematical requirement. A single prefix can only describe a contiguous range of addresses. If you try to aggregate networks with gaps, you'll either include addresses that don't belong to you (potentially hijacking someone else's traffic) or fail to cover all your addresses.\n\nUnderstanding contiguity is essential for effective supernetting. In this page, we'll explore what makes networks contiguous, how to identify valid aggregation candidates, and why alignment matters as much as adjacency.
By the end of this page, you will understand: (1) The precise definition of network contiguity and why gaps prevent aggregation, (2) How to identify whether a set of networks is contiguous and aggregatable, (3) The concept of alignment boundaries and why aggregation must start at specific addresses, (4) Common scenarios that break contiguity and how to work around them. This knowledge is essential for performing supernetting calculations correctly.
Contiguity means that networks are numerically adjacent in the IP address space with no gaps between them. When network A ends at address X, network B must start at address X+1 for them to be contiguous.\n\nFormal Definition:\n\nTwo networks N₁ and N₂ are contiguous if and only if:\n- The last address of N₁ + 1 equals the first address of N₂, OR\n- The last address of N₂ + 1 equals the first address of N₁\n\nFor a set of networks to be aggregatable to a single prefix, all networks in the set must be contiguous to each other, forming a complete, unbroken range.
Why Gaps Prevent Aggregation:\n\nConsider what happens if we try to aggregate non-contiguous networks. If we advertise 192.168.0.0/22 to cover 192.168.0.0/24, 192.168.2.0/24, and 192.168.3.0/24 (skipping .1.0/24):\n\n- The /22 covers 192.168.0.0 through 192.168.3.255\n- This includes 192.168.1.0 through 192.168.1.255\n- If someone else owns .1.0/24, we've just announced their addresses as part of our routes\n- Their traffic gets sent to us instead of them — route hijacking\n\nAlternatively, if .1.0/24 is simply unallocated, advertising the /22 claims addresses we're not authorized to use.
Aggregating non-contiguous networks is not just a configuration error—it can inadvertently hijack traffic destined for networks you don't own. This has caused real Internet outages when organizations misconfigure aggregated route advertisements. BGP has no built-in authentication to prevent this; operational care and Resource Public Key Infrastructure (RPKI) are the defenses.
Given a set of network addresses, how do we determine if they form a contiguous block suitable for aggregation? Let's develop a systematic process.\n\nStep 1: List All Networks and Their Address Ranges\n\nFor each network, calculate:\n- First address (network address)\n- Last address (broadcast address)\n- Total number of addresses\n\nStep 2: Sort by Network Address\n\nArrange networks in ascending numerical order based on their first address.\n\nStep 3: Check for Gaps\n\nFor each adjacent pair of networks, verify that the last address of network N plus one equals the first address of network N+1.
Example: Checking Contiguity═══════════════════════════════════════════════════════════════════════════════ Given Networks (unsorted): - 10.20.16.0/24 - 10.20.18.0/24 - 10.20.17.0/24 - 10.20.19.0/24 Step 1: Calculate Address Ranges─────────────────────────────────────────────────────────────────────────────Network First Address Last Address # of Addresses10.20.16.0/24 10.20.16.0 10.20.16.255 25610.20.17.0/24 10.20.17.0 10.20.17.255 25610.20.18.0/24 10.20.18.0 10.20.18.255 25610.20.19.0/24 10.20.19.0 10.20.19.255 256 Step 2: Sort by First Address─────────────────────────────────────────────────────────────────────────────1. 10.20.16.0/242. 10.20.17.0/243. 10.20.18.0/244. 10.20.19.0/24 Step 3: Gap Analysis─────────────────────────────────────────────────────────────────────────────• 10.20.16.255 + 1 = 10.20.17.0 ✓ Matches next network's first address• 10.20.17.255 + 1 = 10.20.18.0 ✓ Matches next network's first address• 10.20.18.255 + 1 = 10.20.19.0 ✓ Matches next network's first address Result: ✓ CONTIGUOUS — All networks form an unbroken range Total range: 10.20.16.0 through 10.20.19.255 (1,024 addresses)Handling Mixed Prefix Lengths:\n\nContiguity checking works the same way with mixed prefix lengths—you're simply looking at address ranges, not prefix lengths.
Example: Mixed Prefix Lengths═══════════════════════════════════════════════════════════════════════════════ Given Networks: - 172.16.0.0/25 (128 addresses: .0.0 to .0.127) - 172.16.0.128/25 (128 addresses: .0.128 to .0.255) - 172.16.1.0/24 (256 addresses: .1.0 to .1.255) Sorted Address Ranges:─────────────────────────────────────────────────────────────────────────────Network First Address Last Address Size172.16.0.0/25 172.16.0.0 172.16.0.127 128172.16.0.128/25 172.16.0.128 172.16.0.255 128172.16.1.0/24 172.16.1.0 172.16.1.255 256 Gap Analysis:─────────────────────────────────────────────────────────────────────────────• 172.16.0.127 + 1 = 172.16.0.128 ✓ Matches next range• 172.16.0.255 + 1 = 172.16.1.0 ✓ Matches next range Result: ✓ CONTIGUOUS — Total range: 172.16.0.0 to 172.16.1.255 (512 addresses) Note: Two /25s + one /24 = 128 + 128 + 256 = 512 addresses 512 = 2^9, so aggregate could be /23For networks of equal prefix length (e.g., all /24s), contiguity checking is simpler: convert the third octet (for /24s) to numbers and verify they form a consecutive sequence. For 10.20.16.0/24 through 10.20.19.0/24, the sequence 16, 17, 18, 19 is consecutive—contiguous!
Contiguity alone is not sufficient for aggregation. The aggregate block must also start at a valid alignment boundary. This is where many supernetting attempts fail.\n\nThe Alignment Rule:\n\nAn aggregate of N networks (where N is a power of 2) can only start at addresses that are multiples of N × (size of each network).\n\nExample: Aggregating Four /24 Networks\n\nEach /24 has 256 addresses. Four /24s = 1,024 addresses.\n- 1,024 = 2¹⁰, so the aggregate is a /22\n- The aggregate must start at an address that's a multiple of 1,024\n\nValid /22 starting addresses (in the third octet):\n- 0, 4, 8, 12, 16, 20, 24, 28, 32... (multiples of 4)
Why Alignment Matters (Binary Explanation):\n\nLet's examine why 192.168.1.0 through 192.168.4.0 cannot aggregate to a /22, even though they're contiguous.
Alignment Analysis in Binary═══════════════════════════════════════════════════════════════════════════════ Misaligned Block: 192.168.1.0/24 through 192.168.4.0/24 Third Octet Binary Values: 1 = 00000001 2 = 00000010 3 = 00000011 4 = 00000100 Looking at the last 2 bits (what a /22 would hide): 1 = 000000|01| ← last 2 bits = 01 2 = 000000|10| ← last 2 bits = 10 3 = 000000|11| ← last 2 bits = 11 4 = 000001|00| ← last 2 bits = 00 (but prefix changed!) Notice: The first 6 bits are NOT identical! - Networks 1, 2, 3 have prefix 000000 - Network 4 has prefix 000001 A /22 prefix encompasses addresses where the first 22 bits match.These networks span TWO different /22 blocks: - 192.168.0.0/22 (covers .0, .1, .2, .3) - 192.168.4.0/22 (covers .4, .5, .6, .7) ═══════════════════════════════════════════════════════════════════════════════ Aligned Block: 192.168.0.0/24 through 192.168.3.0/24 Third Octet Binary Values: 0 = 00000000 1 = 00000001 2 = 00000010 3 = 00000011 Looking at the last 2 bits: 0 = 000000|00| 1 = 000000|01| 2 = 000000|10| 3 = 000000|11| The first 6 bits ARE identical (000000) — this is the /22 network portion!All four combinations of the last 2 bits are covered (00, 01, 10, 11). Result: 192.168.0.0/22 is a valid aggregate.For aggregating 2^k networks of size 2^n addresses each: the starting network address (the portion that varies) must be divisible by 2^k. Example: To aggregate 8 /24 networks (2³ networks of 2⁸ addresses), the third octet must be divisible by 8 (0, 8, 16, 24...). The result is a /(24-3) = /21.
Given a set of networks, determining if they can aggregate requires checking both contiguity AND alignment. Here's a systematic approach.\n\nMethod: Find the Natural Aggregate Boundary\n\n1. Calculate the total address count\n2. Verify it's a power of 2 (if not, aggregation to a single prefix is impossible)\n3. Determine the aggregate prefix length\n4. Check if the first network address is aligned to that prefix length
Aggregate Boundary Calculation Algorithm═══════════════════════════════════════════════════════════════════════════════ Input: Set of networks to aggregate Step 1: Verify Contiguity───────────────────────────────────────────────────────────────────────────── Sort networks by first address For each adjacent pair, verify no gap exists If gaps found → Cannot aggregate to single prefix Step 2: Calculate Total Addresses───────────────────────────────────────────────────────────────────────────── Sum the size of all networks Example: Four /24s = 4 × 256 = 1,024 addresses Step 3: Verify Power of Two───────────────────────────────────────────────────────────────────────────── Is total a power of 2? (Check: total & (total - 1) == 0) If not power of 2 → Cannot aggregate to single prefix 1,024 = 2^10 ✓ Step 4: Calculate Aggregate Prefix Length───────────────────────────────────────────────────────────────────────────── Aggregate prefix = 32 - log₂(total addresses) Example: 32 - log₂(1024) = 32 - 10 = /22 Step 5: Verify Alignment───────────────────────────────────────────────────────────────────────────── The first address's network portion must be aligned For /22: The first 22 bits must have trailing zeros in the "hidden" positions Alternative check: (first_address) mod (total_addresses) == 0 Example: 192.168.0.0 mod 1024 = ? 192.168.0.0 = 192×256³ + 168×256² + 0×256 + 0 = 3,232,235,520 3,232,235,520 mod 1024 = 0 ✓ (Aligned!) Step 6: Construct Aggregate───────────────────────────────────────────────────────────────────────────── Aggregate = first_address / aggregate_prefix_length Example: 192.168.0.0/22Practical Alignment Shortcut for /24 Networks:\n\nWhen aggregating /24 networks, alignment checking can be done by examining the third octet:
of /24s | Aggregate Prefix | Third Octet Must Be Divisible By | Valid Starting Values |
|---|---|---|---|
| 2 | /23 | 2 | 0, 2, 4, 6, 8, 10, 12, ... |
| 4 | /22 | 4 | 0, 4, 8, 12, 16, 20, 24, ... |
| 8 | /21 | 8 | 0, 8, 16, 24, 32, 40, 48, ... |
| 16 | /20 | 16 | 0, 16, 32, 48, 64, 80, 96, ... |
| 32 | /19 | 32 | 0, 32, 64, 96, 128, 160, ... |
| 64 | /18 | 64 | 0, 64, 128, 192 |
| 128 | /17 | 128 | 0, 128 |
| 256 | /16 | 256 | 0 only (new second octet) |
To quickly check alignment: divide the third octet by the number of /24 networks being aggregated. If the result is a whole number, the block is aligned. Example: Can 192.168.12.0/24 start a block of 4 /24s? 12 ÷ 4 = 3.0 ✓ (whole number, aligned). Can 192.168.13.0/24? 13 ÷ 4 = 3.25 ✗ (not aligned).
What happens when a set of networks is contiguous but not aligned for a single aggregate? Or when networks are mostly contiguous with small gaps? These real-world scenarios require partial aggregation strategies.\n\nScenario 1: Contiguous but Misaligned\n\nNetworks: 192.168.1.0/24 through 192.168.4.0/24 (4 contiguous /24s)\n\nThese cannot aggregate to a single /22 (misaligned). But we can partially aggregate:
Partial Aggregation: Misaligned Block═══════════════════════════════════════════════════════════════════════════════ Original: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24 Analysis: - 192.168.1.0/24: 1 is odd, cannot pair downward - 192.168.2.0/24: 2 is even, CAN pair with .3.0 → 192.168.2.0/23 - 192.168.3.0/24: pairs with .2.0 - 192.168.4.0/24: 4 is even, can start a new pair (but alone here) Best Aggregation:───────────────────────────────────────────────────────────────────────────── 192.168.1.0/24 ← Advertise individually (cannot pair) 192.168.2.0/23 ← Aggregate of .2.0 and .3.0 192.168.4.0/24 ← Advertise individually (no pair partner) Result: 4 networks → 3 route advertisements (25% reduction) Alternative (if we had .5.0): 192.168.1.0/24 ← Individual 192.168.2.0/23 ← .2.0 + .3.0 192.168.4.0/23 ← .4.0 + .5.0 Result: 5 networks → 3 route advertisements (40% reduction)Scenario 2: Gap in the Middle\n\nNetworks: 192.168.0.0/24, 192.168.1.0/24, 192.168.3.0/24, 192.168.4.0/24, 192.168.5.0/24, 192.168.6.0/24, 192.168.7.0/24\n\nNote: 192.168.2.0/24 is missing (gap).
Partial Aggregation: Gap in Block═══════════════════════════════════════════════════════════════════════════════ Original Networks: 192.168.0.0/24 ─┐ 192.168.1.0/24 ─┘ ← First contiguous segment [192.168.2.0/24 is MISSING - gap] 192.168.3.0/24 ─┐ 192.168.4.0/24 │ 192.168.5.0/24 │ ← Second contiguous segment 192.168.6.0/24 │ 192.168.7.0/24 ─┘ Aggregation Strategy:─────────────────────────────────────────────────────────────────────────────Segment 1 (before gap): 192.168.0.0/24 + 192.168.1.0/24 → 192.168.0.0/23 ✓ (aligned at 0) Segment 2 (after gap): Third octets: 3, 4, 5, 6, 7 (five /24s - not power of 2!) Must break into aggregatable pieces: - 192.168.3.0/24: 3 is odd, must be individual - 192.168.4.0/24 + .5.0 + .6.0 + .7.0: starts at 4 (divisible by 4) → /22? No! Only 4 networks but starts at 4, ends at 7. Perfect! 192.168.4.0/22 ✓ Final Route Advertisements:───────────────────────────────────────────────────────────────────────────── 192.168.0.0/23 ← Covers .0.0 and .1.0 192.168.3.0/24 ← Individual (odd, no pair) 192.168.4.0/22 ← Covers .4.0, .5.0, .6.0, .7.0 Result: 7 networks → 3 route advertisements (57% reduction)Finding the minimum number of prefixes to cover a given set of networks is computationally complex. However, for typical network sizes, greedy algorithms work well: always try to aggregate the largest aligned power-of-two block possible, then handle remainders. In practice, network operators plan address allocations to avoid this problem entirely.
The best way to ensure aggregation works is to plan address assignments from the start. Organizations that allocate addresses without considering aggregation often find themselves unable to summarize routes later—locked into inefficient routing configurations.\n\nAggregation-Friendly Address Planning Principles:
Example: Enterprise Address Plan with Aggregation
Enterprise Address Plan (Aggregation-Friendly)═══════════════════════════════════════════════════════════════════════════════ Enterprise Allocation: 172.20.0.0/16 (65,536 addresses) Hierarchical Breakdown:───────────────────────────────────────────────────────────────────────────── Level 1: Regional Allocation (/18 blocks = 16,384 addresses each)───────────────────────────────────────────────────────────────────────────── North America: 172.20.0.0/18 (172.20.0.0 - 172.20.63.255) Europe: 172.20.64.0/18 (172.20.64.0 - 172.20.127.255) Asia Pacific: 172.20.128.0/18 (172.20.128.0 - 172.20.191.255) Reserved: 172.20.192.0/18 (For future regions) Level 2: Site Allocation within North America (/20 = 4,096 addresses each)───────────────────────────────────────────────────────────────────────────── NYC HQ: 172.20.0.0/20 (172.20.0.0 - 172.20.15.255) Chicago DC: 172.20.16.0/20 (172.20.16.0 - 172.20.31.255) Dallas Office: 172.20.32.0/20 (172.20.32.0 - 172.20.47.255) LA Office: 172.20.48.0/20 (172.20.48.0 - 172.20.63.255) Level 3: Department within NYC HQ (/24 = 256 addresses each)───────────────────────────────────────────────────────────────────────────── Engineering: 172.20.0.0/24 Sales: 172.20.1.0/24 Marketing: 172.20.2.0/24 HR: 172.20.3.0/24 Finance: 172.20.4.0/24 ... (reserved through 172.20.15.0/24) ═══════════════════════════════════════════════════════════════════════════════Aggregation at Each Level: • NYC HQ router advertises 172.20.0.0/20 to regional backbone • Regional backbone advertises 172.20.0.0/18 to WAN • WAN advertises 172.20.0.0/16 to Internet Result: Regardless of internal complexity, only ONE route (172.20.0.0/16) appears in the global Internet routing tableGood address planning is a one-time investment that pays dividends for the lifetime of the network. Retrofitting aggregation into a poorly planned address space often requires renumbering—a disruptive, expensive undertaking. Invest the time upfront to plan aggregatable address assignments.
We've thoroughly examined the contiguity requirement for supernetting—the critical constraint that networks must be numerically adjacent and properly aligned for aggregation to work. Let's consolidate the key takeaways:
What's Next:\n\nNow that we understand what makes networks aggregatable, the next page covers supernet calculation—the step-by-step mathematical process for determining the aggregate prefix from a given set of networks. We'll work through detailed calculations and develop techniques for rapid supernet computation.
You now understand the contiguity and alignment requirements for network aggregation. These constraints aren't arbitrary—they're fundamental to how IP prefixes work. With this knowledge, you can evaluate whether a set of networks can aggregate and identify the barriers when they can't. Next, we'll put this understanding into practice with supernet calculations.