Start free trial

By Yair Knijn · February 4, 2025

The /24 two teams both think they own, until the routing loop hits production

The NetOps lead is the last human gate on subnet allocation, and that is exactly the problem. A request lands, they open the shared IPAM spreadsheet, scan for a row that says free, type a name next to 10.20.40.0/24, and reply approved. The wrong assumption is buried there: that reading a cell and writing a cell is one action. It is not. Between the read and the write, someone else can do the same thing, and the spreadsheet lets them.

That gap is where a single /24 gets handed to two teams in the same week. Nobody was careless; the tool just has no way to say "I'm already giving this away, wait."

How a "free" /24 gets carved twice in the same week

Two requests arrive Tuesday afternoon: a new app tier in the Amsterdam DC, a database cluster in Frankfurt. The lead approves the first and grabs the next clean block under 10.20.0.0/16. A teammate handling the second has had that file open since lunch, sees the row still marked free in their stale copy, and takes it too. The "last write wins" merge keeps one edit and drops the other, and both engineers walk away believing 10.20.40.0/24 is theirs. RFC 1918 hands you all of 10.0.0.0/8; the address space was never the constraint, the bookkeeping is.

Why duplicate subnets produce asymmetric routing, not a clean error

Here is the cruel part. Put the same IP on two hosts in one broadcast domain and the switch screams duplicate-address. A duplicate /24 in two data centers throws no such alarm. Both prefixes get announced into your IGP, OSPF or BGP picks whichever has the better metric for a given source, and traffic to that block leaves through one DC while the return path comes back through the other.

Asymmetric routing is not itself illegal, packets still move. The damage is downstream. Stateful firewalls and NAT devices see half the conversation and drop the flow as invalid. TCP, tracking sequence state strictly, sees connections that open and then hang. The result is intermittent timeouts that depend on which host pair is talking, the worst failure signature to debug.

The three-day trace: from user tickets to the second announcement

It starts as a help-desk theme, not an outage: "the app is slow," "sessions drop after a minute," "works from my desk, not the VPN." Day one goes to the app team, who find nothing wrong. Day two goes to packet captures showing SYNs with no matching ACKs and retransmits on flows that should be local. Day three someone pulls the routing table, sees the same prefix learned from two next-hops, and starts the archaeology: whose change, which ticket, which row. The fix takes minutes. The three days went to trusting the evidence over the system of record, which swore no duplicate could exist.

Atomic allocation: what a real IPAM does that a spreadsheet cannot

The whole class of incident dies if allocation is atomic: the system reserves a block and records the owner in one indivisible transaction, so a second request for the same space is refused the instant it is made, not found three days later in a capture. A spreadsheet cannot do this; a cell has no lock and no concept of "in flight." Enforced at the data layer:

Spot IPAM treats each customer Environment as a single authoritative allocator, so two parallel requests for the same range cannot both win and overlaps are caught before they reach a router. If your source of truth is a file two people can edit at once, that is the bug; see how atomic allocation closes it.