Overlapping Address Space and a 120 TB First Sync: Connecting a Two-Site Enterprise to OCI

This is the decision that constrains everything downstream, so evaluate it on total cost of change rather than on elegance.

Option A - re-IP the OCI production VCN. Choose a range from 10.0.0.0/8 that is genuinely unused (that is the point: the on-prem plan is mostly empty, so the collision is with one legacy block, not with the whole space). Cheapest option in infrastructure and the only one with no ongoing operational tax. Cost is configuration churn during migration.

Option B - re-IP the on-premises warehouse system. Removes the collision permanently and simplifies the long-term estate, but touches a legacy system with hard-coded addresses, unowned source code and a live logistics operation. Highest risk, longest lead time - usually correct eventually, but not on a three-week critical path.

Option C - NAT in the path. Put a third-party firewall or NVA in the hub VCN to translate between the overlapping ranges. Technically workable, but it introduces a stateful chokepoint for 4 Gbps of migration traffic, breaks end-to-end source-IP visibility for logs and partner whitelists, and adds a component that must be HA and maintained forever. OCI's DRG does not provide overlapping-CIDR translation natively, so this always means an NVA.

Recommendation: Option A now, Option B as a funded follow-on for the warehouse system. Use a hub-and-spoke design with a dedicated hub VCN for the NVA/firewall and connectivity, and allocate VCN ranges from a documented IPAM plan so the next collision is prevented rather than resolved.

To the application teams: the recommendation is that hard-coded addresses must go. Publish a DNS-based contract - connect strings and endpoints by name - and treat any remaining literal IP as a tracked defect with an owner. Otherwise every future re-IP carries the same risk you are absorbing today.

Single DRG, version 2, as the regional hub. Use one DRG per region attached to the on-premises connection and to all VCNs, rather than chaining VCN peerings. DRG v2 is the right choice here because it supports transit routing between attachments and allows separate DRG route tables per attachment - with v1 and its single route table, the non-production VCN would be able to route to on-premises production ranges with no way to prevent it. That isolation is a requirement, not a refinement.

Topology:

• Hub VCN holding the firewall/NVA and the DRG attachment; production, non-prod and shared-services VCNs attach to the DRG (or to the hub via LPG, depending on how much inspection you need).
• DRG route tables: one per VCN attachment, distributing only the routes that VCN should see. Non-prod gets a table without production or on-premises production prefixes. This is where segmentation actually happens.
• Security zones: NSGs and security lists still apply at the VCN layer; route tables decide reachability, security rules decide permission. Do not rely on routing alone for security.

On-premises connection: FastConnect with two virtual circuits - one per data centre, diverse paths - into the same DRG, with BGP over private peering. The two circuits provide the redundancy; a single circuit plus VPN backup is a reasonable cost compromise but gives you a weaker SLA and worse latency under failure. Given 4 Gbps peak, provision private peering at 10 Gbps rather than 2×1 Gbps, since the peak is the sizing driver and circuit upgrades have lead time.

DR region: a second DRG in the DR region with its own FastConnect attachment or, if the on-premises sites do not need to reach DR directly, remote peering between the two DRGs. Replication traffic between regions should not traverse on-premises. Keep the DR VCN address plan non-overlapping with production so the same route-table logic applies.

Do the arithmetic before agreeing to anything, and present the assumptions explicitly because this is where projects get into trouble.

The maths. Three weeks is 21 days, or about 1,814,400 seconds. 120 TB is roughly 960 Tb (120,000 GB × 8). Required sustained throughput = 960 Tb ÷ 1,814,400 s ≈ 0.53 Gbps of goodput. Applying realistic overheads - TCP efficiency, encryption, and the fact that the 4 Gbps is a peak shared with replication - plan for roughly 30-40% efficiency against the provisioned capacity. A 1 Gbps circuit is therefore marginal, a 10 Gbps FastConnect is comfortable, and a 2×1 Gbps pair is not, because replication traffic will contend with it at exactly the wrong moment.

Note also that the seed and the ongoing replication compete for the same path. Either schedule the seed outside the replication peak, or size the circuit so both fit concurrently - otherwise the 21-day estimate silently becomes six weeks.

Alternatives if the link cannot carry it:

• OCI Data Transfer Appliance for the bulk cold data, with the network carrying only the delta. This is often the right answer for 120 TB when lead time allows, and it removes the contention problem entirely.
• Data Transfer Service / station-style physical transfer where the region and volume support it.
• Compress and deduplicate before transfer, and stage large archives into Object Storage using parallel multipart uploads with large part sizes rather than many small files. Object counts, not just bytes, frequently drive the real transfer time.
• Re-sequencing the migration so that the largest dataset moves first while replication volume is still low.

Recommendation: provision FastConnect at 10 Gbps, run a measured transfer test with representative object sizes in week one, and hold the appliance as the contingency with its lead time checked now, not in week three.