IPAM and Naming That Scale

Every network has an address plan. In some districts it is a spreadsheet, in others it is a wiki page, and in the worst cases it is the memory of the person who built it. The plan exists either way; the only question is whether it survives that person's vacation.

At 113 networks and four sites, the plan is the difference between a ten-minute change and a two-hour archaeology project.

The scheme is the documentation

A good scheme lets you derive an address from a name and a name from an address without looking anything up. The district's does:

10.<site>.<function>.0/<prefix>
VLAN = site × 10 + function index

Function index is stable across sites: 40 student, 50 guest, 60 staff, 80 IoT, 10 printers, 20 management. Now 10.50.40.57 is self-describing: site 50, student, host 57. No lookup required.

Naming: role, site, number

Device names should sort usefully and decode without a spreadsheet:

The point is not aesthetics. It is that ap-mps-14 appears in a log, in a controller, on a label, and in a ticket, and every one of those places should be searchable by the same string.

Reserved ranges inside every subnet

Pick a layout and use it everywhere, so a scan result is immediately interpretable:

This is a convention, not a protocol. Its value is that "why is .7 responding to ping" has an answer without a lookup.

Tooling, from spreadsheet to source of truth

For a district this size, a structured file in the same repository as the documentation is usually the right answer: it is reviewable, diffable, and survives a vendor change. A full IPAM pays off when several people allocate addresses daily.

Worked example: allocating a site

New campus, site 50:

1. Reserve 10.50.0.0/16, and record it in the plan before anything is built.
2. Assign functions: 504 student /21, 505 guest /24, 506 staff /22, 508 IoT /24, 510 printers /24, 512 management /24.
3. Reserve .2–.9 in each subnet for infrastructure, .200–.250 for DHCP.
4. Create reverse zones for each subnet that appears in logs.
5. Add the summary 10.50.0.0/16 to the routing documentation.
6. Publish the plan where the on-call person will look, not in a folder only you can find.

Total: one table, six subnets, one summary, and a name for every device.

What breaks in production

• Undocumented static addresses. A device with a hand-typed address inside the DHCP pool causes a duplicate, and the symptom is intermittent and blames the network.
• Two sites, one subnet. Route tables pick a winner and the other site silently loses. This is the most expensive mistake an address plan can produce.
• Names that lie. sw-mhs-01 in the middle school after a move; logs point at the wrong building.
• Reverse zones nobody maintains. Every incident becomes a reverse lookup exercise.
• The plan lives in one person's head. The next person rebuilds it from ARP tables.

Checklist

1. Every address is derivable from the scheme, and every scheme is written down.
2. Each site has a reserved block, and nothing outside it uses that space.
3. Function indices are identical across sites.
4. Reserved ranges inside each subnet are consistent and documented.
5. Device naming is role-site-number, and it is searchable across systems.
6. The plan is version-controlled and reviewed like code.

Next

The plan is written; the services must survive a failure. Continue with High Availability for Core Services.