Interconnect for Google Cloud
This topic describes how to set up Oracle Interconnect for Google Cloud.
Oracle Interconnect for Google Cloud lets you create a cross-cloud connection between Oracle Cloud Infrastructure and Google Cloud Platform (GCP) in certain regions. This connection lets you set up cloud-to-cloud workloads without the traffic between the clouds going over the internet. This topic describes how to set up virtual networking infrastructure resources to enable this deployment.
Highlights
- You can connect an Oracle Cloud Infrastructure (OCI) virtual cloud network (VCN) with a GCP virtual private cloud (VPC) and run a cloud-to-cloud workload. In the typical use case, you might deploy an Oracle Database on OCI, and deploy a custom application in GCP.
- The two virtual networks must belong to the same company or organization and not have overlapping CIDRs. Oracle Interconnect for Google Cloud requires you to create a Partner Interconnect circuit and an OCI FastConnect virtual circuit.
Availability
Oracle Interconnect for Google Cloud is only available in the paired regions depicted in the following maps and tables. For more information on GCP region locations see the Colocation Facilities Locations table in the GCP documentation.
The following image shows regions with Oracle Interconnect for Google Cloud, showing all commercial OCI regions and noting regions with interconnect to both Azure and GCP. Participating GCP regions are also listed in the following tables.
US Government Cloud regions with Oracle Interconnect for Google Cloud are listed in the US Government Cloud documentation,
Asia Pacific
| OCI region - key | Google Cloud region
|
|---|---|
|
Australia East (Sydney) / ap-sydney-1 - SYD |
Sydney (australia-southeast1) |
|
Australia Southeast (Melbourne) / ap-melbourne-1 - MEL |
Melbourne (australia-southeast2) |
|
India West (Mumbai) / ap-mumbai-1 - BOM |
Mumbai (asia-south1) |
|
Japan East (Tokyo) / ap-tokyo-1 - NRT |
Tokyo (asia-northeast1) |
| Singapore (Singapore) / ap-singapore-1 - SIN |
Singapore (asia-southeast1) |
Europe, Middle East, Africa (EMEA)
| OCI region - key | Google Cloud region
|
|---|---|
|
Germany Central (Frankfurt) / eu-frankfurt-1 - FRA |
Frankfurt (europe-west3) |
|
Spain Central (Madrid) / eu-madrid-1 - MAD |
Madrid (europe-southwest1) |
|
UK South (London) / uk-london-1 - LHR |
London (europe-west2) |
|
Switzerland North (Zurich) / eu-zurich-1 - ZRH |
Zurich (europe-west6) |
Latin America (LATAM)
| OCI region - key | Google Cloud region
|
|---|---|
|
Brazil East (Sao Paulo) /sa-saopaulo-1 - GRU |
São Paulo (southamerica-east1) |
North America (NA)
| OCI location - key | Google Cloud region
|
|---|---|
|
Canada Southeast (Montreal) (ca-montreal-1) - YUL |
Montréal (northamerica-northeast1) |
|
Canada Southeast (Toronto) (ca-toronto-1) - YYZ |
Toronto (northamerica-northeast2) |
|
US East (Ashburn) (us-ashburn-1) - IAD |
N. Virginia (us-east4) |
Overview of Supported Traffic
Here are more details about the supported types of traffic.
VCN-to-VPC Connection: Extension from One Cloud to Another
You can connect a VCN and VPC so that traffic that uses private IP addresses goes over a cloud-to-cloud connection.
For example, the following diagram shows a VCN connected to a VCP. Resources in the VPC are running an application that accesses an Oracle database that runs on Database service resources in the VCN. The traffic between the application and database uses a logical circuit that runs on the cloud-to-cloud connection between GCP and OCI.
To enable the connection between the VPC and VCN, you set up a GCP VLAN attachment and an OCI FastConnect virtual circuit. The connection doesn't have built-in redundancy, which means you need to set up a second Oracle Interconnect for Google Cloud connection to enable a highly available, resilient network design.
For detailed instructions, see Setting up a Connection.
Peered VCNs
The connection traffic can flow from the VPC to one or more peered VCNs in the same OCI region or in other OCI regions.
Types of Traffic Not Supported by the Connection
This connection doesn't enable traffic between an on-premises network through OCI to the VPC, or from an on-premises network through GCP to OCI.
Important Implications of Connecting Clouds
This section summarizes some access control, security, and performance implications of Oracle Interconnect for Google Cloud. In general, you can control access and traffic by using IAM policies, route tables in the VCN, and security rules in the VCN.
The sections that follow discuss implications from the perspective of a VCN. Similar implications affect a VPC. As with a VCN, you can use GCP resources such as route tables and network security groups to secure a VPC.
Controlling the Establishment of a Connection
With Oracle Cloud Infrastructure IAM policies, you can control:
- Who has the authority to create a FastConnect virtual circuit (see Setting up a Connection). Deletion of the relevant IAM policy doesn't affect any existing connections to a VPC, only the ability for a future connection to be created.
- Who can manage route tables, network security groups, and security lists.
Controlling Traffic Flow Over the Connection
Even if a connection has been established between VCN and VPC, you can control the packet flow over the connection with VCN route tables. For example, you can restrict traffic to only specific subnets in the VPC.
Without terminating the connection, you can stop traffic flow to the VPC by removing route rules that direct traffic from the VCN to the VPC. You can also effectively stop the traffic by removing any security rules that enable VPC ingress or egress traffic. This doesn't stop traffic flowing over the connection, but stops it at the VNIC level.
Controlling the Specific Types of Traffic Allowed
Ensure that all outbound and inbound traffic with the VPC is intended or expected and defined. Implement GCP security and Oracle security rules that explicitly state the types of traffic one cloud can send to the other and accept from the other.
Oracle Cloud Infrastructure instances running Linux or Windows platform images also have firewall rules that control access to the instance. When troubleshooting access to an instance, ensure that the following items are set correctly: the network security groups that the instance is in, the security lists associated with the instance's subnet, and the instance's firewall rules.
If an instance is running Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7, or Oracle Linux Cloud Developer 8, you need to use firewalld to interact with the iptables rules. For reference, here are commands for opening a port (1521 in this example):
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reloadFor instances with an iSCSI boot volume, the preceding --reload command can cause problems. For details and a workaround, see Instances experience system hang after running firewall-cmd --reload.
In addition to using security rules and firewalls, evaluate other OS-based configuration on the instances in the VCN. There could be default configurations that don't apply to the VCN's CIDR, but inadvertently apply to the VPC's CIDR.
Using Default Security List Rules with the VCN
If the VCN's subnets use the default security list with the default rules, two rules in that list allow ingress traffic from anywhere ( 0.0.0.0/0, and thus the VPC):
- Stateful ingress rule that allows traffic on TCP port 22 (SSH) traffic from 0.0.0.0/0 and any source port
- Stateful ingress rule that allows traffic on ICMP type 3, code 4 traffic from 0.0.0.0/0 and any source port
Evaluate these rules and whether you want to keep or update them. As stated earlier, ensure that all allowed inbound or outbound traffic is intended or expected and defined.
Preparing for Performance Impact and Security Risks
In general, prepare the VCN for the ways it could be affected by the VPC. For example, the load on the VCN or its instances could increase. Or the VCN could experience a malicious attack directly from or by way of the VPC.
Regarding performance: If the VCN is providing a service to the VPC, be prepared to scale up service to accommodate the demands of the VPC. This might mean being prepared to create more instances as necessary. Or if you're concerned about high levels of network traffic coming to the VCN, consider using stateless security rules to limit the level of connection tracking the VCN must perform. Stateless security rules can also help slow the impact of a denial-of-service (DoS) attack.
Regarding security risks: If the VPC is connected to the internet, the VCN can be exposed to bounce attacks. A bounce attack involves a malicious host on the internet sending traffic to the VCN that appears to be coming from the VPC. To guard against this, as mentioned earlier, use security rules to carefully limit the inbound traffic from the VPC to expected and defined traffic.
Setting up a Connection
This section describes how to set up Oracle Interconnect for Google Cloud (for background, see Overview of Supported Traffic).
The Google Cloud Platform side of this connection uses what Google refers to as "Partner Interconnect." The OCI side uses the FastConnect Oracle Partner method.
Prerequisites: Resources You Need
You must already have:
- A GCP VPC with subnets, a Google Cloud Router, and service perimeters
- An Oracle Cloud Infrastructure VCN with subnets and an attached dynamic routing gateway (DRG). Remember to attach the DRG to the VCN after you create it. If you already have Site-to-Site VPN or FastConnect between an on-premises network and VCN, then the VCN already has an attached DRG. You use that same DRG here when setting up the connection to GCP.
- IAM permissions to configure the resources needed for the required OCI components.
- A valid subscription in both OCI and GCP for the regions you want to connect
As a reminder, here is a table that lists the comparable networking components involved in each side of the connection.
| Component | GCP | Oracle Cloud Infrastructure |
|---|---|---|
| Virtual network | Virtual Private Cloud (VPC) | VCN |
| Virtual circuit | VLAN attachment | FastConnect private virtual circuit |
| Gateway | Google Cloud Router | dynamic routing gateway (DRG) |
| Routing | route tables | route tables |
| Security rules | Service Perimeter | network security groups (NSGs) or security lists |
Prerequisites: BGP Information You Need
The connection between the VPC and VCN uses BGP dynamic routing. When you set up the Oracle virtual circuit, you provide the BGP IP addresses used for the two redundant BGP sessions between Oracle and GCP:
- A primary pair of BGP addresses (one IP address for the Oracle side, one IP address for the GCP side)
- A separate, secondary pair of BGP addresses (one IP address for the Oracle side, one IP address for the GCP side)
For each pair, you must provide a separate block of addresses with a subnet mask from /28 to /31.
The second and third addresses in each address block are used for the BGP IP address pair.
- The second address in the block is for the Oracle side of the BGP session
- The third address in the block is for the GCP side of the BGP session
The first and last addresses in the block are used for other internal purposes. For example, if the CIDR is 10.0.0.20/30, then the addresses in the block are:
- 10.0.0.20
- 10.0.0.21: Use this for the Oracle side (in the Oracle Console, enter the address as 10.0.0.21/30)
- 10.0.0.22: Use this for the GCP side (in the Oracle Console, enter the address as 10.0.0.22/30, and notice that this address is referred to as the "Customer" side in the Console)
- 10.0.0.23
Remember that you must also provide a second block with the same size for the secondary BGP addresses. For example: 10.0.0.24/30. In this case, 10.0.0.25 is for the Oracle side, and 10.0.0.26 is for the GCP side. In the Oracle Console, you must enter these as 10.0.0.25/30 and 10.0.0.26/30.
Prerequisites: Required IAM Policy
You must already have the necessary GCP access and Oracle Cloud Infrastructure IAM access to create and work with the relevant GCP and Oracle networking resources. If your user account is in the Administrators group, you probably have the required authority, otherwise a policy similar to this one covers all the Networking resources:
Allow group NetworkAdmins to manage virtual-network-family in tenancyTo only create and manage a virtual circuit, you must have a policy such as this:
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancyFor more information, see IAM Policies for Networking.
Overall Process
The following diagram shows the overall process of connecting a VPC and a VCN.
The first task is to decide what traffic needs to flow between the relevant subnets within the VPC and VCN, and then configure the necessary service perimeters and VCN security rules. The general types of rules to add are:
- Ingress rules for the types of traffic you want to allow from the other cloud's relevant subnets.
- Egress rules to allow outgoing traffic to the other cloud. If the VCN's subnet already has a broad egress rule for all types of protocols to all destinations (0.0.0.0/0), then you don't need to add a special one for the traffic to the VPC. The VCN's default security list includes such a broad default egress rule.
Here are recommended types of traffic to allow between the VPC and VCN:
- Ping traffic in both directions for testing the connection from each side
- SSH (TCP port 22)
- Client connections to an Oracle database (SQL*NET on TCP port 1521)
Only allow traffic to and from specific address ranges of interest (for example, the other cloud's relevant subnets).
For the VPC: Decide which subnets in the VPC need to communicate with the VCN. Then configure the service perimeters for those subnets to allow traffic.
For the VCN:
The following procedure uses security lists, but you could instead implement the security rules in one or more network security groups and then place the VCN's relevant resources in NSGs.
- Decide which subnets in the VCN need to communicate with the VPC.
-
Update the security list for each of those subnets to include rules to allow egress or ingress traffic with the VPC's CIDR block or a subnet of the VPC:
- In the Console, while viewing the VCN you're interested in, select Security Lists.
- Select the security list you're interested in.
-
Select Edit All Rules and create one or more rules, each for the specific type of traffic you want to allow. See the example rules that follow.
-
Select Save Security List Rules at the bottom of the dialog box when finished.
For more information about setting up security rules, see Security Rules.
The following egress security rule lets an instance create a ping request to a host outside the VCN (echo request ICMP type 8). This is a stateful rule that automatically allows the response. No separate ingress rule for echo reply ICMP type 0 is required.
The following ingress security rule lets an instance receive a ping request from a host in the VPC (echo request ICMP type 8). This is a stateful rule that automatically allows the response. No separate egress rule for echo reply ICMP type 0 is required.
The following ingress security rule lets an instance receive an SSH connection (on TCP port 22) from a host in the VPC.
The following ingress security rule allows SQL connections (on TCP port 1521) from hosts in the VPC.
Create a pair of Partner Interconnect connections to Oracle Cloud Infrastructure FastConnect. During the setup, set the following parameters:
- Network: Use the default.
- Region: Select a region where the interconnect is available. See Availability.
- Cloud Router: Select a Cloud Router that already works with the VPC you want to connect to an OCI VCN.
- MTU: Select 1500. This size is the least likely to cause issues. See the article Hanging Connection for more about MTU sizes in OCI.
You receive a pairing key or keys from GCP. See step 10 of Create unencrypted VLAN attachments. Record or store that pairing key, because you must provide it to Oracle when you set up a FastConnect virtual circuit in the next step. The pairing key is a unique key that lets OCI identify and connect to the Google Cloud​​​​​​​ VPC network and the associated Cloud Router. OCI requires this key to complete the configuration of the VLAN attachment.
After the VLAN attachments are created, check the Enable box to preactivate the VLAN attachments. If you do this now, you can skip Task 4 (Optional): Activate the Connection.
We recommend creating a redundant pair of interconnect VLAN attachments to increase availability. Creating redundancy results in 2 pairing keys. If you don't need redundancy, you can create a single VLAN attachment (you can always make it redundant later), which results in a single pairing key.
In the next task, you set up a FastConnect private virtual circuit to Google Cloud Platform. When that virtual circuit provisioning finishes, the VLAN attachment updates to show that private peering is enabled.
- In the Console, confirm you're viewing the compartment that you want to work in. If you're not sure which one, use the compartment that contains the DRG to connect to. This choice of compartment, along with a corresponding IAM policy, controls who can access the virtual circuit you're about to create.
-
Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
The resulting FastConnect page is where you create a new virtual circuit and later return to when you need to manage the virtual circuit.
- Select Create FastConnect.
- Select FastConnect partner and select Google Cloud​​​​​​​: OCI Interconnect from the list.
-
Select either Single virtual circuit (the default) or Redundant virtual circuits to configure virtual circuits that use different physical devices in the same FastConnect location. See FastConnect Redundancy Best Practices for more about redundancy. If you select Single virtual circuit you can return later to add a redundant virtual circuit.
- Select Next.
-
Enter the following for the virtual circuit (Virtual circuit 1 if you selected Redundant virtual circuits):
- Name: A descriptive name for the virtual circuits. The value doesn't need to be unique across the virtual circuits, and you can change it later. Avoid entering confidential information.
- Create in Compartment: Leave as is (the compartment you're working in).
- Select Partner and select the partner from the list. Note
If you select Megaport as the partner, you can provision the partner side of the circuit using the optional steps mentioned.
-
Select the Private virtual circuit type. Redundant virtual circuits must both be private, or both public, so this setting is matched on the other virtual circuit. Now enter the following:
- Select either All traffic or IPSec over FastConnect traffic only. The virtual circuit can be used for IPSec over FastConnect with either choice, but you can select to only allow encrypted traffic on the virtual circuit. Redundant virtual circuits must have the same setting, so this is matched on the other virtual circuit.
- Dynamic Routing Gateway: Select the DRG to route the FastConnect traffic to. IPSec over FastConnect requires an upgraded DRG. This DRG could be attached to several VCNs or to other DRGs with attached VCNs.
- Provisioned Bandwidth: Select a value. If the bandwidth needs increase later, you can update the virtual circuit to use a different value (see To edit a virtual circuit).
- Partner Service Key (Optional): Enter the service key provided by Google. You can enter this key now or edit the circuit later.
If the BGP session goes to Oracle (see Basic Network Diagrams), the dialog box includes other fields for the BGP session:
- Customer BGP IP Address: The BGP peering IP address for the edge (CPE), with a subnet mask from /28 to /31.
- Oracle BGP IP Address: The BGP peering IP address you want to use for the Oracle edge (the DRG), with a subnet mask from /28 to /31.
- Enable IPv6 Address Assignment: IPv6 addressing is supported for all commercial and government regions. See FastConnect and IPv6.
- Customer BGP ASN: The public or private ASN for the Google VCP.
- Use a BGP MD5 Authentication Key (optional): Select this checkbox and provide a key if MD5 authentication is required. Oracle supports up to 128-bit MD5 authentication.
- Enable Bidirectional Forwarding Detection (optional): Select this checkbox to enable Bidirectional Forwarding Detection. Note
When you use Bidirectional Forwarding Detection, the paired device must be configured to use a 300 ms minimum interval and a multiplier of 3.
- If you're creating a redundant virtual circuit, enter the necessary information for the other virtual circuit (Virtual circuit 2). If you selected Redundant virtual circuits, remember that the virtual circuit type (private or public) and All traffic or IPSec over FastConnect traffic only settings for Virtual circuit 2 are already set to match Virtual circuit 1 and if you change them the settings on the other circuit automatically change to match. Note
Creating a redundant virtual circuit is optional if you selected Redundant virtual circuits and the partner you selected creates a Layer 3 connection to OCI, but a redundant virtual circuit is required if the partner you selected creates a Layer 2 connection. See FastConnect Redundancy Best Practices for more about Layer 2 and Layer 3 connections. -
Select Create.
The virtual circuit is created and a status page displays. Select Close to return to the list of virtual circuits.
- Select the name of the virtual circuit you created. While the virtual circuit is in the PENDING PARTNER state, its OCID and a link to the partner's portal are displayed in the "Connection created" confirmation box at the top of the page. The virtual circuit's OCID is also available with the other virtual circuit details. Copy and paste the OCID to another location. You give it to the Oracle partner in the next task. Also copy the OCID for the redundant circuit if you created one.
After you create the FastConnect virtual circuit, wait until OCI configures the connections. Looking at the details page for the virtual circuit you created, verify on the Virtual circuit information tab that the lifecycle state for the virtual circuit information changes to Provisioned. Also look on the BGP information tab to verify that the BGP session is established. Allow a few minutes for the BGP session to change to the Established state. Also see To get the status of a FastConnect virtual circuit.
Task 4 (Optional): Activate the Connection
This step is only required if you didn't preactivate the GCP VLAN attachments when you were provided the pairing keys in Task 2: Create a Google Cloud Interconnect VLAN attachment.
After configuration and provisioning have completed on the OCI side, if you didn't preactivate the GCP VLAN attachments you receive an email notification from Google Cloud​​​​​​​. After receiving the email, you must Enable the VLAN attachment from the Google Cloud​​​ Console. Activating the connection and checking its activation status is required before you can verify that you have established connectivity with the Google Cloud​​​​​​​.
For the VPC: Decide which subnets in the VPC need to communicate with the VCN. Then configure BGP advertising for those subnets to route traffic as appropriate.
For the VCN:
- Decide which subnets in the VCN need to communicate with the VPC.
-
Update the route table for each of those subnets to include a new rule that directs traffic destined for the VPC's CIDR to the DRG:
- In the Console, while viewing the VCN you're interested in, select Route Tables.
- Select the route table you're interested in.
- Select Edit Route Rules.
-
Select + Another Route Rule and enter the following:
- Target Type: Dynamic Routing Gateway. The VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself.
- Destination CIDR Block: The relevant subnet in the VPC (10.0.0.0/16 in the preceding diagram).
- Description: An optional description of the rule.
- Select Save.
Any subnet traffic with a destination that matches the rule is routed to the DRG. The DRG then knows to route the traffic to the VPC based on the virtual circuit's BGP session information.
Later, if you no longer need the connection and want to delete the DRG, you must first delete all the route rules in the VCN that specify the DRG as the target.
For more information about setting up route rules, see VCN Route Tables.
If you decide to terminate the connection, you must follow a particular process. See To terminate Oracle Interconnect for Google Cloud.
Contact OCI or Google Cloud​​​​​​​ support teams if the BGP state isn't established.
Managing Oracle Interconnect for Google Cloud
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
- Select the compartment where the connection resides.
- Select the connection you're interested in. If the icon for the virtual circuit is green and says UP, the virtual circuit is provisioned and BGP has been correctly configured. The virtual circuit is ready to use.
You can change these items for a virtual circuit:
- The name
- Which DRG it uses
If the virtual circuit is in the PROVISIONED state, changing which DRG it uses switches the state to PROVISIONING and might cause the connection to go down. After Oracle reprovisions the virtual circuit, its state returns to PROVISIONED. Confirm that the connection is back up and working.
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
- Select the compartment where the connection resides, and then select the connection.
- Select the virtual circuit.
- Select Edit and make changes. Avoid entering confidential information.
- Select Save.
The following steps show the overall process of terminating Oracle Interconnect for Google Cloud.
The Oracle Interconnect for Google Cloud is terminated.