Modeling Overlapping RFC1918 with NetBox VRFs Without Breaking IPAM

Two tenants both want 10.0.0.0/24 inside their MPLS edge. In a flat IPAM that is a conflict. In NetBox it is not, if you scope the prefixes and IP addresses to VRFs. The useful takeaway is to treat VRF as the isolation boundary for IPAM, not just a device label.

The problem with a flat IP space

Multi-tenant networks and service providers routinely reuse private RFC1918 space. The same 192.168.1.0/24 can exist in Customer A and Customer B, and it should be allowed to. A flat IPAM model that enforces global uniqueness forces artificial renumbering or manual workarounds.

Virtual Routing and Forwarding, VRF, is a routing concept that gives each routing table an independent view of addresses. NetBox mirrors that concept in IPAM. The IPAM model treats the Global routing table as the default VRF. Assigning a prefix or IP address to a specific VRF isolates it from the global scope and from other VRFs.

How NetBox scopes IPAM to VRFs

Under IPAM > VRFs you create a VRF object with a name, RD, and optionally a Tenancy. Prefixes and IP addresses each have a VRF field. When the field is empty the object lives in Global. When it is set to a VRF, uniqueness is enforced only within that VRF.

That means NetBox will allow the same prefix, e.g. 10.0.0.0/24, to exist in VRF CustomerA and VRF CustomerB. It will reject a second 10.0.0.0/24 inside the same VRF. The relationship between VRFs and Tenancies lets you group resources by organizational ownership, which helps with filtering and permissions.

Interfaces can be assigned to a VRF via the device context, so an IP address assigned to an interface inherits the VRF scope. Moving an IP or prefix from one VRF to another can break those associations, so treat VRF changes as a state-changing operation.

Worked example: overlapping prefix via the API

The REST API is the practical way to create VRFs and overlapping prefixes consistently, especially for IaC.

Create two VRFs. Run from any machine that can reach NetBox, with a token that has write permission to ipam.

curl -X POST "$NETBOX_URL/api/ipam/vrf/" \
  -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "CustomerA", "rd": "65000:100"}'

Repeat for CustomerB with a different RD, e.g. 65000:200. Expected check is a 201 Created response with the VRF ID in the body. Risk is creating duplicate VRF names if the call is not idempotent.

Create the same prefix in both VRFs.

curl -X POST "$NETBOX_URL/api/ipam/prefixes/" \
  -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prefix": "10.0.0.0/24", "vrf": $VRF_A_ID, "tenant": "$TENANT_A"}'

Use the VRF ID from the previous step and repeat with $VRF_B_ID. NetBox should accept both because the VRF differs. To verify the uniqueness constraint, attempt to create 10.0.0.0/24 a second time in the same VRF. You should receive a validation error.

A practical check is to list prefixes filtered by VRF:

curl -G "$NETBOX_URL/api/ipam/prefixes/" \
  --data-urlencode "vrf_id=$VRF_A_ID" \
  -H "Authorization: Token $NETBOX_TOKEN"

Confirm the prefix appears only under its VRF and that the same CIDR appears under the other VRF.

Trade-offs and limits

Overlapping addresses are only safe if VRF labels are strictly enforced in documentation and automation. Manual spreadsheets that ignore VRF will show duplicates and cause confusion.

Performance can vary when querying very large numbers of prefixes across hundreds of distinct VRFs. Filtering by VRF or Tenancy early reduces result sets.

Do not move an IP address or prefix between VRFs without checking existing device interface assignments. NetBox will allow the change, but the operational meaning changes.

Actionable close

Model each routing domain as a VRF in NetBox, scope prefixes and IPs to that VRF, and tie VRFs to Tenancies for ownership. Use the API to create VRFs and prefixes consistently, and verify uniqueness within a VRF and overlap across VRFs with filtered API queries. That gives you accurate IPAM for overlapping private space without artificial renumbering.