Start free trial

By Yair Knijn · February 23, 2025

Your two 10.0.0.0/8 networks will collide on day one of the acquisition. Nobody scoped the renumber.

The infrastructure director signs the integration plan because the diagram is clean: two campuses, one new MPLS link, a few firewall rules, traffic flows. The assumption baked in is that two private networks connect, because private networks always connect. They will not. Both sides built on 10.0.0.0/8, both carved a 10.10.0.0/16 for production, and the day the link comes up half the addresses on the combined network point at two different machines.

This is not bad luck. It is the predictable result of two organizations that never coordinated, each doing the only sensible thing on its own: grabbing the largest RFC 1918 block and never thinking about the other company that did the same.

Why every acquired network is built on the same 10.0.0.0/8

RFC 1918 hands out three private ranges, and 10.0.0.0/8 is the one everyone reaches for because it is the biggest. Sixteen million addresses, no registration, no coordination with anyone outside your walls. That last part is the whole problem. The standard works only because nobody talks to anybody: each enterprise numbers its own internet in isolation, and isolation is fine right up until two of those internets have to become one.

So when you acquire a company, the odds they also live in 10/8 are close to one. The question is never whether the ranges overlap. It is how deep the overlap runs and how many production hosts sit inside it.

What RFC 1918 actually says about merging private internets

The authors saw this coming in 1996. Section 4 of the RFC says plainly that a drawback of private address space is that it "may require renumbering when merging several private internets into a single private internet," and that "companies tend to merge." If both merging networks used uncoordinated private space, "some addresses within the combined private internet may not be unique. As a result, hosts with these addresses would need to be renumbered."

Read that as a warranty exclusion, not a footnote. The same document that let you skip address registration told you the bill comes due on merger day. Renumbering is the named, expected cost, and the one nobody scoped before signing.

NAT as a band-aid: the overlapping-CIDR tax that never goes away

The first instinct is NAT. Put twice-NAT between the sites, map one company's 10.10.0.0/16 into 100.64.0.0/16, and call it integrated. It works in the demo. Then it bleeds:

NAT does not remove the collision. It hides it behind a translation layer you now operate forever, converting a one-time renumber into a permanent tax that compounds with every acquisition after this one.

The pre-LOI overlap audit that turns a surprise into a line item

The renumber is unavoidable. What is avoidable is discovering it after close, when you own the cost and have no room left to negotiate price. Before the letter of intent, run an overlap audit against the target's real allocations: their authoritative ranges, what DHCP and DNS actually serve, and which production subnets sit inside CIDRs you already use. That turns "we'll figure out networking later" into a sized project with a host count, a sequence, and a number that belongs in the deal model.

Spot IPAM makes that number knowable before you sign. Import both sides as separate Environments, and the overlap report tells you which subnets collide, how many live hosts sit in each, and what has to be renumbered first. The acquisition still costs what it costs. At least the address bill stops being the part you found out about last. See what the overlap audit surfaces on the features page.