Understanding Network Infrastructure · Part 4 · How do we use these principles to design a real network?
How can a company avoid overlapping private IP ranges?
Prevent overlap before connecting networks; plan for route summaries, growth, and ownership
If headquarters, branches, and clouds may be connected later, private ranges that look unused today cannot be assigned casually. Divide addresses by region, site, and function, and manage both the approved plan and actual usage in IPAM. We examine overlap prevention, a hierarchy that supports route summaries, DHCP ranges, integration after acquiring another organization's network, and cloud connectivity.
Which addresses should we inventory before connecting headquarters, branches, and clouds?↑
Planning private addresses around headquarters and branch LANs alone risks later collisions with cloud VPCs, remote-access pools, partner VPNs, and acquired networks. Record candidate prefixes and responsible owners even for future connections outside your direct management.
Whichever of the three RFC 1918 blocks you choose, do not reserve the entire block as though you will use it all. Size the parent block for expected growth and possible external connections, and document why unused space is being left free.
Include possible future connections in the address map, not just networks currently exchanging routes. Remote-access VPN pools, Kubernetes Pod and service CIDRs, cloud peering, backup networks, and device-management ranges are easy to miss. The same prefix can coexist while isolated in separate VRFs, but connecting services between those VRFs raises questions of address translation or readdressing. Record the isolation conditions as part of the address asset too.
Do not select a parent block merely because it looks free within RFC 1918. Consider ranges commonly used by existing partners, cloud-provider reservations, the future number of regions, and summaries needed per site. Give spare space an owning team and conditions for use. Unexplained gaps tend to go to the next project; documented headroom preserves the intended growth plan.
Record each prefix's location, function, VRF/routing context, parent block, status, owning team, change ticket, and last observation time. Marking a large range such as 10.0.0.0/8 merely “in use” does not show what is free. Conversely, a failed ping does not prove an address is free: it may belong to an asset behind a firewall or temporarily offline, and reassigning it could create a conflict. Keep declared allocation and observed usage in separate fields.
Sources for this section IETF RFC 1918 · IETF RFC 4632 · IETF RFC 4193
Address blocks organized by region and function help organize routes and failure domains↑
Allocating parent blocks to regions or major network areas first makes it easier to advertise one summary at the WAN boundary as a single route. Within each block, separate uses with different operational or security policies, such as users, servers, management, and voice.
Putting a branch number in an octet may make an address easy to read, but it breaks summarization if it does not align with prefix boundaries. Prioritize contiguous binary prefixes and real organizational boundaries over the appearance of the numbers.
For example, an organization could choose 10.64.0.0/10 for internal use, assigning region A 10.64.0.0/14 and region B 10.68.0.0/14. Each region allocates user, server, and management prefixes within its block and advertises a /14 summary to the WAN. Placing new sites within their region's block can keep the upstream routers' route count and change scope stable.
An overly broad summary may attract traffic for nonexistent child prefixes into the region. At the region boundary, design the discard route, more-specific advertisements from redundant sites, and behavior during partial failures together. If security zones and recovery units do not align with address boundaries, policies and routes become more complex. What matters most is whether routes, failure domains, and operational responsibility align at the same prefix boundaries, not whether the addresses look tidy.
Advertising a summary attracts traffic for addresses it covers. If a child route disappears but the summary remains, traffic can reach the aggregation point and then be discarded. When dividing an address block, consider aggregation points, redundant paths, and partial-range failures together. Any exception route must also be checked against the existing summary coverage.
Sources for this section IETF RFC 4632
Within one subnet, infrastructure, fixed-address clients, and general clients need different address management↑
Gateways, network equipment, servers, and DHCP clients can share a subnet while using different allocation methods. Keep the dynamic pool separate from manually configured static addresses, and record DHCP reservations as allocated in IPAM too.
| State | Typical use | Required records |
|---|---|---|
| Infrastructure | Gateways · Switches · APs | Device · Interface · Responsible owner |
| Reservation | Printers · Designated clients | Identifier · Reason for reservation |
| Dynamic Pool | General clients | Scope · Lease · Exclusions |
| Held | Planned expansion or migration | Owner · Release conditions |
The DHCP scope, reservations, dynamic range, and exclusions must agree with the address plan in IPAM. That does not mean they must all cover the same numeric range. Distinguish their roles, and prevent manually configured addresses from being dynamically assigned to other endpoints.
An address needs more than an “in use” flag: record its owner, interface, allocation method, and grounds for creation and expiration. Link a reservation to the server configuration and client identifier; a static address to device configuration and a change request; and a dynamic address to its scope and lease. If a removed printer leaves a reservation and DNS record behind, its address may appear permanently occupied. Include cleanup of DNS, DHCP, and IPAM in asset retirement so availability reflects reality.
Define the pool boundaries so manually assigned static addresses cannot overlap dynamically allocated addresses. Also define DNS updates, asset registration, and lease retention periods. If security requirements call for tracing address use over time, synchronize the timestamps in NAT logs and authentication records as well. Do not assume that a single IPAM field proves who is actually using every address in real time.
Sources for this section IETF RFC 1918 · IETF RFC 2131 · Microsoft IP Address Management
What to look for The /24 example on the left separates the roles of the gateway address, static infrastructure addresses, the DHCP lease pool, and the spare address block. The connections from the devices in the middle to the right compare in-band management, which shares the service network, with a separate out-of-band management network. Address allocation and management access paths are separate design decisions.
↔ Scroll horizontally to explore the diagram.
Why is overlap harder to fix after connecting a cloud or acquired company?↑
If two networks use the same prefix, a router cannot distinguish them by destination alone. NAT can enable some connections, but DNS, logs, bidirectional access, and operations become more complex.
Before connecting a new VPC, branch, or acquired network, compare prefix inventories automatically and plan readdressing on the side that can change. If temporary NAT is used, document its exit conditions and the original-to-translated address mapping.
If headquarters uses 10.10.0.0/16 and an acquired company uses the same prefix, placing both routes in one VRF does not distinguish the destinations. A NAT domain can provide a quick connection for selected applications, but plan how each side's DNS returns original or translated addresses and which side initiates connections. Logs and access policies also need a way to correlate both addresses.
For long-term integration, readdressing the side that can change usually leads to a simpler target design. Changing addresses without checking server dependencies, license bindings, ACLs, and static routes can cause hidden failures. Preconnection prefix overlap checks must find not only identical CIDRs but also a prefix contained within another prefix. Temporary NAT needs a service scope, end date, owner, and readdressing steps so it does not become permanent by default.
Before connecting, compare both sides' prefixes using exact prefix lengths and VRF contexts. If they conflict, choose which side to renumber based on its remaining lifetime, device count, and external dependencies. For temporary NAT, document owners for original and translated addresses, permitted services, log retention, and exit conditions. For lasting connections, reserve central blocks in advance and require review instead of accepting automatically generated cloud CIDRs unchanged.
Sources for this section IETF RFC 1918 · IETF RFC 4193
IPAM cannot be a source of truth if it only lists free addresses↑
IPAM must connect prefixes, VLANs, VRFs, sites, DHCP scopes, and actual address states. Reclamation and incident response need more than usage flags: retain who created a reservation, why it exists, and which change allocated the address.
When observations from device configuration, DHCP/DNS, or cloud APIs differ from IPAM, decide which record is authoritative. Automatic collection finds discrepancies; it does not turn unapproved observations into the correct values by overwriting the plan.
For a new VLAN, use IPAM to reserve its prefix and gateway first, then apply the approved values to DHCP, DNS, and network configuration. Creating addresses on devices before recording them in IPAM can reveal duplicates too late. A source of truth is the reference for approved address plans and changes, not a claim that every displayed value is always correct.
Discovery compares actual conditions with the approved plan. Do not identify an address user from a ping response alone; compare ARP/MAC data, DHCP leases, DNS, and cloud API results. Before correcting differences automatically, decide which record governs each field. For example, use the DHCP lease for a dynamic assignment and IPAM for a range's long-term responsible department.
Discovery results have limits and depend on when they were collected. Absence from ARP does not prove a device is absent, and an old DNS record does not prove current use. Synchronization jobs should record sources, collection times, and conflict rules. Queuing a discrepancy for review is safer than automatically deleting a record. Require an approver and change number for prefix creation, allocation, and reclamation so every state change has an attributable reason.
Sources for this section IETF RFC 4632 · Microsoft IP Address Management
What to look for The left shows the approved address plan in IPAM. The middle shows observed state collected from DHCP, DNS, ARP, MAC tables, cloud systems, and the CMDB. On the right, comparing the two reveals duplicate addresses, stale records, and changes that depart from the plan. The sequence below follows the management process from change request through approval, implementation, observation, and audit.
↔ Scroll horizontally to explore the diagram.
Before approving a range, check overlap, route summaries, and room to grow↑
Scenario: A new cloud environment is proposed to use 10.0.0.0/16, but part of an existing branch VPN already uses that range.
- Collect every prefix used internally, at branches, for remote access, by partners, and in clouds.
- Distinguish identical prefixes from cases where one contains another.
- Choose a different cloud prefix after comparing change cost, future summaries, and room to grow.
- Review the VPC, subnet, routes, security policies, and DNS as one change.
- Record the allocation rationale and owner in IPAM, and test routes in both directions before connecting.
Run three tests for every candidate prefix. Compare it with the enterprise prefix inventory for overlap; check alignment within site and region summaries; and check contiguous space for the expected subnets and growth. Include cloud minimum and maximum prefix limits, reserved addresses, and connection methods. Enough addresses alone do not make a good choice for routes or operational boundaries, so compare all three criteria in one table.
After deployment, automatically compare the plan in IPAM with observations from cloud route tables, on-premises routers, DHCP, and DNS. Before opening a new connection, test route lookups in both directions and representative service flows. If NAT is involved, record the original and translated addresses. Review unused reservations periodically, either releasing them or updating the reason for retaining them. An address plan is operational data to keep validating as connections and organizations change, not a one-time diagram.
The deliverable is not just an address table: it is the rationale for each prefix decision and a list of dependent systems. These records remove guesswork during expansion and help locate where an incorrect route, DHCP pool, or firewall object departs from the design during an incident.
Sources for this section IETF RFC 4632 · IETF RFC 3021 · Microsoft IP Address Management
FAQ↑
Should a company use only 10.0.0.0/8 for private addresses?
Can we leave overlapping addresses in place if we use NAT?
Can IPAM immediately mark discovered addresses as confirmed to be in use?
Glossary↑
Sources and verification
- IETF RFC 1918 — IPv4 private address space and design considerations
- IETF RFC 4632 — Classless prefixes and route aggregation
- IETF RFC 4193 — IPv6 Unique Local Address
- IETF RFC 3021 — IPv4 point-to-point /31 addressing
- IETF RFC 2131 — DHCP dynamic allocation and manual allocation
- Microsoft IP Address Management — Provides address-space planning, deployment, management, and auditing as one implementation of IPAM
The address hierarchy and the proportion of address space held in reserve depend on the organization's size, connectivity, and operational tools. No particular octet convention or fixed percentage is presented as a universal standard.