IP addressing is one of those foundational decisions that most organisations make once, badly, and then spend years working around. It happens organically — a network engineer picks a convenient range, subnets get added as the business grows, and before long you have a patchwork of overlapping, inconsistently sized, poorly documented address space that nobody fully understands and everyone is afraid to touch.
That is not a network problem. It is an architecture problem — with real consequences for security, automation, compliance, and your ability to scale. This post covers the key considerations for designing an internal IP addressing strategy, written from the perspective of someone who has inherited broken schemas, designed replacements, and lived through the rollout.
Why IP Addressing Strategy Matters
IP addresses in a modern enterprise are not just routing labels. They are identity signals, segmentation boundaries, firewall policy anchors, automation inputs, and audit artefacts.
A predictable schema means that when you see 10.14.32.45 in a firewall log, you know immediately it is a server in your Manchester datacentre, production zone, application tier — without querying a CMDB or asking a colleague. Contrast that with a flat, unstructured schema where the same 192.168.1.x range appears in three locations. Troubleshooting becomes archaeology. Automation becomes fragile. And when an incident occurs, the time spent working out what is affected is time not spent on containment.
One point worth making explicitly: avoid default home network ranges — particularly 192.168.0.0/24 and 192.168.1.0/24. In a hybrid working environment, these overlap with virtually every consumer router and home broadband connection, causing routing conflicts and split-tunnel failures that are entirely avoidable with a deliberate choice of less-common RFC 1918 space.
Security Perimeters and Segmentation
Your IP schema is the physical expression of your security architecture. IP ranges should align with security zones, not just physical or functional groupings. A subnet containing both privileged management interfaces and standard workstations is not a security boundary — it is a liability. Larger subnets increase blast radius and make precise firewall rules harder to write.
Map your schema to data classification boundaries and sensitive zones before assigning a single address. The questions to answer: What are your distinct security zones — production, development, management, user, guest, IoT? What traffic is permitted between zones? Where are your most sensitive assets, and are they in explicitly restricted ranges?
In cloud environments — Azure VNETs, AWS VPCs — the same logic applies. Your cloud address space should be a deliberate extension of your on-premises schema. Overlapping ranges between on-premises and cloud are a common source of VPN and ExpressRoute failures that are entirely avoidable at design time.
Datacentres vs Offices
Datacentre and office environments have fundamentally different addressing requirements. In a datacentre, workloads are high-density and relatively static. The priority is precision — small, well-defined subnets mapped to specific tiers (web, application, database, management) that make east-west traffic patterns explicit and controllable.
Office environments are the opposite: dynamic, high-churn device populations that connect and disconnect constantly. The priority is scalability and manageability, with subnets segmented by device type and security classification. A subnet mixing corporate laptops with guest Wi-Fi is not a design — it is an oversight.
Wi-Fi Roaming and the Layer 3 Subnet Boundary
One of the most consistently overlooked interactions between IP addressing strategy and physical network design is Wi-Fi roaming — a common enterprise pitfall whose consequences are visible to every user in the building.
The fundamental rule: devices roaming between Wireless Access Points broadcasting the same SSID must remain within the same Layer 3 subnet. When a device moves between WAPs, the handover is handled at Layer 2 — the device retains its IP, TCP sessions stay open, and the transition is invisible to the user. That seamlessness depends entirely on the device staying within the same broadcast domain throughout its journey.
Break that assumption, and everything breaks with it. When a user walks between floors on different subnets, the device must release its DHCP lease, obtain a new IP, re-establish DNS, and rebuild active TCP connections. The impact is immediate:
- Teams, Zoom, and Webex calls drop — real-time UC sessions terminate when the IP changes mid-call. In a multi-floor office where people move during calls, this is a daily occurrence, not an edge case.
- VPN tunnels collapse — corporate VPN clients bind to a specific local IP; a change forces full tunnel re-establishment, interrupting all traffic for 10–30 seconds.
- Application sessions time out — any system maintaining server-side session state keyed to client IP will drop the user and require re-authentication.
The Correct Design Approach
Design wireless subnets around roaming domains, not physical floors. All WAPs broadcasting the same SSID within a contiguous roaming area should be on the same VLAN, served by the same DHCP scope. A corporate wireless subnet for a 400-person building likely needs a /22 or larger. You cannot have both a /27 per floor and seamless roaming across floors — choose one.
Where security segmentation is required within the wireless estate, use separate SSIDs mapped to separate VLANs rather than splitting a single SSID across subnets. Each SSID becomes its own roaming domain, and the security boundary is enforced at the SSID level.
Knock-on Effects Across the Schema
- VLAN design: Wireless VLANs must be trunked across all access switches in the building — with implications for spanning tree topology and switch configuration standards.
- DHCP scopes: One correctly sized scope per wireless SSID per site. Centralised DHCP with relay on each access switch is the standard pattern.
- Security boundaries: Apply firewall policy at the SSID-to-VLAN boundary, not per floor — consistent policy regardless of which WAP a device is associated with.
- Scalability: Reserve address space for wireless growth at design time. Re-addressing a live wireless subnet is a significant project. Size generously from the start.
Subnet Sizing and Scalability
Size for realistic peak occupancy plus 20–30% headroom. For a standard office floor with 80 workstations, a /25 (126 usable addresses) is usually appropriate. For server subnets in a datacentre, smaller is almost always better — a /27 or /28 per application tier forces discipline and limits blast radius.
Use consistent sizes within a category — all office floors get /25, all server tiers get /27 — so your schema is predictable. Reserve contiguous blocks for future expansion at design time. Inconsistency is the enemy of automation and documentation.
Static IP Devices and How They Are Identified
Not every device in your estate is dynamically addressed. Servers, network infrastructure, printers, and fixed AV equipment typically carry static IPs — requiring a different approach to planning, documentation, and security enforcement.
Static devices are usually identified by:
- Function and role. Infrastructure devices — core switches, firewalls, hypervisors, domain controllers — are almost always statically addressed. Their IPs are referenced in routing tables, firewall rules, and monitoring configurations, making dynamic addressing impractical.
- MAC address patterns. Enterprise hardware OUI prefixes allow infrastructure to be distinguished from end-user devices in DHCP logs and network scans before a hostname is resolved.
- Naming conventions. A consistent hostname schema —
MAN-SW-CORE-01,LON-SRV-APP-04— makes static devices immediately identifiable in logs and IPAM records without cross-referencing an address. - DHCP reservations. Many organisations bind a fixed IP to a MAC address at the scope level rather than configuring static addresses on the device itself, keeping addressing centralised in IPAM.
Static devices must be allocated from a dedicated range within each subnet — typically the lower address space — so the dynamic DHCP pool cannot overlap. Firewall rules referencing static IPs are brittle: re-address a device without updating the rule and the policy silently breaks. Any re-addressing exercise must begin with a full audit of static assignments, including those outside IPAM.
Schema Design and Octet Logic
The goal is to encode meaning into the address structure itself. A practical approach for a multi-site enterprise using 10.0.0.0/8 space:
32 = Zone + function (production application tier)
/27 = Subnet size (30 usable hosts — server tier)
The second octet encodes location — 10.14.x.x is Manchester, 10.21.x.x is London, 10.50.x.x is Azure UK South. The third octet encodes zone and function: 10–19 for production servers, 20–29 for development, 30–39 for management, 100–199 for user workstations, 220–239 for IoT.
The benefits compound quickly. Firewall rules become readable. Automation scripts derive zone membership from the address without a database lookup. Troubleshooting logs become self-documenting. A new engineer can learn the schema in an afternoon.
Firewall Policies and Static Rules
A well-structured schema dramatically reduces firewall rule complexity. When all production servers sit in a consistent range, a single rule applies universally rather than site-specific rules that diverge over time. The pathology to avoid is rule sprawl — hundreds of host-to-host rules accumulated over years, many no longer valid, none that anyone is confident enough to remove. This is almost always a symptom of an inconsistent addressing schema.
When migrating to a new schema: audit existing rules against current traffic flows first; map old ranges to new ranges explicitly and translate rules in batches; run old and new ranges in parallel during transition before decommissioning old space.
Implementation: The Real-World Rollout
IP scavenging and reclamation. Audit what you have before allocating new ranges. A proper scavenging exercise typically recovers 20–40% of allocated space, reducing the re-addressing scope significantly.
DNS and DHCP in lockstep. Reverse DNS zones must be created for new ranges before devices are moved. DHCP scopes must be active on the correct VLANs before old scopes are decommissioned. Devices that get a new IP but cannot resolve DNS generate immediate support tickets.
Transition periods. For anything other than a small environment, run old and new ranges simultaneously for four to eight weeks, with routing in place to allow communication between them. Migrate devices in batches, validate connectivity, and resolve issues without a hard deadline forcing rushed decisions.
Communication. End users will notice IP changes if they have static IPs, VPN configurations, or application shortcuts referencing addresses directly. A structured communication plan with a clear timeline and a rollback procedure is not optional.
Compliance and Accreditation
Cyber Essentials Plus. CE+ requires demonstrable network segmentation, boundary protection, and device identification. A structured IP schema makes all three demonstrable in minutes; an unstructured one buries the evidence in VLAN configurations and firewall rules that require significant interpretation.
ISO 27001. Controls around asset management (A.8), access control (A.9), and secure configuration (A.8.9) all have direct implications for IP addressing. A structured schema in IPAM with documented zone definitions satisfies these controls in a way an ad hoc schema cannot. Pointing to a schema where production is consistently 10.x.10.0/24 and development is consistently 10.x.20.0/24 across all sites is a far more compelling audit answer than a verbal explanation.
Final Recommendations
Treat IP addressing as architecture, not administration. This decision belongs in the same conversation as your security architecture and automation roadmap.
Encode meaning into the schema from the start. Every address should tell a story — site, zone, function, device type. If you cannot read the story from the address, the schema is not doing its job.
Align subnets with security zones. The security boundary is the unit of design. Everything else — VLAN, DHCP scope, firewall rule — follows from it.
Size for discipline, not convenience. Smaller, more precise subnets are harder to manage in the short term and significantly safer in the long term.
Document the schema as a first-class artefact. It should be a living document reviewed as part of every significant network change — not something that exists only in the head of the person who designed it.
IP addressing is unglamorous work, but it is the substrate on which everything else runs. The organisations that treat it as a strategic decision have networks that are easier to secure, easier to automate, and easier to audit. The ones that treat it as an afterthought tend to find out why that matters at the worst possible time.