· Yair Knijn
Finding CIDR conflicts before the peering ships
The peering ships on Friday afternoon. On Saturday morning, the on-call engineer gets a call that the warehouse in Rotterdam is offline. The packets are reaching Azure. The packets are not coming back. The reason is a CIDR overlap: the new VNet peered into the hub is using 10.42.0.0/16, and so is a network another team stood up in a different subscription eight months ago, and the warehouse's on-prem range is 10.42.0.0/24, which means the routing tables have been quietly disagreeing for about twelve hours.
This is the failure mode a spreadsheet does not catch. It is also the failure mode a process that relies on people remembering to update a process does not catch. It is the failure mode that an inventory of address space, checked at allocation time, would have caught before the peering shipped.
Why the obvious fix does not work
The obvious fix is to install an agent on every network component and have it report its address space. The reason this does not work in practice is that the address space you care about is not the address space Azure sees. The address space you care about includes the on-prem range the warehouse uses, the range the old DR site uses, the range the M&A target's network is going to use, and the block your CISO carved out six years ago for a project that has been "temporarily" off-limits ever since. None of those live in Azure. None of them are reachable from an agent. The agent reports the VNet's address prefix, which is the thing you already know.
The other obvious fix is to give an IPAM tool Owner rights on every subscription and let it query anything. That works, until an auditor asks why a third-party SaaS has Owner on your production estate, and the answer does not satisfy anyone in the room.
What a conflict check actually requires
Three things. The full address space across the tenants you care about, including the on-prem ranges and the reserved blocks that have nothing to do with cloud. A way to express a proposed allocation and have it checked against that space before the allocation is created. And a record of the check, so the question "did anyone know this overlap existed on the day the peering was approved" has an answer.
Without the on-prem ranges, the check is incomplete by definition. Without the reserved blocks, the check will pass for an allocation that an architect has already promised to someone else. Without the record, the check is an opinion.
Read-only is a feature, not a limitation
A collector that needs Owner rights is a collector that can break the estate it is reading. A collector that needs a custom role is a collector that an auditor will spend a meeting on. A service principal with Reader on the management group, scoped to network resources, is enough to enumerate every VNet, every peering, every address prefix, and every private endpoint in a tenant, and it does not require a justification to deploy.
Read-only is also the right level for what the check needs. The check is a query, not a write. The query runs in the IPAM system, against the data the collector has assembled, and the answer is yes, this allocation overlaps something, here is what it overlaps, and here is the work item. The write that creates the VNet is still the engineer's; the platform is not in the deployment path.
The A.8.20 angle
ISO 27001:2022 Annex A control 8.20 is "networks security". Among other things, it asks for documented and agreed network rules, address space, and the controls on them. The output of an IPAM system is, more or less, the register that 8.20 wants: every range, who owns it, what it is for, and the approvals behind it. The register is what you hand the auditor when they ask how you know the address space on the day of the incident matched the address space on the day of the design.
A spreadsheet is not the register, because a spreadsheet does not record who approved what when, and it does not survive a turnover. A tool that records an approval and binds it to the allocation is the register.
How Spot IPAM detects conflicts
Spot IPAM assembles the address space across the Azure tenants it is pointed at, using a read-only service principal with Reader rights on network resources. It does not request Owner. It enumerates VNets, peerings, address prefixes, and private endpoints, and adds the on-prem ranges and reserved blocks you load into it directly, because those are not in Azure and never will be.
When a new allocation is proposed, Spot IPAM checks it against the assembled space, across tenants, and against peerings and on-prem ranges, before the allocation is approved. The check produces a conflict report rather than a hard block, because the engineering call is the engineer's; the platform's job is to make the conflict visible. CIDR allocation is governed by a workflow with approvals, and the approval record is bound to the allocation.
DNS reconciliation runs against Azure Private DNS and Cloudflare, so a name that resolves to a new address does not silently point at a range that is about to be retired. For ISO 27001 A.8.20, the address-space register is exportable, with the allocation owner, the approver, and the date the range went into use. The same register drives the API, so Terraform, Bicep, and Pulumi can call into the same workflow that the GUI uses, with the same checks applied.
What Spot IPAM does not do is approve an allocation. The platform surfaces the conflict, the approver signs the approval, and the audit trail carries both. The judgement is the operator's; the evidence is the platform's.