Loading learning content...
Throughout this module, we've built a comprehensive understanding of supernetting—from the foundational concept of address aggregation through contiguity requirements, calculation techniques, and efficiency benefits. Now it's time to apply this knowledge to realistic scenarios.\n\nThis page presents complete worked examples that mirror real-world networking challenges. You'll see supernetting applied to enterprise networks, service provider environments, and complex multi-site configurations. Each example walks through the complete analysis and solution, building your practical problem-solving skills.\n\nBy working through these examples, you'll develop the intuition needed to recognize supernetting opportunities and apply aggregation effectively in your own network designs.
By the end of this page, you will be able to: (1) Apply supernetting to enterprise campus networks with multiple sites, (2) Aggregate customer routes in service provider networks, (3) Handle complex scenarios with gaps and misalignments, (4) Make supernetting decisions in multihomed environments, and (5) Recognize common pitfalls and best practices. These practical skills translate directly to network design and operational work.
Scenario:\n\nAcme Corporation has a main campus with 4 buildings. Each building has multiple VLANs for different departments. The network was allocated 172.16.0.0/16 and assigned as follows:
ACME CORPORATION CAMPUS ADDRESS ALLOCATION═══════════════════════════════════════════════════════════════════════════════ Building A (Engineering): 172.16.0.0/24 - Engineering Workstations 172.16.1.0/24 - Engineering Labs 172.16.2.0/24 - Engineering Servers 172.16.3.0/24 - Engineering VoIP Building B (Sales & Marketing): 172.16.4.0/24 - Sales Workstations 172.16.5.0/24 - Marketing Workstations 172.16.6.0/24 - Sales VoIP 172.16.7.0/24 - Marketing VoIP Building C (Finance & HR): 172.16.8.0/24 - Finance Workstations 172.16.9.0/24 - HR Workstations 172.16.10.0/24 - Finance Servers 172.16.11.0/24 - HR Servers Building D (IT & Operations): 172.16.12.0/24 - IT Workstations 172.16.13.0/24 - Operations Center 172.16.14.0/24 - Datacenter Servers 172.16.15.0/24 - Network Management ═══════════════════════════════════════════════════════════════════════════════OBJECTIVE: Create appropriate route summarizations at each hierarchy levelSolution:\n\nWe'll create a hierarchical summarization strategy with aggregation at the building level and campus level.
HIERARCHICAL SUMMARIZATION SOLUTION═══════════════════════════════════════════════════════════════════════════════ STEP 1: Building-Level Summarization───────────────────────────────────────────────────────────────────────────── Building A: 172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24 • Count: 4 networks × 256 = 1,024 addresses • Third octets: 0, 1, 2, 3 (contiguous, starts at 0) • Alignment check: 0 ÷ 4 = 0 ✓ • SUMMARY: 172.16.0.0/22 Building B: 172.16.4.0/24, 172.16.5.0/24, 172.16.6.0/24, 172.16.7.0/24 • Count: 4 networks × 256 = 1,024 addresses • Third octets: 4, 5, 6, 7 (contiguous, starts at 4) • Alignment check: 4 ÷ 4 = 1 ✓ • SUMMARY: 172.16.4.0/22 Building C: 172.16.8.0/24, 172.16.9.0/24, 172.16.10.0/24, 172.16.11.0/24 • Count: 4 networks × 256 = 1,024 addresses • Third octets: 8, 9, 10, 11 (contiguous, starts at 8) • Alignment check: 8 ÷ 4 = 2 ✓ • SUMMARY: 172.16.8.0/22 Building D: 172.16.12.0/24, 172.16.13.0/24, 172.16.14.0/24, 172.16.15.0/24 • Count: 4 networks × 256 = 1,024 addresses • Third octets: 12, 13, 14, 15 (contiguous, starts at 12) • Alignment check: 12 ÷ 4 = 3 ✓ • SUMMARY: 172.16.12.0/22 ───────────────────────────────────────────────────────────────────────────── STEP 2: Campus-Level Summarization───────────────────────────────────────────────────────────────────────────── Building summaries: 172.16.0.0/22, 172.16.4.0/22, 172.16.8.0/22, 172.16.12.0/22 • Count: 4 × 1,024 = 4,096 addresses • Third octets covered: 0-3, 4-7, 8-11, 12-15 (contiguous, 0-15) • Alignment check: 0 ÷ 16 = 0 ✓ • SUMMARY: 172.16.0.0/20 ───────────────────────────────────────────────────────────────────────────── VERIFICATION: 172.16.0.0/20 range: First: 172.16.0.0 Last: 172.16.0.0 + 4,095 = 172.16.15.255 Original range: 172.16.0.0 through 172.16.15.255 ✓ Exact match ───────────────────────────────────────────────────────────────────────────── FINAL ROUTING CONFIGURATION: Each building router advertises its /22 to campus core Campus core advertises 172.16.0.0/20 to WAN/Internet edge WAN edge can further advertise 172.16.0.0/16 if more campus networks exist Result: 16 internal routes summarized to 1 external advertisementThis example demonstrates hierarchical summarization in action. Good address planning (allocating contiguous, aligned blocks to each building) made clean summarization possible at every level. If addresses had been allocated randomly, summarization would have been impossible or partial.
Scenario:\n\nRegionalNet ISP was allocated 203.0.113.0/24 for customer assignments. They've subdivided it among customers. Before advertising to upstream peers, they want to aggregate all customer routes into the minimum number of prefixes.
REGIONALNET ISP CUSTOMER ALLOCATIONS═══════════════════════════════════════════════════════════════════════════════ Customer Allocations (from 203.0.113.0/24): Customer A (Small business): 203.0.113.0/28 (16 addresses) Customer B (Small business): 203.0.113.16/28 (16 addresses) Customer C (Medium business): 203.0.113.32/27 (32 addresses) Customer D (Medium business): 203.0.113.64/26 (64 addresses) Customer E (Large enterprise): 203.0.113.128/25 (128 addresses) Total allocated: 16 + 16 + 32 + 64 + 128 = 256 addresses (/24 worth) ═══════════════════════════════════════════════════════════════════════════════OBJECTIVE: Determine minimum prefixes to advertise upstreamSolution:\n\nFirst, let's verify if these can be aggregated to a single prefix, then determine the optimal advertisement strategy.
ISP AGGREGATION ANALYSIS═══════════════════════════════════════════════════════════════════════════════ STEP 1: Map Address Ranges───────────────────────────────────────────────────────────────────────────── Customer A: 203.0.113.0/28 First: .0 Last: .15 (16 addresses)Customer B: 203.0.113.16/28 First: .16 Last: .31 (16 addresses)Customer C: 203.0.113.32/27 First: .32 Last: .63 (32 addresses)Customer D: 203.0.113.64/26 First: .64 Last: .127 (64 addresses)Customer E: 203.0.113.128/25 First: .128 Last: .255 (128 addresses) STEP 2: Check Contiguity───────────────────────────────────────────────────────────────────────────── .15 + 1 = .16 ✓ (A→B).31 + 1 = .32 ✓ (B→C).63 + 1 = .64 ✓ (C→D).127 + 1 = .128 ✓ (D→E).255 is the end of the /24 CONTIGUOUS ✓ (Full range .0 to .255 covered) STEP 3: Calculate Total Addresses───────────────────────────────────────────────────────────────────────────── 16 + 16 + 32 + 64 + 128 = 256 addresses = 2^8 ✓ (Power of two) STEP 4: Calculate Supernet Prefix───────────────────────────────────────────────────────────────────────────── Prefix = 32 - 8 = /24 STEP 5: Verify Alignment───────────────────────────────────────────────────────────────────────────── First address: 203.0.113.0For /24, fourth octet must be 0 ✓Third octet can be any value (full octet is the boundary) ALIGNED ✓ STEP 6: Construct Supernet───────────────────────────────────────────────────────────────────────────── RESULT: 203.0.113.0/24 ───────────────────────────────────────────────────────────────────────────── VERIFICATION: 203.0.113.0/24 covers .0 through .255 All customer allocations are within this range No unallocated addresses exist (all 256 are assigned) ═══════════════════════════════════════════════════════════════════════════════FINAL ANSWER: Advertise single prefix 203.0.113.0/24 upstream Internal routing maintains specific customer prefixes for forwardingExternal advertisement uses the single aggregate for simplicityISPs typically maintain detailed internal routing (each customer prefix) while advertising aggregates externally. The edge routers know which customer owns which specific prefix for internal forwarding, but upstream peers only see the aggregate. This is called 'filtering more-specifics at the edge.'
Scenario:\n\nMegaCorp was allocated 10.0.0.0/8 for internal use. Due to legacy decisions, their current allocations have gaps:
MEGACORP ADDRESS ALLOCATIONS (With Gaps)═══════════════════════════════════════════════════════════════════════════════ Used Allocations: 10.1.0.0/16 - US East Region 10.2.0.0/16 - US West Region (10.3.0.0/16 - UNALLOCATED - reserved for future) 10.4.0.0/16 - Europe Region 10.5.0.0/16 - Europe Region (expansion) 10.6.0.0/16 - Asia Pacific Region 10.7.0.0/16 - Asia Pacific Region (expansion) (10.8.0.0/16 - UNALLOCATED) (10.9.0.0/16 - UNALLOCATED) 10.10.0.0/16 - Data Centers 10.11.0.0/16 - Cloud Infrastructure ═══════════════════════════════════════════════════════════════════════════════OBJECTIVE: Determine minimum number of aggregates for external advertisementSolution:\n\nWith gaps in the address space, we cannot create a single aggregate. We must find the optimal set of aggregates.
AGGREGATION WITH GAPS ANALYSIS═══════════════════════════════════════════════════════════════════════════════ STEP 1: Identify Contiguous Segments───────────────────────────────────────────────────────────────────────────── Segment 1: 10.1.0.0/16, 10.2.0.0/16 Gap: 10.3.0.0/16 unallocated Segment 2: 10.4.0.0/16, 10.5.0.0/16, 10.6.0.0/16, 10.7.0.0/16 Gap: 10.8.0.0/16, 10.9.0.0/16 unallocated Segment 3: 10.10.0.0/16, 10.11.0.0/16 STEP 2: Aggregate Each Segment───────────────────────────────────────────────────────────────────────────── Segment 1: 10.1.0.0/16 and 10.2.0.0/16 • Count: 2 /16 networks = 2 × 65,536 = 131,072 addresses • Second octets: 1, 2 (contiguous) • Alignment check: For /15, second octet must be even 1 is ODD → NOT ALIGNED for /15 Cannot aggregate! Must advertise separately: → 10.1.0.0/16 → 10.2.0.0/16 Segment 2: 10.4.0.0/16, 10.5.0.0/16, 10.6.0.0/16, 10.7.0.0/16 • Count: 4 /16 networks = 4 × 65,536 = 262,144 addresses • Second octets: 4, 5, 6, 7 (contiguous) • Alignment check: For /14, second octet must be divisible by 4 4 ÷ 4 = 1 ✓ ALIGNED Can aggregate: → 10.4.0.0/14 Segment 3: 10.10.0.0/16 and 10.11.0.0/16 • Count: 2 /16 networks = 131,072 addresses • Second octets: 10, 11 (contiguous) • Alignment check: For /15, second octet must be even 10 is EVEN ✓ ALIGNED Can aggregate: → 10.10.0.0/15 ───────────────────────────────────────────────────────────────────────────── FINAL AGGREGATE LIST:───────────────────────────────────────────────────────────────────────────── 1. 10.1.0.0/16 (cannot aggregate, odd start) 2. 10.2.0.0/16 (cannot aggregate, would need 10.3.0.0 for /15) 3. 10.4.0.0/14 (aggregates 10.4-7.0.0/16) 4. 10.10.0.0/15 (aggregates 10.10-11.0.0/16) ═══════════════════════════════════════════════════════════════════════════════RESULT: 8 /16 networks → 4 advertisements (50% reduction) Note: If 10.3.0.0/16 were allocated later, 10.1-3.0.0 could become: - 10.1.0.0/16 (still separate, odd) - 10.2.0.0/15 (aggregates 10.2 and 10.3) If 10.0.0.0/16 were allocated: - 10.0.0.0/15 could aggregate 10.0 and 10.1MegaCorp's allocation at 10.1.0.0 instead of 10.0.0.0 prevents clean aggregation with future allocations. Starting at an odd second octet means the first block can never pair down. Planning would have reserved 10.0.0.0/16 initially, even if unused, to maintain aggregation options.
Scenario:\n\nTechStart Inc. is a growing company with provider-allocated address space from their primary ISP. They want to add a second ISP for redundancy. Their current allocation is 198.51.100.0/24 from ISP-A.
MULTIHOMING SCENARIO ANALYSIS═══════════════════════════════════════════════════════════════════════════════ Current Setup: - TechStart uses 198.51.100.0/24 (allocated from ISP-A's block) - ISP-A owns 198.51.0.0/16 - ISP-A advertises 198.51.0.0/16 to the Internet (aggregated) Desire: Add ISP-B for redundancy - TechStart wants traffic to failover to ISP-B if ISP-A fails ═══════════════════════════════════════════════════════════════════════════════THE AGGREGATION PROBLEM: ISP-A advertises 198.51.0.0/16 (covers 198.51.100.0/24)If ISP-B advertises 198.51.100.0/24, two routes exist: - 198.51.0.0/16 via ISP-A - 198.51.100.0/24 via ISP-B Longest-prefix match: /24 is more specific than /16Result: ALL traffic goes to ISP-B (not just failover!) If ISP-B only advertises when ISP-A fails: This works BUT requires active coordination BGP doesn't natively support "only if other path fails" ═══════════════════════════════════════════════════════════════════════════════Solution Options:
MULTIHOMING SOLUTIONS═══════════════════════════════════════════════════════════════════════════════ OPTION 1: Provider-Independent (PI) Address Space───────────────────────────────────────────────────────────────────────────── TechStart obtains their own /24 directly from Regional Internet RegistryExample: 192.0.2.0/24 (PI space, not from any ISP) Configuration: - Advertise 192.0.2.0/24 via BOTH ISP-A and ISP-B - Use BGP attributes (AS-path prepending, MED) for traffic engineering - Both ISPs accept and propagate the route Aggregation impact: - 192.0.2.0/24 appears as separate route in global table - Cannot aggregate with either ISP's block - Adds 1 route to global Internet routing table Pros: Clean multihoming, TechStart controls routing policyCons: Costs money (RIR membership), adds to global table ───────────────────────────────────────────────────────────────────────────── OPTION 2: More-Specific Deaggregation (Traffic Engineering)───────────────────────────────────────────────────────────────────────────── Keep 198.51.100.0/24 but advertise MORE-SPECIFIC prefixes: Via ISP-A: 198.51.100.0/25 (preferred for first half) Via ISP-B: 198.51.100.128/25 (preferred for second half) Both ISPs also advertise the /24 as backup: Via ISP-A: 198.51.100.0/24 (backup if /25 fails) Via ISP-B: 198.51.100.0/24 (backup if /25 fails) Result: Each half of addresses prefers one ISP If either ISP fails, the other's /24 covers everything Aggregation impact: - 2 more routes in global table (/25s) - /24 still aggregates within ISP-A's /16 when healthy Pros: Works with PA space, load-balances between ISPsCons: Adds routes to global table, some ISPs filter /25s ───────────────────────────────────────────────────────────────────────────── OPTION 3: Conditional Advertisement (Active/Passive)───────────────────────────────────────────────────────────────────────────── ISP-A advertises 198.51.100.0/24 normally (aggregates to /16)ISP-B only advertises if ISP-A link is detected down Implementation: - Monitor ISP-A link status - Script to announce/withdraw via ISP-B based on status - Or use BGP conditional advertisement Aggregation impact: - No additional routes during normal operation - 1 new route only during failover Pros: No global table impact during normal operationCons: Complex, slower failover, single points of failure ═══════════════════════════════════════════════════════════════════════════════RECOMMENDATION FOR TECHSTART: If budget allows: Option 1 (PI space) - cleanest solutionIf budget constrained: Option 2 with /25 deaggregationAvoid Option 3 for critical applications (too fragile)Multihoming inherently conflicts with aggregation. Aggregation wants to minimize routes; multihoming requires multiple paths to the same destination. Networks must choose: use PI space (clean multihoming, no aggregation benefit), use PA space with deaggregation (partial aggregation, routing table impact), or accept single-homed limitations (full aggregation, no redundancy).
Scenario:\n\nCloudProvider Inc. is designing a new data center and wants to plan address allocation for optimal aggregation. They've been allocated 10.128.0.0/10 (4 million addresses) and need to support:
CLOUDPROVIDER DATA CENTER REQUIREMENTS═══════════════════════════════════════════════════════════════════════════════ Allocation: 10.128.0.0/10 (10.128.0.0 - 10.191.255.255) Requirements: - 4 Availability Zones (AZs) - Each AZ needs: - Up to 256 customer VPCs - Each VPC: up to 256 subnets - Each subnet: up to 256 addresses - Management networks per AZ - Backbone/interconnect networks - Growth capacity for 2 more AZs ═══════════════════════════════════════════════════════════════════════════════Solution:\n\nWe'll design a hierarchical addressing scheme where each level aggregates cleanly to the next.
HIERARCHICAL ADDRESS PLAN═══════════════════════════════════════════════════════════════════════════════ LEVEL 1: Data Center Block───────────────────────────────────────────────────────────────────────────── Total space: 10.128.0.0/10 Addresses: 4,194,304 (2^22) LEVEL 2: Availability Zone Allocation (/12 per AZ = 1M addresses each)───────────────────────────────────────────────────────────────────────────── AZ-1: 10.128.0.0/12 (10.128.0.0 - 10.143.255.255) AZ-2: 10.144.0.0/12 (10.144.0.0 - 10.159.255.255) AZ-3: 10.160.0.0/12 (10.160.0.0 - 10.175.255.255) AZ-4: 10.176.0.0/12 (10.176.0.0 - 10.191.255.255) Aggregation: Each AZ advertises single /12 to DC backbone Future AZs: Would require additional /10 allocation LEVEL 3: Zone Subdivision within each AZ (/14 blocks)───────────────────────────────────────────────────────────────────────────── Per AZ breakdown (using AZ-1 as example): Customer VPCs: 10.128.0.0/14 (262,144 addresses for customers) Management: 10.132.0.0/14 (262,144 addresses for mgmt) Backbone: 10.136.0.0/14 (262,144 addresses for interconnect) Reserved: 10.140.0.0/14 (262,144 addresses for growth) LEVEL 4: VPC Allocation within Customer Space (/22 per VPC = 1K addresses)───────────────────────────────────────────────────────────────────────────── 10.128.0.0/14 contains 256 /22 blocks: VPC-001: 10.128.0.0/22 VPC-002: 10.128.4.0/22 VPC-003: 10.128.8.0/22 ... VPC-256: 10.131.252.0/22 Each VPC can be subnetted into up to 4 /24s or 8 /25s, etc. LEVEL 5: Subnet within VPC (/24 or smaller)───────────────────────────────────────────────────────────────────────────── VPC-001 (10.128.0.0/22) example subnets: Web tier: 10.128.0.0/24 App tier: 10.128.1.0/24 Database tier: 10.128.2.0/24 Reserved: 10.128.3.0/24 ═══════════════════════════════════════════════════════════════════════════════ AGGREGATION SUMMARY:───────────────────────────────────────────────────────────────────────────── Subnets → VPC: 4 /24s aggregate to 1 /22 VPCs → Zone: 64 /22s aggregate to 1 /14 Zones → AZ: 4 /14s aggregate to 1 /12 AZs → DC: 4 /12s aggregate to 1 /10 Reduction at each level: 4:1 typically Overall: ~256 subnets per VPC × 256 VPCs × 4 AZs = 262,144 routes Aggregated to 1 route (10.128.0.0/10) at DC edge ═══════════════════════════════════════════════════════════════════════════════ ROUTING IMPLEMENTATION:───────────────────────────────────────────────────────────────────────────── • Leaf switches know specific /24 subnets (local VPC routes) • Spine switches aggregate to /22 (VPC level) • AZ routers aggregate to /12 (AZ level) • DC border routers advertise /10 externally Traffic engineering within DC uses specific routes External traffic uses aggregates onlyNotice how every allocation level uses power-of-two sizing at aligned boundaries. This isn't coincidence—it's deliberate design that makes aggregation mathematically clean at every hierarchy level. A well-planned address architecture pays dividends for the entire lifetime of the infrastructure.
Test your supernetting skills with these exam-style problems. Try solving each before checking the solution.
Problem:\nWhat single supernet can summarize these networks?\n- 172.20.32.0/24\n- 172.20.33.0/24\n- 172.20.34.0/24\n- 172.20.35.0/24\n- 172.20.36.0/24\n- 172.20.37.0/24\n- 172.20.38.0/24\n- 172.20.39.0/24
Answer: 172.20.32.0/21\n\nAnalysis:\n- 8 /24 networks = 2,048 addresses = /21\n- Third octets: 32, 33, 34, 35, 36, 37, 38, 39 (contiguous)\n- Alignment: 32 ÷ 8 = 4 (whole number) ✓\n- Result: 172.20.32.0/21 covers 172.20.32.0 through 172.20.39.255
For supernetting problems: (1) Always check contiguity first—gaps mean multiple aggregates. (2) Count total addresses and verify power of two. (3) Check alignment using the divisibility rule. (4) When in doubt, draw the binary representation. These steps will handle any supernetting question.
We've completed our comprehensive exploration of supernetting—from foundational concepts through practical application. Let's consolidate everything we've learned across this module:
| Concept | Formula/Rule |
|---|---|
| Aggregate prefix length | 32 - log₂(total addresses) |
| Alignment check | (first address) mod (block size) = 0 |
| /24 aggregation | 2^n /24s → /(24-n) prefix |
| Third octet divisor | Must divide by number of /24s being aggregated |
| Address count | 2^(32 - prefix_length) |
| Last address | First address + address count - 1 |
Key Principles to Remember:\n\n1. Plan for aggregation from the start — It's far easier to allocate aggregatable addresses initially than to reorganize later.\n\n2. Every route has a cost — Memory, CPU, convergence time, stability. Minimize routes through aggregation.\n\n3. Hierarchical design enables hierarchical aggregation — Structure your network so each level naturally summarizes to the next.\n\n4. Never aggregate what you don't own — Including addresses in an aggregate that you don't control is route hijacking.\n\n5. Multihoming conflicts with aggregation — Understand the trade-offs and choose consciously.
Congratulations! You've mastered supernetting—a fundamental skill for network engineers. You can now aggregate routes to reduce routing table size, plan address allocations for optimal aggregation, calculate supernets quickly and accurately, and understand the efficiency benefits. This knowledge applies directly to network design, BGP configuration, and addressing architecture decisions.