Designing an IP Plan from Scratch: A Worked Example

Most IP (Internet Protocol) plans don't start as plans. They start as a single subnet on day one, then a second one bolted on for the new office, then a third for that thing somebody set up in the cloud. By year three, the route table reads like a ransom note, every Access Control List (ACL, the rules a router uses to decide which traffic to allow or block) has been patched twice, and the day a competitor gets acquired, half the network has to be renumbered. None of that has to happen. The cost of a careful IP plan, drafted in an afternoon, is hours. The cost of skipping it, paid back over years in renumbering projects and outages, runs to weeks of engineering time per incident. This post walks through that plan from a blank page, using a fictional but realistic company as the worked example.

Step 1: Inventory before allocation

Before drawing a single line on a diagram, write down what you actually have to support. The questions to answer are roughly the same for every organization: how many physical sites, how many devices per site, what kinds of networks each site needs (typically users, voice, Wi-Fi, servers, IoT, guest, management, and sometimes a DMZ), how much you expect to grow over the next five years, and whether any address space already exists that you can't move. The single question that gets forgotten most often is whether your address space has to coexist with anyone else's. If you ever expect to absorb another company, share routes with a partner, or host customer environments you don't fully control, your plan needs an answer for what happens when their addresses collide with yours.

For the rest of this post, the worked example is a fictional logistics company called Meridian Logistics. Their network looks like this. Three offices: a Chicago headquarters with about 600 people, a Dallas branch with 150, and an Atlanta branch with 100. One colocation data center in Ashburn, Virginia, holding around 120 physical and virtual servers. A cloud footprint in Amazon Web Services (AWS) across two regions. A wide-area network (WAN, the long-distance links that connect offices to each other and to the data center) of point-to-point connections between the offices and Ashburn. A small lab environment at the Chicago headquarters. A recent acquisition called Cargo-Co, whose internal network uses 10.1.0.0/16, the same range Meridian was planning to assign to its Dallas branch. And a five-year horizon that calls for doubling the user count and tripling the cloud footprint. Every constraint in that list will drive a real decision in the plan that follows.

Step 2: Pick the aggregate

The phrase "pick the aggregate" means choosing the single largest block of private address space the entire organization will draw from. Three private ranges are available, set aside by a 1996 standards document called RFC 1918. (RFC stands for Request for Comments, the name used for the technical specifications that define how the internet works.) The three ranges are 192.168.0.0/16, which holds about 65,000 addresses and suits home networks; 172.16.0.0/12, which holds about a million addresses and tends to be the middle option; and 10.0.0.0/8, which holds about 16.8 million addresses. A longer treatment of these ranges, along with seven other reserved blocks worth knowing, lives in a separate post on this blog.

For anything larger than a single small office, pick 10.0.0.0/8. The math is generous enough that you'll never run out, the ranges inside it are easy to read, and almost every networking tool defaults to expecting it. Picking a smaller range to "save space" is a false economy: the address space inside 10.0.0.0/8 has no real cost, and the cost of outgrowing your aggregate later is an organization-wide renumber. Pick once, pick big, never come back. Meridian picks 10.0.0.0/8, and the rest of the carve flows from there.

Step 3: Carve the top level by purpose, not by site

This is the most important step in the entire post. The instinct most teams have is to carve the aggregate by site: HQ gets the first slice, Dallas the next, the data center the one after that. Function-first carving, where each top-level block is reserved for a category of network rather than a specific location, scales much better, for reasons worth working through.

The reason is that sites change. Offices open, close, merge, get sold off in a divestiture. Functions change much more slowly. You will probably always have on-premises networks, cloud workloads, lab environments, and infrastructure plumbing. Allocating by function lets you summarize cleanly in route tables, gives every engineer a stable mental model, and reserves a "growth pen" you can dip into later without retrofitting. Here's how Meridian carves the top level of 10.0.0.0/8.

Top-level allocation: function-first

10.0.0.0/8                Meridian aggregate
├── 10.0.0.0/12       On-prem sites (HQ + branches)
├── 10.16.0.0/12      Data center (Ashburn colo)
├── 10.32.0.0/12      Cloud (AWS, kept separate from on-prem)
├── 10.48.0.0/12      Lab / staging / pre-prod
├── 10.64.0.0/16      Infrastructure (loopbacks, P2P WAN, OOB management)
├── 10.65.0.0/16      Acquisitions holding pen
└── 10.128.0.0/9      Reserved for future growth (don't touch)

A few things to notice. The first four blocks are each /12s, which is roughly a million addresses each. That is far more than Meridian needs today, which is exactly the point: every block has decades of room to grow inside it. Infrastructure space gets its own /16 because the things that go there (router loopbacks, point-to-point links between routers, out-of-band management interfaces) don't naturally belong inside any one site. The acquisitions pen is a /16 reserved up front, so the next time someone gets bought, you have a place to put them while you sort out the renumber.

The biggest block, 10.128.0.0/9, holds half the entire aggregate and is explicitly reserved for "don't touch yet." That reservation is pure optionality. Five years from now, you might need a giant slice for an unexpected workload, or to absorb a competitor twice your size. Holding half your space in reserve means you don't have to scramble.

Step 4: Site-level allocation

Now take the on-prem /12, 10.0.0.0/12, and split it among the offices. A /12 contains 16 different /16 blocks, so you can hand each site its own /16 and still have plenty left over.

On-prem sites: a /16 per office, with room for more

10.0.0.0/12                  On-prem sites
├── 10.0.0.0/16             Chicago HQ
├── 10.1.0.0/16             Dallas branch
├── 10.2.0.0/16             Atlanta branch
├── 10.3.0.0/16             Reserved (next office)
├── ...
└── 10.15.0.0/16            Reserved

A reasonable question at this point is whether each site really needs a /16. Atlanta has 100 people. A /16 holds 65,000 addresses. That is hilariously oversized.

The reason to give every site a /16 anyway is that you don't allocate addresses for the user count alone. You allocate for the user count plus all the supporting networks the site needs: a Wi-Fi network for laptops, another for phones, another for guests, a server segment for local infrastructure, a printer and IoT (Internet of Things, the term for connected devices that aren't traditional computers, like printers, badge readers, and security cameras) network, a management network for the network gear itself, sometimes a DMZ (demilitarized zone, a network segment deliberately isolated from the rest and used to host things that need to face the public internet), and so on. Each of those is a separate VLAN at minimum, and once you start counting, even a small office burns through a few thousand addresses comfortably. A /16 per site means you never have to come back and renumber when a site adds a new VLAN.

VLAN, by the way, stands for Virtual LAN, and LAN means Local Area Network. A VLAN is a way of running multiple separate networks over the same physical wiring, which is how every modern office keeps user traffic, voice traffic, and server traffic from mingling. If sizing subnets is unfamiliar, the CIDR guide on this blog walks through how to pick the right block size for a given device count.

Step 5: A VLAN scheme that scales

With a /16 per site, the next decision is how to slice each /16 into per-VLAN subnets. The trick that pays off forever is to make the third octet of every subnet match the VLAN ID. Anybody looking at an IP address can then read its VLAN out of the address itself, without consulting documentation. Here's the convention Meridian adopts and applies identically at every site.

Applied to the Chicago headquarters, where the second octet is 0, the carve looks like this. Dallas, where the second octet is 1, gets the identical layout shifted to 10.1.x.x; Atlanta, with a 2, shifts to 10.2.x.x. The convention is what makes that shift painless.

Chicago HQ: same scheme, second octet = 0

10.0.0.0/16                  Chicago HQ
├── 10.0.10.0/24            VLAN 10  Users
├── 10.0.20.0/24            VLAN 20  Voice
├── 10.0.30.0/24            VLAN 30  Wi-Fi corp
├── 10.0.31.0/24            VLAN 31  Wi-Fi guest
├── 10.0.40.0/24            VLAN 40  Printers / IoT
├── 10.0.50.0/23            VLAN 50  Servers
├── 10.0.60.0/24            VLAN 60  DMZ
└── 10.0.99.0/24            VLAN 99  Management

Look at an address like 10.2.30.42. Without checking anything, you know it's the Atlanta branch (second octet 2), corporate Wi-Fi (third octet 30 maps to VLAN 30), and host 42 within that segment. That fluency, multiplied across hundreds of engineers and thousands of tickets, is what makes this convention worth so much more than its tiny up-front cost. The server VLAN gets a /23 instead of a /24 because servers tend to outgrow their original subnet first, and pre-allocating the extra space is free.

Step 6: Special-purpose space

Some networks don't fit the per-site mental model and shouldn't be jammed in. Three of them deserve their own home, drawn from the infrastructure /16 set aside earlier (10.64.0.0/16).

The first is router loopbacks. A loopback is a virtual interface on a router that exists for management and routing-protocol purposes; each router gets a single /32 (a single IP address) loopback drawn from a dedicated /24. With 256 addresses, Meridian can label every router for the foreseeable future. The second is point-to-point WAN links, the connections between one router and another, typically across a long-distance circuit. Each link only ever has two devices on it, so a /31 (two addresses) is exactly the right size, and a dedicated /24 broken into /31s gives 128 router-to-router links. The third is out-of-band management. "Out-of-band" means the network used to reach the management interfaces of network gear when the main network is down. It needs its own segment, ideally with completely separate physical paths, and gets its own large block carved from the infrastructure space.

Infrastructure space: shared resources, not site-specific

10.64.0.0/16                 Infrastructure
├── 10.64.0.0/24            Router loopbacks (256 /32s)
├── 10.64.1.0/24            Point-to-point WAN links (128 /31s)
└── 10.64.128.0/17          Out-of-band management

The big idea is that these are shared resources, not site-specific resources. Putting the loopback for the Chicago core router inside 10.0.0.0/16 makes sense for two minutes and then makes no sense for a decade. Keep them separate.

Step 7: Cloud is a separate world

The cloud /12, 10.32.0.0/12, gets its own carve, and the temptation to fold cloud allocation into on-prem space should be resisted. Cloud networks behave differently from physical ones. They get destroyed and recreated all the time, which on-prem networks don't. They aggregate by region and Virtual Private Cloud (VPC, the AWS term for a private network you've defined inside their cloud), not by office or floor. They route differently across availability zones (AZs, AWS's term for separate data center buildings within a single region). And the blast radius of a misallocation in the cloud is usually a Terraform run, while on-prem mistakes mean a truck roll. Mixing the two leads to a plan that has to compromise on both sides. A clean cloud carve uses a /16 per region, a /20 per VPC, and a /24 per AZ subnet within each VPC.

Cloud allocation: region → VPC → AZ subnet

10.32.0.0/12                 Cloud aggregate (AWS)
├── 10.32.0.0/16            us-east-1
│   ├── 10.32.0.0/20        prod-vpc-1
│   │   ├── 10.32.0.0/24    AZ a
│   │   ├── 10.32.1.0/24    AZ b
│   │   └── 10.32.2.0/24    AZ c
│   ├── 10.32.16.0/20       prod-vpc-2
│   ├── 10.32.32.0/20       stage-vpc
│   └── ...
└── 10.33.0.0/16            us-west-2
    └── ...

With sixteen /20s available inside each /16, Meridian can host sixteen VPCs per region, already more than they need today, with fifteen more /16s available before the next region runs out. If you're working across more than one cloud provider, the multi-cloud post on this blog goes deeper on hybrid allocation patterns and overlap headaches.

Step 8: When you actually need a VRF

This is the Cargo-Co problem. The acquired company runs 10.1.0.0/16 internally, the exact range Meridian assigned to the Dallas branch. There are three options.

The first is to renumber Cargo-Co. Months of work. Every device they own changes addresses, every certificate has to be reissued, every DNS record has to be updated, every hardcoded reference in legacy applications has to be hunted down. This is what you'd do if you had infinite time and they were small. The second is to renumber Dallas, which is worse. Dallas is your network, with your engineers, your tickets, your customers depending on it. You don't disrupt your own production to accommodate the acquired company. The third is to keep both running, separated by a Virtual Routing and Forwarding instance, called a VRF. A VRF is a way to run multiple completely independent routing tables on the same physical network gear, so that overlapping addresses live in parallel universes that never see each other unless you explicitly bridge them. Cargo-Co's 10.1.0.0/16 lives in its own VRF, Dallas's 10.1.0.0/16 lives in the default VRF, and traffic between them passes through a controlled gateway that translates addresses where it crosses over.

For an acquisition, option three is almost always the right answer. It buys you time to renumber on your own schedule, isolates the new network until you're confident in its security posture, and avoids any production disruption. The VLANs vs VRFs guide on this blog goes deeper on when each tool is appropriate. The short version is that VLANs separate networks at one site, while VRFs separate routing domains across an entire infrastructure.

It is worth being clear about when not to use a VRF. If two departments inside Meridian need to be separated, but their address ranges don't overlap, that is a folder problem in your IPAM and an ACL problem on your routers. VRFs are the tool when you genuinely need overlapping address space to coexist. Reaching for them in any other situation adds operational complexity for no benefit.

Step 9: Organizing the plan in IPCraft

Once the design is on paper, it has to live somewhere engineers actually look. In IPCraft (IP Address Management, the category of tool that tracks what addresses your organization owns and what each one is being used for), the plan maps onto four primitives: folders, VLANs, VRFs, and locations.

Folders give you the function-first hierarchy directly. Meridian's folder tree mirrors the top-level carve: an On-Prem folder with subfolders for Chicago, Dallas, and Atlanta; a Data Center folder containing the Ashburn colo; a Cloud folder with AWS and per-region subfolders; a Lab folder; an Infrastructure folder for shared resources; and an Acquisitions folder containing Cargo-Co. Subnets get filed under the folder that matches their function, and the hierarchy in IPCraft mirrors the conceptual carve. An engineer browsing for the Chicago user VLAN doesn't need to know its address; they navigate to On-Prem, then HQ Chicago, and find it.

VLANs are tracked as objects in IPCraft and attached to the subnets they correspond to. Once VLAN 30 is defined as Wi-Fi corporate at the headquarters, every subnet using that VLAN ID stays tagged consistently, and you can search for all corporate Wi-Fi networks across every site in one click. VRFs in IPCraft handle the Cargo-Co case directly. Cargo-Co's 10.1.0.0/16 lives in a VRF named cargo-co, and Dallas's 10.1.0.0/16 lives in the default VRF. The IPAM is the only place in your stack where both can coexist without one of them being technically wrong. Locations represent the physical sites: each office and data center gets registered with an address and tagged with the folders it relates to. If you'd like to provision new subnets against this plan programmatically rather than by hand, the API automation post on this blog walks through doing it with curl, Terraform, and Ansible.

Step 10: The plan only works if it's the source of truth

A beautifully designed IP plan that lives in a Confluence page or a shared spreadsheet has a lifespan of about three weeks. The first time someone provisions a new VLAN at one in the morning to fix an outage, they update the network gear and skip the doc. The plan diverges from reality, and once divergence starts, it accelerates: every later change feels less worth documenting because the doc is already wrong about something.

The plan has to live in the same tool engineers reach for when they need to look up an address. That way, the act of using the IPAM and the act of maintaining the plan are the same act. Pair this with a yearly review, plus an ad-hoc review after any acquisition, major project, or new site opening, and the plan stays alive. The Meridian carve described here would survive a decade of growth without renumbering, but only if it's actively maintained. The carve plus active maintenance is what makes that ten-year horizon real.

The whole plan, top to bottom

Here is the entire Meridian plan in one diagram. Screenshot it if it's useful.

Meridian Logistics: complete IP plan

10.0.0.0/8                          MERIDIAN AGGREGATE
│
├── 10.0.0.0/12                    ON-PREM SITES
│   ├── 10.0.0.0/16                Chicago HQ
│   │   ├── 10.0.10.0/24           VLAN 10  Users
│   │   ├── 10.0.20.0/24           VLAN 20  Voice
│   │   ├── 10.0.30.0/24           VLAN 30  Wi-Fi corp
│   │   ├── 10.0.31.0/24           VLAN 31  Wi-Fi guest
│   │   ├── 10.0.40.0/24           VLAN 40  Printers / IoT
│   │   ├── 10.0.50.0/23           VLAN 50  Servers
│   │   ├── 10.0.60.0/24           VLAN 60  DMZ
│   │   └── 10.0.99.0/24           VLAN 99  Management
│   ├── 10.1.0.0/16                Dallas branch (same VLAN scheme)
│   ├── 10.2.0.0/16                Atlanta branch (same VLAN scheme)
│   └── 10.3.0.0/16 - 10.15.0.0/16 Reserved for future sites
│
├── 10.16.0.0/12                   DATA CENTER
│   └── 10.16.0.0/16               Ashburn colo
│
├── 10.32.0.0/12                   CLOUD (AWS)
│   ├── 10.32.0.0/16               us-east-1
│   │   ├── 10.32.0.0/20           prod-vpc-1
│   │   ├── 10.32.16.0/20          prod-vpc-2
│   │   └── 10.32.32.0/20          stage-vpc
│   └── 10.33.0.0/16               us-west-2
│
├── 10.48.0.0/12                   LAB / STAGING / PRE-PROD
│
├── 10.64.0.0/16                   INFRASTRUCTURE
│   ├── 10.64.0.0/24               Router loopbacks
│   ├── 10.64.1.0/24               Point-to-point WAN links
│   └── 10.64.128.0/17             Out-of-band management
│
├── 10.65.0.0/16                   ACQUISITIONS HOLDING PEN
│
└── 10.128.0.0/9                   RESERVED FOR FUTURE GROWTH

# Separate VRF, deliberately overlapping with Dallas:
cargo-co VRF:  10.1.0.0/16  (acquired network, isolated until renumbered)

The bigger payoff is fluency. Any engineer hired in 2030 can read an address like 10.2.30.42 and know exactly where it lives, who owns it, and what kind of device sits behind it. That is what designing an IP plan from scratch buys you, when you do it once, do it carefully, and put it somewhere that stays alive.