Support Overlapping Tenant IP Address Space Across VPCs

[benhuntley]

Priority

Low

Use case / problem

Cloud-parity expectation: customers — especially hybrid setups linking an on-prem DC to the AI factory over MPLS — want to bring their own IP space, which may overlap between tenants (e.g. two tenants both using 10.0.0.0/24). The pre-Initiative NICo IPAM model blocks overlapping IP within a site.

Raised by

Reliance (multi-tenant AI factory, hybrid/MPLS).

Current state / workaround

• NICo still enforces non-overlapping IP while the default-off implementation in Tenant-Managed Site Prefixes #3883 is built and qualified.
• Workaround: handle overlapping ranges outside NICo via NAT (firewall / edge / MPLS NAT).
• Distinct from BYOIP: announcing your own (non-overlapping) prefix via host→DPU BGP is already supported (BGP-Peering page); this request is specifically about overlapping address space.
• Technically, separate VRFs/L3 VNIs can carry overlapping prefixes as long as those VPCs never interconnect, but NICo's global overlap guard blocks that configuration until Tenant-Managed Site Prefixes #3883 is complete.

Ask

Support overlapping private address space across isolated tenant VPCs and document the supported boundaries and operator responsibilities.

Delivery plan

This partner request is delivered by #3883 and tracked separately from the Initiative's implementation Task hierarchy. This issue stays open and blocked by #3883 until the Initiative is complete, then closes as completed.

The #3883 MVP has a deliberate boundary:

• Two tenants may register and use the same RFC1918 IPv4 range in separate eligible FNN VPCs.
• Same-VPC overlap and any direct or sibling routing relationship that would import overlapping ranges are rejected. Non-overlapping VPC peering remains supported.
• Tenant prefixes are DatacenterOnly and east/west. Internet ingress and egress require operator-provided VRF-aware NAT or elastic-IP policy; public or north/south tenant-prefix announcement is not included.
• Duplicate addresses must remain isolated across allocation, deletion, lookup, PTR, PXE/cloud-init, DPU policy, and withdrawal.

Implementation tracking

• Core address, boot, and DNS safety: Make Core overlay address operations VPC-aware #3887, Determine the PXE and cloud-init identity contract for duplicate overlay addresses #3888, Make reverse DNS safe for duplicate overlay addresses #3889
• Atomic routing and peering admission plus database cutover: Enforce overlap eligibility and route-consumer safety atomically #3890, Install scoped prefix constraints while global exclusions remain #3891, Retire global prefix exclusions for eligible FNN VPCs #3892
• DPU rendering, readiness, and withdrawal: Compare all agent-rendered network inputs before skipping apply #3893, Apply dynamic tenant-root isolation and gate SitePrefix readiness on DPU application #3894, Drain VpcPrefix and NetworkSegment withdrawals through existing DPU acknowledgements #3895, Drain VPC peering withdrawals through existing DPU acknowledgements #3896
• Tenant-managed prefixes and exact allocation: Persist and reconcile SitePrefix resources in Core #3884, Add tenant-managed SitePrefix lifecycle APIs in Core #3885, Associate VpcPrefixes with exact SitePrefix parents and parent-scoped allocation #3886, Distinguish Tenant SitePrefixes from Allocation IP Blocks in REST #3897, Make Core SitePrefixes Authoritative for Linked REST IP Blocks #3898, Expose tenant-managed SitePrefix lifecycle through REST #3899, Support exact VpcPrefix leases from tenant SitePrefixes #3900, Add tenant SitePrefix and exact VpcPrefix workflows to nicocli #3901
• Operator tooling and authority terminology: Add admin CLI management for tenant SitePrefixes #4226, Use Operator-Managed SitePrefix Authority Terminology #4573
• Qualification and documentation: Qualify and gate tenant-managed SitePrefixes across Core, DPU, and REST #3902, Document tenant-managed SitePrefix architecture and operations #3903

#1074 tracks the broader FNN and Ethernet Virtualizer networking documentation request. It overlaps this issue's documentation needs but is not a duplicate of the feature request.

The ratified MVP requires no additional implementation Task for this request. If public prefixes or built-in Internet NAT or elastic-IP support becomes part of NICo instead of an operator integration, that should be planned separately; it is outside #3883's MVP.

[ajf]

Over to @deepak-poornachandra to understand & prioritize. cc @nick-vetro

[deepak-poornachandra]

@benhuntley - I agree we should add a targeted documentation clarification. NICo does not currently support overlapping tenant IP address space across VPCs within a site. BYOIP with non-overlapping prefixes is a separate supported pattern.

What we will do:

• document the current overlapping-IP limitation
• clarify the distinction between BYOIP and overlapping address space

[nvda-jake]

@deepak-poornachandra There is additional asks on overlapping IP space we are seeing from customers. There are a few reasons why we need to prioritize this ask.

• All CSP's allow customers to use the same IP space. The look and feel of a VPC in NICo should be the same and have the same functionality. Customers choose their own IP space and then if they need to peer another VPC they need to make sure those IP spaces don't overlap. A consumer of NICo should not have to worry about the underlying deployment!
• A tenant picks their own IP space as part of the NCP workflow and overlaps with an existing tenant
• A tenant knows another tenant's IP space is a potential security concern even if in a different VNI
• Deployment/documentation is easier for the NCP if IP space is set up on a per tenant level instead of at a NICo deployment level. E.g. every tenant is 192.168.0.0/16

There are other benefits that I'm not listing but this is an important ask.

[as3-rdnt]

NICo enforces non-overlapping IP today (guards in VPC peering / allocation); noted as unlikely to be lifted soon.

Is there any clarification on what is considered soon? Is this in the roadmap for any scheduled releases this year?

[ajf]

Moved from Evaluate to Closed as not planned; We will be focusing on IPv6 implementation where overlapping IP space is a non-issue.

[Seppun]

NICo will enable specifying the address range for a VPC without restrictions, including public IP space and RFC1918 space, with the following restrictions:

1. VPC peering between VPCs with overlapping ranges will not be supported and will be rejected by the VPC peering request API if the IPs overlap
2. A NICo operator must implement appropriate egress NAT and “elastic IP” support for ingress/egress to the appropriate VRF (VPC).