Overlapping Address Space and Spoke Isolation in a Three-VCN Landing Zone

The obvious conflict is not the subsidiaries - it is the hub. On-premises advertises 10.0.0.0/8, which contains 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16 and 10.3.0.0/16. From the on-premises perspective every OCI VCN is inside a locally known prefix. Unless the on-premises routers carry more-specific routes, return traffic for 10.1.x.x will be sent toward the on-premises core rather than the DRG, and traffic black-holes or loops. That failure is intermittent and prefix-dependent, which makes it the worst kind to debug during a cutover.

Options, in order of preference:

1. Re-address the OCI landing zone into space that neither on-premises nor either subsidiary uses - a clean block from 172.16.0.0/12, or 100.64.0.0/10 if you want a range no acquisition is likely to collide with. The landing zone is mostly empty, so this is a DNS and route-table exercise, not an application project. Do it now; the cost rises linearly with every workload placed on it.
2. Re-address the 10.10.128.0/17 subsidiary in the same change as its own migration. Renumbering during a move costs a fraction of renumbering afterwards.
3. For 10.10.0.0/16, if it must stay, use a transit VCN with NAT and route-based translation. Accept that double NAT breaks application-embedded IPs, source-IP-based ACLs, TLS SNI assumptions and some vendor support statements.

Recommendation: option 1 immediately, option 2 opportunistically, option 3 only for a residual application with a documented expiry date.

Do not use a single shared DRG route table for all attachments. With DRG route tables you can give each spoke attachment its own import distribution containing only the hub and on-premises prefixes, so no spoke is ever handed a route to another spoke. That gives you a hard, configuration-level guarantee of isolation that survives someone adding a VCN later.

Inspection needs the traffic to physically traverse the firewall, and a DRG does not inspect. Two viable patterns:

• Hub VCN hosting OCI Network Firewall (or a marketplace NGFW behind a private NLB) with a policy for spoke-to-spoke and spoke-to-internet. Spoke route tables send inter-spoke and default traffic to the hub via the DRG attachment, and the hub returns via the DRG.
• Transit VCN dedicated to inspection, with the hub and spokes as spokes of the transit VCN. Cleaner separation, one more hop, and one more place for a route table to be wrong.

Asymmetric routing is the classic failure here: the outbound packet goes spoke, DRG, hub, firewall; the return packet goes hub, DRG, straight to the spoke, bypassing the firewall and getting dropped by stateful inspection. Prevent it by making the firewall the only path in both directions - return traffic must also be routed to the firewall's private IP, not directly to the DRG, and the firewall must be configured to preserve and re-inject source and destination correctly. Verify with flow logs on every attachment, not with a single ping. Also log at the NSG and firewall layers separately; you will need both when an application owner reports 'it works from the hub but not from the spoke'.

A single FastConnect is a single point of failure across three independent layers: the cross-connect at the provider, the physical port, and the provider's path to the OCI edge. The higher FastConnect availability tier requires two virtual circuits on diverse paths, or a FastConnect plus an IPSec VPN backup running BGP. Buying one circuit and asserting 99.95% is asserting something the architecture does not provide.

But the requirement is 99.95% for order intake with a 4-hour RTO, not 99.95% for every packet between the data centre and OCI. That distinction drives the answer:

• Localise order intake in the region: load balancer, application tier and database all in OCI, so a connectivity outage degrades administration and batch, not customer ordering. This is the cheapest availability you can buy and it is an architecture decision, not a network purchase.
• Add two IPSec VPN tunnels over separate internet providers as a BGP-backed backup to the FastConnect. Bandwidth is far lower, which is acceptable for control traffic and unacceptable for 22 TB bulk transfer - so schedule bulk work to avoid depending on it.
• Model the actual exposure: if order intake is localised and only batch/RFC traffic rides the circuit, a single circuit plus VPN backup is proportionate. Buy the second FastConnect when a workload that cannot be localised depends on it.

Do not spend 18 months of network budget on a second circuit to protect traffic you could have kept in the region. Revisit if the 4-hour RTO turns out to depend on on-premises systems.