Traffic between SaaS and PaaS Services that reside in separate Regions within Oracle Cloud Infrastructure (OCI) regions already take advantage of the OCI backbone to ensure that traffic is not routed via the Public Internet. Benefits using the OCI Backbone are encryption by default and consistent, reliable performance for data that is traversing between OCI Regions.
OCI-Classic Regions (1st Generation Datacentre) and OCI Regions (2nd Generation Datacentre) currently coexist. PaaS and SaaS Services are actively being operated across both OCI and OCI-C Regions. This leads to the requirement for certain services to route traffic across region boundaries from OCI-C to OCI and vice versa. Careful planning and placement of these services can avoid this traffic to be sent across the Public Internet and instead use internal OCI Backbone.
Traversing traffic from OCI Regions to OCI-Classic Regions is only configured within geographical area, e.g. EMEA. Not all OCI-Classic Regions are supported to connect in this way. The following table shows the current connectivity – subject to change – the latest routes are advertised here: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectpublicpeeringaddressranges.htm
Geography |
OCI Region |
OCI-Classic Region |
Americas |
Canada Southeast (Toronto) |
Ashburn-Classic |
Canada Southeast (Montreal) |
Chicago-Classic |
|
US East (Ashburn) |
||
US West (Phoenix) |
||
US West (San Jose) |
||
Sao Paulo-Classic |
Brazil East (Sao Paulo) |
|
Asia-Pacific (APAC) |
Australia East (Sydney) |
Sydney-Classic |
Australia Southeast (Melbourne) |
||
India West (Mumbai) |
||
India South (Hyderabad) |
||
Japan East (Tokyo) |
||
Japan Central (Osaka) |
||
South Korea Central (Seoul) |
||
South Korea North (Chuncheon) |
||
Europe, Middle East, Africa (EMEA) |
Netherlands Northwest (Amsterdam) |
Amsterdam-Classic |
Germany Central (Frankfurt) |
Slough-Classic |
|
Switzerland North (Zurich) |
||
UK South (London) |
|
|
Saudi Arabia West (Jeddah) |
Traffic will traverse to the Public Internet and is potentially not encrypted when traffic is routed outside these routes. For example, traffic from Sydney-Classic will traverse the public internet when accessing a service in US East (Ashburn).
In this example Oracle EPM Cloud has been provisioned in the OCI-Classic Sydney Region and Oracle Integration Cloud is running out of the OCI Australia East (Sydney) Region. Since the Public Routes between these Region are automatically advertised the traffic will run via the Oracle Backbone.
If Oracle Integration Cloud would be provisioned in the OCI Region US East (Ashburn) the traffic would be routed via the public internet.
Note that this approach is not using Remote VCN Peering as described here: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/remoteVCNpeering.htm
Traffic is transparently routed via the OCI Backbone based on the advertised routes that are also used for Public Peering as listed here: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectpublicpeeringaddressranges.htm
There are also additional options available for Private Routes between OCI-C and OCI specifically when using FastConnect with Private Peering. This works similar to the OCI VCN to OCI-C IP Network connections that are outlined here: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Concepts/classicwithoraclenetwork.htm#Connection_Over_Oracle_Network
Asia-Pacific (APAC) |
Australia East (Sydney) |
Sydney-Classic |
Americas |
US East (Ashburn) |
Ashburn-Classic |
Europe, Middle East, Africa (EMEA) |
UK South (London) |
Slough-Classic |
Remote VCN Peering
https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/remoteVCNpeering.htm
Latest FastConnect Public Peering Advertised Routes
Previous Post