Managing Overlapping IPs in NetBox with VRFs

The Problem: The Duplicate IP Wall

Network engineers often hit a wall when managing mergers, acquisitions, or multi-tenant environments. You might have two different customers or internal departments both using 10.0.0.0/24. In a traditional spreadsheet or a basic IPAM tool, this is a nightmare—you either create confusing naming conventions or you simply cannot enter the data because the system flags it as a duplicate.

The takeaway: To handle overlapping address space without losing data integrity, you must move away from a global IP pool and implement Virtual Routing and Forwarding containers within NetBox.

How NetBox Isolates IP Space

In NetBox, a VRF acts as a logical boundary. Instead of every IP address and prefix existing in a single global routing table, you assign them to a specific VRF. This tells NetBox that 192.168.1.1 in VRF_Customer_A is a completely different entity than 192.168.1.1 in VRF_Customer_B.

This hierarchy is critical because NetBox functions as a Source of Truth. It doesn't ping devices to see if they are alive; it records what should be there. By using VRFs, you ensure your documentation reflects the actual routing isolation configured on your hardware, preventing the overlapping address errors that typically block the creation of child IP addresses.

Practical Implementation: Segmenting Your Network

To implement this, you first define the VRF and then associate your Prefixes with it. Because NetBox uses a hierarchical model, any IP address created within a prefix automatically inherits that prefix's VRF.

Configuration Example

Assume you are managing two tenants. You should execute these steps in the NetBox UI or via the REST API:

1. Create VRFs: Create two VRF objects named Tenant_Alpha and Tenant_Beta.
2. Define Prefixes: Create a prefix 10.0.0.0/24 and assign it to Tenant_Alpha. Create a second prefix 10.0.0.0/24 and assign it to Tenant_Beta.
3. Assign IP Addresses: Within each prefix, create the IP 10.0.0.1.

Verification Check: Navigate to the IP Address list. You will see two entries for 10.0.0.1. Check the VRF column; if one says Tenant_Alpha and the other Tenant_Beta, the isolation is working correctly.

Automating Allocation via API

Manual entry is prone to error, especially when managing multiple VRFs. Using the REST API allows you to programmatically request the next available IP within a specific VRF context. This prevents engineers from accidentally assigning an IP to the global table when it belongs to a tenant.

# Example API request to find the next available IP in a specific prefix
# Run this from a management workstation with API token permissions
curl -X GET https://netbox.example.com/api/ipam/prefixes/{prefix_id}/available-ips/ -H Authorization: Token YOUR_API_TOKEN

Risk: If you omit the VRF association during an API POST request, NetBox may attempt to place the address in the Global table, which will trigger a 400 Bad Request error if that IP is already taken in any other VRF.

Trade-offs and Limitations

While VRFs solve the overlap problem, they introduce cognitive load. When searching for an IP address in the global search bar, you will see multiple results for the same address. Users must be trained to always check the VRF attribute before making configuration changes on a live router.

Additionally, remember that NetBox does not perform active discovery. If a technician manually changes an IP on a switch without updating NetBox, the VRF isolation in the UI will remain, but your actual traffic will fail. You must maintain a strict process where NetBox is updated before the device configuration is pushed.

Closing Action

Audit your current IPAM. If you have Duplicate or Reserved notes in your spreadsheets to handle overlapping ranges, migrate those ranges into NetBox VRFs. Start by defining your VRFs, then move your Prefixes into them, and finally assign your individual IP addresses to those prefixes to ensure a clean, hierarchical source of truth.