Partner Interconnect provides connectivity between your on-premises network and your Virtual Private Cloud (VPC) network through a supported service provider. A Partner Interconnect connection is useful if your data center is in a physical location that can't reach a Dedicated Interconnect colocation facility, or your data needs don't warrant an entire 10-Gbps connection.
Before you use Partner Interconnect
Ensure that you meet the following requirements:
- Be familiar with Cloud Interconnect terminology.
- Work with a supported service provider to establish connectivity between their network and your on-premises network. Supported service providers offer layer 2 connectivity, layer 3 connectivity, or both. Work with your service provider to understand their offerings and requirements.
How does Partner Interconnect work?
Service providers have existing physical connections to Google's network that they make available for their customers to use. After you establish connectivity with a service provider, you can request a Partner Interconnect connection from your service provider. After the service provider provisions your connection, you can start passing traffic between your networks by using the service provider's network.
To provision a Partner Interconnect connection with a service provider, you start by connecting your on-premises network to a supported service provider. Work with the service provider to establish connectivity.
Next, you create a VLAN attachment for a Partner Interconnect connection in your Google Cloud project, which generates a unique pairing key that you use to request a connection from your service provider. You also need to provide other information such as the connection location and capacity.
After the service provider configures your VLAN attachment, you activate your connection to start using it. Depending on your connection, either you or your service provider then establishes a Border Gateway Protocol (BGP) session.
For detailed steps to provision a Partner Interconnect connection, see the Provisioning overview.
Layer 2 versus layer 3 connectivity
For layer 2 connections, you must configure and establish a BGP session between your Cloud Routers and on-premises routers for each VLAN attachment that you create. The BGP configuration information is provided by the VLAN attachment after your service provider has configured it.
For layer 3 connections, your service provider establishes a BGP session between your Cloud Routers and their edge routers for each VLAN attachment. You don't need to configure BGP on your on-premises router. Google and your service provider automatically set the correct configurations.
Because the BGP configuration for layer 3 connections is fully automated, you can pre-activate your connections (VLAN attachments). When you enable pre-activation, the VLAN attachments are active as soon as the service provider configures them.
After you create a VLAN attachment and your service provider configures it, the attachment can't pass traffic until you activate it. Activation lets you check that you're connecting to an expected service provider.
If you don't need to verify the connection and are using a layer 3 connection, you can choose to pre-activate the attachment. If you pre-activate the attachment, it can immediately pass traffic after your service provider has configured it.
If you want to verify who you're connecting to, don't pre-activate your attachments.
Consider pre-activation if you're using layer 3 and want your connection to activate without additional approval. Layer 3 service providers automatically configure BGP sessions with your Cloud Routers so that BGP starts immediately. You don't need to return to Google after your service provider configures your attachments.
For layer 2 connections, there's no benefit to pre-activating VLAN attachments.
The following topology diagrams show example Partner Interconnect connections for layer 2 and layer 3.
For layer 2 connections, traffic passes through the service provider's network to reach the VPC network or on-premises network. BGP is configured between the on-premises router and a Cloud Router in the VPC network, as shown in the following diagram.
For layer 3 connections, traffic is passed to the service provider's network. Their network then routes the traffic to the correct destination, either to the on-premises network or to the VPC network. Connectivity between the on-premises network and the service provider network depends on the service provider. For example, the service provider might request that you establish a BGP session with them or configure a static default route to their network.
Redundancy and SLA
Depending on your availability needs, you can configure Partner Interconnect to support mission-critical services or applications that can tolerate some downtime. To achieve a specific level of reliability, Google has two prescriptive configurations:
- Achieve 99.99% availability for Partner Interconnect (recommended)
- Achieve 99.9% availability for Partner Interconnect
We recommend that you use the 99.99% availability configuration for production-level applications with a low tolerance for downtime. If your applications aren't mission-critical and can tolerate some downtime, you can use the 99.9% availability configuration.
For the 99.99% and 99.9% availability configurations, Google offers an SLA that applies only to the connectivity between your VPC network and the service provider's network. The SLA doesn't include the connectivity between your network and the service provider's network. If your service provider does offer an SLA, you can get an end-to-end SLA based on the Google-defined topologies. For more information, ask your service provider.
99.99% availability topology
For the highest level availability, we recommend the 99.99% availability configuration. Clients in the on-premises network can reach the IP addresses of virtual machine (VM) instances in the selected region through at least one of the redundant paths. If one path is unavailable, the other paths can continue to serve traffic.
99.99% availability requires at least four VLAN attachments across two metros, one in each edge availability domain (metro availability zone). You also need four Cloud Routers (two in each Google Cloud region of a VPC network). Associate one Cloud Router with each VLAN attachment. You must also enable global routing for the VPC network.
For layer 2 connections, four virtual circuits are required, split between two metros. Layer 2 also requires that you add four BGP sessions to the on-premises router, one for each Cloud Router, as shown in the following diagram.
For layer 3 connections, four connections between Google and your service provider are required. You create four VLAN attachments, and then your service provider establishes four BGP sessions with each of your Cloud Routers. The VLAN attachments must be split between two metros, as shown in the following diagram.
Multiple service providers
To build a highly available topology, you can use multiple service providers. You must build redundant connections for each service provider in each metro.
For example, you might provision two primary connections by using a local service provider that's close to your data center. For the backup connection, you might use a long-haul service provider to build two connections in a different metro. Ensure that this topology meets all your requirements for availability.
Balancing egress traffic with redundant VLAN attachments
When you have a redundant topology similar to the 99.99% configuration, there are multiple paths for traffic to traverse from the VPC network to your on-premises network. If Cloud Routers in the same region receive the same announcement with equal cost (same CIDR range and same MED values), Google Cloud uses ECMP to balance the egress traffic across connections.
Restricting Partner Interconnect usageBy default, any VPC network can use Cloud Interconnect. To control which VPC networks can use Cloud Interconnect, you can set an organization policy. For more information, see Restricting Cloud Interconnect usage.
- To find answers to common questions about Cloud Interconnect architecture and features, see the Cloud Interconnect FAQ.
- To find out more about Cloud Interconnect, see the Cloud Interconnect overview.
- To learn about best practices when planning for and configuring Cloud Interconnect, see Best practices for Cloud Interconnect.
- To find Google Cloud resource names, see the Cloud Interconnect APIs.