Summarizable Address Plan for a Four-Site Distributor
NovaFreight is a regional distributor with four sites: headquarters (380 endpoints today), a northern depot (140), a southern depot (90), and a small DR suite (60). Everything sits inside a single 10.20.0.0/16 block carried by one OSPF area, and the recently acquired southern depot still uses 192.168.50.0/24 for its label printers because nobody has renumbered them. Endpoint growth is forecast at 30% over three years, and the CIO wants a design the team can summarize at each site boundary so that a flapping access link never floods the whole domain with topology changes. There are 14 WAN links today and space for 40. One constraint: server VLAN 10.20.10.0/24 hosts two label-printing appliances with hard-coded addresses that cannot change before the next fiscal year. NovaFreight employs two senior network engineers and has no dedicated design group; every added protocol is an operational cost they will carry personally.
1. Produce an address allocation that lets each site be advertised as a single summary route and still accommodates 40 point-to-point WAN links. Show the arithmetic, and explain how you handle 192.168.50.0/24.
Read the worked answer
Carve four /19s out of 10.20.0.0/16, one per site: HQ 10.20.0.0/19, north depot 10.20.32.0/19, south depot 10.20.64.0/19, DR 10.20.96.0/19. Those consume 10.20.0.0–10.20.127.255 and leave 10.20.128.0/17 untouched. Sanity-check growth: HQ 380 × 1.3 ≈ 494, which fits a /23 with only 16 addresses spare, so give HQ a /22 or better inside its /19; depots need at most a /24 each. The trick with the hard-coded appliance VLAN is that 10.20.10.0/24 must fall inside HQ's summary, which is exactly why HQ is anchored at 10.20.0.0/19 rather than at any arbitrary free block - otherwise 10.20.10.0/24 becomes an exception route that defeats summarization. Allocate WAN transit from the unclaimed half: 10.20.128.0/24 split into /31s (RFC 3021) yields 128 links, comfortably above the 40 needed, and 10.20.129.0/24 holds loopbacks. 192.168.50.0/24 lives outside 10.20/16, so OSPF would carry it as an unsummarized external and reintroduce the churn you are trying to remove; renumber the printers into the south depot block (for example 10.20.66.0/24) and run a static one-to-one NAT on the depot Layer 3 switch for a 30-day parallel period before removal.
2. The CIO asks whether each site should be built as a three-tier core/distribution/access hierarchy. Recommend an architecture and justify it against the traffic pattern and staffing.
Read the worked answer
A three-tier model is the wrong purchase here. Three tiers earn their cost when you have thousands of access ports, multiple buildings per site, or a genuine need for a distinct policy-distribution layer between routing domains. NovaFreight's largest site is 380 endpoints growing to roughly 500, traffic is overwhelmingly north-south to the HQ server farm, and east-west traffic between access closets is negligible. A two-tier collapsed core - a pair of Layer 3 switches that both route and aggregate the access switches - delivers the same summarization boundary, dual-homed access, and OSPF stub behavior at roughly half the equipment and one less layer for two engineers to troubleshoot. Invest the saved budget in redundant power, dual uplinks from each access switch, and UPS runtime rather than in a distribution layer. Put each site in its own OSPF stub area with the collapsed core as the only exit, so a flapping access port produces an intra-area event that never leaves the site and only the /19 summary crosses into area 0. Revisit the decision if HQ passes about 800 ports, adds a second building, or acquires another company that needs a fifth summary - those are the triggers, not a calendar date.
3. Name the design inputs still missing before the plan can be signed off, and explain why each changes the design rather than just the documentation.
Read the worked answer
Several unknowns can invalidate the plan. First, peak concurrent sessions rather than headcount: 30% growth in seats is a poor proxy for DHCP pool sizing and NAT table sizing. Second, voice and video QoS: if the depots run softphones, the /19 sizing is unaffected but queue design, trust boundaries, and WAN shaping appear in scope. Third, multicast - warehouse imaging or video walls would force IGMP snooping and possibly PIM where today none is needed. Fourth, IPv6 intent: dual-stack changes the summary strategy and the /31 WAN plan, so deciding now costs nothing and deciding later costs a renumber. Fifth, security zoning: does a depot need direct internet access, or is all traffic backhauled to HQ? A local breakout branch needs a local firewall and a second summarization point. Sixth, DNS/DHCP ownership and where the servers live, because a depot that loses its WAN link also loses name resolution. Seventh, the M&A pipeline, since every future acquisition consumes another summary block from 10.20.128.0/17. Finally, RTO/RPO for the DR suite and who operates routing if the WAN moves to a carrier MPLS - the two-engineer staffing model is a constraint, not a footnote.