A new elementary school is the first building in the district that is not on the same fiber ring as everything else. That single fact changes the design: every service the building uses now crosses a link you have to choose, size, and route.
The mistake to avoid is treating it as "another building on the network." It is another site, and sites need their own address block, their own default route, and a deliberate list of what stays local versus what lives at the district.
Start with the block
Give the site a block large enough that you never have to renumber, and small enough that one summary covers it.
The district uses 10.<site>.<function>.0/xx, with VLAN = site × 10 + function. For site 50:
| VLAN | Function | Subnet | Size | Hosts |
|---|---|---|---|---|
| 504 | Student | 10.50.40.0/21 |
/21 | 2,046 |
| 505 | Guest | 10.50.50.0/24 |
/24 | 254 |
| 506 | Staff | 10.50.60.0/22 |
/22 | 1,022 |
| 508 | IoT / building controls | 10.50.80.0/24 |
/24 | 254 |
| 510 | Printers | 10.50.10.0/24 |
/24 | 254 |
| 512 | Management | 10.50.20.0/24 |
/24 | 254 |
That leaves 10.50.0.0/16 as the site summary — one route at the core, and room for a second phase
without touching it.
Size the student subnet for the building, not the grade
A K-5 campus with 700 students and 1:1 devices needs roughly 1,400 leases at peak (device plus phone plus guest overflow). A /21 gives 2,046, which is comfortable. A /24 gives 254 and fails on the first day of school.
The transit link is its own subnet
The link between the district core and the campus router needs an address, and it should not be inside either site's block. Use a dedicated transit range:
| Side | Address | Purpose |
|---|---|---|
| District core | 10.0.0.9/30 |
Next hop for the campus summary |
| Campus router | 10.0.0.10/30 |
Next hop for the default route |
| Spare | 10.0.0.11/30 |
Second link or test |
/30 gives two usable addresses and is the conventional choice; /31 is valid on point-to-point
links and saves two addresses, but some gear still refuses it. Two addresses are not worth the
argument.
If the link is delivered as layer 2 (the ISP hands you a fiber and says "here is a VLAN"), you provide the routers at both ends and this is exactly the design. If it is delivered as layer 3 (the ISP routes to you), they will ask for your prefix and hand you a next hop — and then your static routes are on their side too, in a portal you should document.
Decide what lives where
Every service is either local, central, or internet. Write it down before cutover, because it decides your firewall policy and your return routes.
| Service | Where | Consequence |
|---|---|---|
| DHCP | Campus gateway | No dependency on the WAN link |
| DNS | District DCs (10.0.0.3/4) |
Needs a route and a firewall allow |
| Printing | District print server | Needs a route; local print server is an option |
| Cameras | Local NVR | Keeps video off the WAN link |
| HVAC / access control | Local controllers, vendor cloud | IoT VLAN, outbound only |
| Content filtering | District egress | All student traffic must reach the district firewall |
| Internet | District egress (or local breakout) | The biggest design decision on the page |
That last row matters more than it looks. If student traffic must be filtered centrally, the WAN link carries every student's browsing, and a 1 Gbps link becomes a bottleneck at 09:00. Local breakout with the same filtering (DNS to the district resolver, forced proxy, or a local filter) is often the better design, and it is a policy decision, not a routing one.
The route set, both directions
On the district core:
10.50.0.0/16 -> 10.0.0.10 distance 1
On the campus router:
0.0.0.0/0 -> 10.0.0.9 distance 1
10.0.0.0/8 -> 10.0.0.9 distance 1
Then the campus needs its connected routes, which it has by definition. That is the entire routing design: four lines, plus DHCP scopes and firewall policy.
Cutover order
- Address and route the link. Prove the two routers can reach each other before anything else.
- Bring up the campus router and its VLAN interfaces. No clients yet.
- Add the summary at the core and the default at the campus. Test from a laptop on a temporary port.
- Stand up DHCP and DNS locally, then test a device end to end.
- Move one VLAN at a time — staff first, then student, then IoT, then guest.
- Cut over the WAN path last, and keep the old path as a floating static for a week.
The first device on the new campus will find the gaps
A laptop that boots, gets DHCP, resolves a name, and loads a page has exercised routing, NAT, firewall policy, DNS, and the return path at once. If any one of them is wrong you will hear about it in the first five minutes — which is exactly when you want to hear about it, with the building empty.
What breaks in production
- The summary is announced before the site exists. Traffic for
10.50.0.0/16heads down a link with nothing behind it, and the black hole is invisible until someone tries. - DHCP handed out from the district, so the site is down whenever the WAN is down — including during the fiber cut you are testing.
- DNS points at the district DCs but no policy allows port 53 across the site link. Everything resolves except the new building.
- The student subnet is sized from the enrollment number instead of the device count.
- No local NTP or syslog, so the campus equipment's clocks drift and its logs are useless during the first incident.
Checklist
- The site has its own block, documented, with the summary written down.
- The transit link has its own /30 and a second address reserved.
- DHCP is local; DNS is documented with its dependency on the WAN.
- Every service is classified local, central, or internet.
- The campus has a default route and the core has exactly one summary.
- Cutover is one VLAN at a time, with a test device per VLAN.
Next
The design assumes a link. Continue with Routing Between Sites: Fiber, VPN, and UniFi to choose it and to make the backup work.