This document covers commonly asked questions about Cloud Interconnect features and architecture grouped into the following major sections:
- Traffic over Cloud Interconnect
- Cloud Interconnect architecture
- VLAN attachments
- Infrastructure maintenance events
- Interconnect connection management
Traffic over Cloud Interconnect
This section covers questions about traffic types, bandwidth, and encryption over Cloud Interconnect.
What kind of packets are carried over Cloud Interconnect?
The Cloud Interconnect circuit carries 802.1q Ethernet frames with IPv4 packets in the payload. These frames are also known as VLAN-tagged Ethernet frames.
The value of the 12-bit VLAN ID (VID) field of the 802.1q header is the same as the VLAN ID value assigned by Google Cloud when a VLAN attachment is created. For more information, see the following documents:
- Creating VLAN attachments for Dedicated Interconnect
- Creating VLAN attachments for Partner Interconnect
How can I encrypt my traffic over Cloud Interconnect?
Depending on the service that is accessed by using Cloud Interconnect, your traffic might already be encrypted without your needing to do anything special. For example, if you are accessing one of the Google Cloud APIs reachable over Cloud Interconnect, that traffic is already encrypted with TLS in the same way as if the APIs were accessed over the public internet.
You can also use the TLS solution for services that you create; for example, a service that you offer on a Compute Engine instance or on a Google Kubernetes Engine Pod that supports the HTTPS protocol.
If you need encryption at the IP layer, you can create one or more self-managed (non-Google Cloud) VPN gateways in your Virtual Private Cloud (VPC) network and assign a private IP address to each gateway. For example, you can run a strongSwan VPN on a Compute Engine instance. You can then terminate IPsec tunnels to those VPN gateways through Cloud Interconnect from an on-premises environment.
For more details, see the Encryption in transit documentation.
Can I create a 100-Gbps connection over Dedicated Interconnect?
Yes, you can scale your connection to Google based on your needs.
An Interconnect connection consists of one or more circuits deployed as an Ethernet port channel link (LAG) group. The circuits in a connection can be 10 Gbps or 100 Gbps, but not both.
A connection can have one of the following maximum capacities:
- 8 x 10-Gbps circuits (80 Gbps total)
- 2 x 100-Gbps circuits (200 Gbps total)
Dedicated Interconnect or Partner Interconnect support VLAN attachment capacities from 50 Mbps to 50 Gbps. Although the maximum supported attachment size for Partner Interconnect is 50 Gbps, not all sizes might be available, depending on what's offered by your chosen service provider in the selected location.
You can order more than one connection and use them in an active-active fashion by using the Border Gateway Protocol (BGP) routing capabilities of Cloud Router.
Can I reach my instances using IPv6 over Cloud Interconnect?
Although IPv6 is supported in some subnet regions, it is not supported by Cloud Interconnect or Cloud Router.
Can I specify the BGP peering IP address?
- For Partner Interconnect, no. Google chooses the peering IP addresses.
- For Dedicated Interconnect, you can specify an IP
address range (CIDR block) that Google selects from when you create a VLAN
attachment. This CIDR block must be in the link-local IP address range
Can I reach Google APIs through Cloud Interconnect from on-premises? Which services or APIs are available?
There are two ways to reach Google APIs:
Option 1: You can enable Private Google Access for one or more subnets in the VPC network, and deploy one or more reverse-proxy instances in those subnets. These reverse proxies have only VPC private IP addresses configured, and are thus reachable only through the Cloud Interconnect link from on-premises. With this solution, most access to Google Cloud APIs, developer APIs, and most Google Cloud services is granted.
For more details, including a list of Google Cloud services that Private Google Access supports, see Configuring Private Google Access.
Option 2: You can use Private Google Access for on-premises hosts. In this case, requests from on-premises hosts must be sent to
restricted.googleapis.com, which resolves persistently to IP range
184.108.40.206/30, also known as the restricted VIP range.
To advertise the restricted VIP range, add a custom route on Cloud Router. This ensures that traffic to the restricted VIP (as a destination) is routed from on-premises to the API endpoints over Cloud Interconnect. Only the Google APIs and services that support the restricted VIP are reachable with this solution.
For the latest information about configuration details and supported services, see Configuring Private Google Access for on-premises hosts.
Can I use Cloud Interconnect as a private channel to access all Google Workspace services through a browser?
It is not possible to reach Google Workspace applications through Cloud Interconnect.
Why do my BGP sessions flap continuously after a certain interval?
Check for an incorrect subnet mask on your on-premises BGP IP range.
For example, instead of configuring
169.254.10.0/29, you might have configured
Can I send and learn MED values over an L3 Partner Interconnect connection?
If you are using a Partner Interconnect connection where a Layer 3 service provider handles BGP for you, Cloud Router can't learn MED values from your on-premises router or send MED values to that router. This is because MED values can't pass through autonomous systems. Over this type of connection, you can't set route priorities for routes advertised by Cloud Router to your on-premises router. In addition, you can't set route priorities for routes advertised by your on-premises router to your VPC network.
Cloud Interconnect architecture
This section covers common questions that arise when designing or using a Cloud Interconnect architecture.
Can I rename Dedicated Interconnect connections or move them to a different project?
No. After you name a Dedicated Interconnect connection, you can't rename it or move it to a different Google Cloud project. Instead, you must delete the connection and recreate it with a new name or in a different project.
Can I use Cloud Interconnect to connect to the public internet?
Internet routes are not advertised over Cloud Interconnect.
How can I connect to Google Cloud if I'm located in a PoP location not listed in the colocation facility locations?
You have two options, after which you can go through the normal ordering and provisioning process for Dedicated Interconnect:
- Option 1: You can order leased lines from a carrier to connect from your point-of-presence (PoP) location to one of Google's Cloud Interconnect colocation facilities. Usually it's best if you contact your existing colocation facility provider and get a list of on-net providers. An on-net provider is a provider that already has infrastructure in the building where you are located. Using an on-net provider is cheaper and faster than using a different provider who must build out infrastructure to meet you in your existing PoP location.
- Option 2: You can use Partner Interconnect with a service provider who can provide a last-mile circuit to meet you. Colocation providers cannot usually provide this type of service because they have fixed locations where you must already be present.
If I use Partner Interconnect, can I see the connection in the project where I create the VLAN attachment?
When you use the Partner Interconnect service, the object for
the Interconnect connection is created in the service provider project and is
not visible in your project. The VLAN attachment (
still visible inside your project as in the Cloud Interconnect case.
How do I create a redundant architecture that uses Cloud Interconnect?
Depending on the desired SLA, there are specific architectures that must be implemented for both Dedicated Interconnect and Partner Interconnect.
Topologies for production-ready architectures with a 99.99% SLA and for non-critical applications with a 99.9% SLA are available at Cloud Interconnect tutorials.
These SLA levels refer to the availability of the Interconnect connection, which is the availability of the routed connection between the on-premises location and the VPC network. For example, if you create a service on Compute Engine instances that's reachable through Cloud Interconnect, the service availability depends on the combined availability of both the Cloud Interconnect service and the Compute Engine service.
- For Dedicated Interconnect, a single Interconnect connection (LACP bundle) has a No Uptime SLA.
- For Partner Interconnect, a single VLAN attachment has a No Uptime SLA.
Issues with single connection/bundle failures are treated as a support case priority no higher than P3: Medium Impact—Service Use Partially Impaired. Therefore, you cannot expect a quick resolution or further analysis of the root cause.
Due to planned or unplanned maintenance, single links or bundles might be drained even for extended periods of time, such as hours or days.
Can I forward traffic over Cloud Interconnect between my on-premises application and my internal load balancer backends?
In this scenario, you deployed an application that consists of two tiers: an on-premises tier that has not yet been migrated to Google Cloud (legacy tier) and a cloud tier running on VPC instances that are also backends of a Google Cloud internal load balancer.
You can use Cloud Interconnect to forward the traffic between these two application tiers as long as you implement the necessary routes between Cloud Router and your on-premises router. Consider the following two cases:
Case 1: Cloud Router and load balancer backends located in the same region.
Because the Cloud Router used for the VLAN attachment that handles this application's traffic is in the same region as the subnet that contains the load balancer backends, traffic can be forwarded without additional settings.
Case 2: Cloud Router and load balancer backends located in different regions.
In this scenario, because the Cloud Router and load balancer backends are located in different regions, you need to configure the following:
- Enable global dynamic routing mode in the VPC.
- Enable global access mode in the load balancer.
For more information, see the following:
Can I move one or more instances of Cloud Interconnect between Google Cloud projects or organizations?
If you want to move a project to a new Google Cloud organization, you can open a support case, and Google Cloud Support can facilitate the move.
Changes of organization do not affect Dedicated Interconnect and VLAN attachments as long as the project stays the same.
For project changes, if you are performing a Cloud Interconnect activation and you have an LOA but have not yet completed the activation, cancel the current activation and create a new one in the correct project. Google issues you a new LOA, which you can then give to your Interconnect connection provider. For steps, see Ordering a connection and Retrieving LOA-CFAs.
An active Interconnect connection can't be moved between projects because it is a child object of the project, and there is no ability to automatically migrate objects between projects. If possible, you should start a request for a new Interconnect connection.
How can I use the same Interconnect connection to connect multiple VPC networks in multiple projects inside the same Google Cloud organization?
For either Dedicated Interconnect or Partner Interconnect, you can use Shared VPC or VPC Network Peering to share a single attachment between multiple VPC networks. For steps, see Enabling multiple VPC networks to access the same VLAN attachment.
For Partner Interconnect
If you can't use Shared VPC or VPC Network Peering—for example, because you need to keep the VPC networks separate—you must create additional VLAN attachments. Creating more attachments might incur additional costs.
If you have multiple VLAN attachments, including attachments in different projects, you can pair them with a Partner Interconnect connection from the same service provider or with Partner Interconnect connections from different service providers.
For Dedicated Interconnect
You can create multiple attachments, one for each project or VPC network that you want to connect to.
If you have many projects, you can give each project its own VLAN attachment and its own Cloud Router while configuring all the attachments to use the same physical Dedicated Interconnect connection in a specified project.
The VLAN attachment, in addition to being a VLAN with an 802.1q ID, is a child object of an Interconnect connection that exists in a project.
In this model, each VPC network has its own routing configuration. If you want to centralize routing policies, you can review the Shared VPC model and Shared VPC considerations. You can then terminate the VLAN attachment in the VPC network of the Shared VPC host project. Your host project has a quota for the maximum number of VLAN attachments per Interconnect connection. For details, see Cloud Interconnect Quotas and limits.
Can I use a single Interconnect connection to connect multiple on-premises sites to my VPC network?
You can easily do this. For example, if the multiple sites are part of an MPLS VPN network, either self-managed or managed by a carrier, you can logically add the VPC network as an additional site by using an approach similar to Inter-AS MPLS VPN Option A (for more information, see RFC 4364, Paragraph 10).
This solution is described in the answer for making a VPC network appear in a partner's MPLS VPN service. By applying the BGP capabilities of Cloud Router, it is possible to inject VPC routes inside an existing IP core fabric by using techniques and architectures similar to the ones used to import internet routes.
Can I physically patch together an Interconnect connection and an interconnect from another cloud provider?
If you are already using another cloud provider that offers a service functionally equivalent to Cloud Interconnect, there is no agreed-upon configuration between cloud providers to physically patch together two connections, one provided by Google Cloud and one provided by the other cloud provider. However, you can route between the private address space of the VPC network and the network of a different cloud provider.
If the service handoff point for the other cloud provider is located in the same location as Cloud Interconnect, you can provision your own router in that location to terminate the two connection services. The router then routes between the VPC network and the other cloud provider's network. This configuration lets you route directly from the two cloud networks into your on-premises network with minimal delay.
Some Partner Interconnect carriers are able to offer this configuration as a managed service, based on a virtual router. If Google Cloud and the other cloud provider terminate connection services in different locations, you must provide a circuit that connects the two locations.
- For locations where Google offers Dedicated Interconnect service, see Choosing colocation facility locations.
- For locations where Google offers Partner Interconnect service, see Supported service providers.
How can I connect AWS and Google Cloud without placing equipment in a colocation facility near the Google edge?
Some network service providers offer their own Cloud Router and Partner Interconnect-based solutions for Google Cloud customers who don't want to place hardware near the Google edge.
For information about how to set up Equinix solutions with Google Cloud, see the Equinix configuration instructions.
For information about how to set up the Megaport product with Google Cloud, see the Megaport configuration instructions.
This section covers questions about VLAN attachments.
How can I choose the VLAN ID that is used for a VLAN attachment?
For a VLAN attachment created with Partner Interconnect, the service provider either chooses the VLAN ID during the attachment creation process or lets you choose it. Check with your service provider to determine if they let you choose the VLAN ID for VLAN attachments.
For a VLAN attachment created with Dedicated Interconnect,
you can use the
gcloud compute interconnects attachments create command
--vlan flag, or you can follow the
Google Cloud console instructions.
The following example shows how to use the
gcloud command to change the
VLAN ID to
gcloud compute interconnects attachments dedicated create my-attachment \ --router my-router \ --interconnect my-interconnect \ --vlan 5 \ --region us-central1
For full instructions, see one of the following documents:
- Creating VLAN attachments for Dedicated Interconnect
- Creating VLAN attachments for Partner Interconnect
Can I use a Cloud Router with more than one VLAN attachment?
Yes, this is a supported configuration.
Can I configure attachments whose combined bandwidth exceeds the bandwidth of my Interconnect connection?
Yes, but creating attachments with a combined bandwidth greater than the Interconnect connection doesn't give you more than the maximum supported bandwidth of the connection.
This section covers questions about Cloud Interconnect and Multiprotocol Label Switching (MPLS).
Can I use Cloud Interconnect to terminate an MPLS LSP inside my VPC network?
VPC does not offer a built-in capability in Google Cloud to terminate MPLS LSP.
For a self-managed MPLS VPN service, can I make my VPC network appear as an additional site?
If you have an MPLS VPN service that you manage, you can make your VPC network appear as an additional site that consists of a self-managed VPN.
This scenario assumes that you are not buying an MPLS VPN service from a provider. Instead, you have an MPLS VPN environment where you manage and configure the P and PE routers of the MPLS network yourself.
To make your VPC network appear as an additional site in your self-managed MPLS VPN service, do the following:
Connect one of your MPLS VPN PE edge devices to your peering edge device for Dedicated Interconnect by using a model similar to Inter-AS MPLS VPN Option A (see RFC 4364, Paragraph 10). In other words, you can terminate the required MPLS-VPN VPN, for example, VRF_A, into your PE edge device, and then use VLAN-to-VRF mapping to "join" the Google Cloud VLAN attachment into this VPN, essentially mapping VLAN to VRF_A at the PE edge device.
Create a standard IPv4 BGP session between the PE router and Cloud Router to ensure that routes are exchanged between them. The routes sent by Cloud Router appear only in the VPN routing table (inside VRF_A) and not in the global routing table of the PE edge device.
You can manage overlapping IP ranges by creating multiple, separated VPNs. For example, VRF_A and VRF_B, each one having a BGP session to Cloud Router in a specific VPC network (for example, VPC_A and VPC_B). This procedure does not require any MPLS encapsulation between your PE edge device and the peering edge device for Dedicated Interconnect.
Can I make my VPC network appear as an additional site in my MPLS VPN from a carrier who is also a service provider for Partner Interconnect?
If you buy an MPLS VPN service from a carrier that is also an official service provider for Partner Interconnect, you can make your VPC network appear as an additional site in your MPLS VPN.
In this case, the carrier manages and configures the P and PE routers of their MPLS network. Because Partner Interconnect uses the exact same connectivity model as Dedicated Interconnect, the carrier can use a model similar to Inter-AS MPLS VPN Option A (see RFC 4364, Paragraph 10).
Essentially, the carrier provides a Layer 3 Partner Interconnect service to you, and then "binds" your VLAN attachment with the correct MPLS VPN on the carrier's edge device. Because this is a Layer 3 service model, the BGP session is established between your Cloud Router and your VRF inside the carrier edge device. For details, see the Partner Interconnect overview.
Infrastructure maintenance events
What are infrastructure maintenance events?
Cloud Interconnect might periodically need to perform scheduled maintenance that might affect your network. Emergency or unscheduled maintenance events might also occur that can cause circuits to be down. Google recommends creating high availability hybrid network topologies.
How often do scheduled infrastructure maintenance events happen?
Infrastructure maintenance events don't have a set interval between occurrences, but generally happen several times a year.
How do I know when infrastructure maintenance events will happen?
Ahead of a scheduled infrastructure maintenance event, Dedicated Interconnect users receive the following notifications:
- An email is sent to all Dedicated Interconnect connection project owners as soon as an impacting maintenance is scheduled.
An email is sent to the address listed in the nocContactEmail field of the Cloud Interconnect object. You can find and edit this object in the Google Cloud console on the Cloud Interconnect details page, or by using the following
gcloud compute interconnects describe my-interconnect
An email is sent to any technical contacts listed for the project that hosts the Dedicated Interconnect connection.
A notification appears on the Google Cloud console Activity tab and in the Notifications area.
Partner Interconnect users receive the following notifications:
- An email is sent to any technical contacts for the project that hosts the VLAN attachment.
- An email is sent to all project owners for the project that hosts the VLAN attachment.
Notifications do not appear in Google Cloud console for Partner Interconnect users.
For details on how to assign technical contacts for a project, see Managing contacts for notifications.
A single link in one edge availability domain carries no SLA. To prevent loss of access to your services during maintenance, make sure that you provision two links in different edge availability domains.
Interconnect connection management
How do I disconnect or disable my Interconnect connection temporarily?
If you want to shut down your Dedicated or Partner Interconnect connection temporarily (for failover testing or alarm testing, etc.), you can use the following command.
gcloud compute interconnects update my-interconnect --no-admin-enabled
To re-enable the connection, use the following command:
gcloud compute interconnects update my-interconnect --admin-enabled
If you need to physically detach the connection, work with your provider to unplug the cross connect at the MMR in your colocation facility. You can provide the original provided LOA to the provider to request the disconnect.
If you no longer have access to the LOA, please email email@example.com.