Repository navigation
Overlap in CIDR #376
Description
Describe the bug
There are some vnet's which got created with overlap CIDR ranges, and we can see both CIDRs are makred as associated as well.
To Reproduce
Steps to reproduce the behavior:
Not sure how to reproduce this as this is not permanent issue
Expected behavior
CIDRs shouldn't be overlapped atleast once those are associated to an existing vnets. Reservations shouldn;t evn provide those ranges
Screenshots
OVERLAP DETECTED:
VNet 1: ***
Address Spaces: 10.43.2.192/26
VNet 2: ***
Address Spaces: 10.43.2.192/28
Overlapping CIDRs:
- 10.43.2.192/26 <-> 10.43.2.192/28
Additional context
We have observed this behaviour for few vnets as mentioned above.
Activity
DCMattyG commentedon Feb 27, 2026
Hey amitjattan, acknowledging this issue. I'll look into this immediately, but just out of curiosity could these vNET CIDR's have been updated after creation/association?
Right now, we can associate Virtual Networks to a Block as long as they are non-overlapping, but since Azure IPAM sits outside of Azure, there is nothing stopping someone from updating or changing the Address Space of the Virtual Network after that happens, which could definitely lead to an overlap situation like you are seeing. I'm not saying that is what happened here, but was just wondering if you've already explored that as a possibility.
uk-sw commentedon Sep 26, 2026
The reproduction is probably not a single bug but a race in the reserve-then-create window. Azure IPAM hands out a reservation, something else creates a VNet directly in the portal or in Terraform without going through the reservation, and the second reservation is calculated against state that no longer reflects reality. That matches "not a permanent issue", which is the tell for a possible race condition.
Two things that narrow it down: check whether both VNets were created through IPAM reservations or whether one was created out of band, and check the gap between the reservation timestamp and the VNet creation timestamp. If any VNet in the estate can be created without a reservation, IPAM is a record rather than a gate.
Disclosure: I build nxip, a different IPAM, so treat that as a bias. The general lesson I would take regardless of tool: overlap has to be rejected at write time by the thing that owns the space, in one transaction. Anything that checks and then writes separately will eventually double-book.