If you have organized your resources in multiple virtual cloud networks (VCNs) to meet your governance model and regional presence, connecting all those VCNs to your on-premises networks can be a real challenge. Until now, your only option was to have a FastConnect or IPSec connection terminate at each of your VCNs. However, this option means you incur costs for multiple FastConnect links, and you have the operational burden of provisioning a new FastConnect or IPSec connection for each new VCN you add.
We are excited to announce the availability of Oracle Cloud Infrastructure VCN Transit Routing, which now offers an alternative. This solution is based on a hub-and-spoke topology and enables the hub VCN to provide consolidated transit connectivity between an on-premises network and multiple spoke VCNs within the Oracle Cloud Infrastructure region. Only a single FastConnect or IPSec VPN (connected to hub VCN) is required for the on-premises network to communicate with all the spoke VCNs. This solution is based on our existing local VCN peering and dynamic routing gateway (DRG) offerings.
With this solution, you no longer need to attach a DRG to each of your VCNs to access your on-premises network. You attach only a single DRG to the hub VCN and allow resources in the spoke VCNs to share the (FastConnect or IPSec VPN) connectivity to the on-premises resources. At a high level, you do this by performing the following steps:
Establishing a peering relationship between each spoke VCN and the hub VCN
Associating route tables with the hub VCN's local peering gateways (LPG) and DRG
Setting up rules in those route tables to direct traffic from each LPG on the hub VCN to the DRG, and from the DRG to each LPG.
VCN transit routing offers customers many benefits:
Better network design: Simplified network management and fewer connections required to establish traffic flow between multiple VCNs and on-premises networks. The hub VCNs enables shared transit connectivity to remote networks and act as a central point of policy enforcement for all your traffic transiting in and out of the region.
Increased service velocity/Faster Time-to-Market: This solution supports Fastconnect and IPSec VPN connectivity requirements between VCNs and remote resources with minimal on-premises network changes. If you add a new VCN, it will now just take few minutes to set up local peering and routing to the hub VCN. This is a marked improvement to previous lead times of days/weeks waiting on corporate change management procedures for establishing Fastconnect or provisioning IPsec connections at on-premises edge routers.
Centralized control of route advertisements: This solution does not enable the traffic to flow between the on-premises network and the spoke VCNs by default
You may want to allow the spoke VCNs to access all or specific corporate network partitions (or subnets) in the customer premises. You control this with the route table associated with the LPG on the hub VCN. You can configure restrictive route rules that specify only the on-premises subnets that you want to make available to the spoke VCN. The routes advertised to the spoke VCN are those in that route table and the hub VCN's CIDR. This control enables isolated connectivity of spoke VCNs' resources to their on-premises counterparts.
Similarly, you may want to allow the on-premises network to access all or specific subnets in the spoke VCNs. You control this using the route table associated with the DRG on the hub VCN. You can configure restrictive route rules that specify only the spoke VCN subnets that you want to make available to the on-premises network. The BGP route advertisements to the on-premises network are those in that route table and the hub VCN's CIDR.
Cost savings: Significant TCO benefits based on centralized management of the private connectivity (Fast Connect/VPN links) and routing to corporate resources in customer premises.
Streamlined operations: This solution enables the service provider model where the hub VCN provides the transit connectivity service to the spoke VCNs. The governance boundaries of these hub VCNs may be different from those of the spoke VCNs and hence may be managed by separate compartments/tenancies. In some cases, the hub and spoke VCNs are in the same company, and the central IT team’s hub VCN provides transit service to spoke VCNs managed by LOBs (Lines of Business). In other cases, the hub and spoke VCNs are in different companies, and one company provides transit service to others.
In my next post, I will walk you through a VCN Transit Routing scenario where two spoke VCNs are enabled to access remote on-premises networks by using a single IPSec connection attached to the hub VCN. Stay tuned...