Partner Interconnect provides connectivity between your on-premisesnetwork and your Virtual Private Cloud (VPC) network through a supportedservice provider. A Partner Interconnect connection is useful ifyour data center is in a physical location that can't reach a Dedicated Interconnect colocation facility, or your data needsdon't warrant an entire 10-Gbps connection.

Before you use Partner Interconnect

Ensure that you meet the following requirements:

• Be familiar withCloud Interconnect terminology.
• Work with asupported service providerto 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 andrequirements.

Note: Partner Interconnect requires that you separately obtainservices from a third-party network service provider. Google is not responsiblefor any aspects of Partner Interconnect provided by thethird-party service provider nor any issues outside of Google's network.

How does Partner Interconnect work?

Service providers have existing physical connections to Google's network thatthey make available for their customers to use. After you establish connectivitywith a service provider, you can request a Partner Interconnectconnection from your service provider. After the service provider provisionsyour connection, you can start passing traffic between your networks by usingthe service provider's network.

VLAN attachment MTU options

We recommend that you use the same MTU for all VLAN attachments that areconnected to the same VPC network, and that you set the MTU ofthe VPC networks to the same value. For more information aboutCloud Interconnect MTUs, seeCloud InterconnectMTU.

Provisioning

To provision a Partner Interconnect connection with a serviceprovider, you start by selecting a partner and whether you wantMACsec for Cloud Interconnect, and thenconnecting your on-premises network to a supported service provider. Work withthe service provider to establish connectivity.

Next, you create a VLAN attachment for a Partner Interconnectconnection in your Google Cloud project, which generates a unique pairing keythat you use to request a connection from your service provider. You alsoneed to provide other information such as the connection location, IP stacktype, and capacity.

After the service provider configures your VLAN attachment, you activate yourconnection to start using it. Depending on your connection, either you or yourservice provider then establishes a Border Gateway Protocol (BGP) session.

For detailed steps to provision a Partner Interconnectconnection, see theProvisioning overview.

Layer 2 versus Layer 3 connectivity

For Layer 2 connections, you must configure and establish a BGP session betweenyour Cloud Routers and on-premises routersfor each VLAN attachment that you create. The BGP configuration information isprovided by the VLAN attachment after your service provider has configured it.

For Layer 3 connections, your service provider establishes a BGP session betweenyour Cloud Routers and their on-premises routers for each VLAN attachment.You don't need to configure BGP on your local router. Google and yourservice provider automatically set the correct BGP configurations.

Because the BGP configuration for Layer 3 connections is fully automated, youcan pre-activate your connections (VLAN attachments). When youenable pre-activation, the VLAN attachments are active as soon as the serviceprovider configures them.

Pre-activation

After you create a VLAN attachment and your service provider configures it, theattachment can't pass traffic until you activate it. Activation lets youcheck 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 theattachment, it can immediately pass traffic after your service provider hasconfigured it.

If you want to verify who you're connecting to, don't pre-activate yourattachments.

Consider pre-activation if you're using Layer 3 and want your connection toactivate without additional approval. Layer 3 service providers automaticallyconfigure BGP sessions with your Cloud Routers so that BGP startsimmediately. You don't need to return to Google after your service providerconfigures your attachments.

For Layer 2 connections, there's no benefit to pre-activating VLAN attachments.

Basic topology

The following topology diagrams show example Partner Interconnectconnections for Layer 2 and Layer 3.

For Layer 2 connections, traffic passes through the service provider's networkto reach the VPC network or on-premises network. BGP is configuredbetween the on-premises router and a Cloud Router in theVPC 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 tothe on-premises network or to the VPC network. Connectivitybetween the on-premises network and the service provider network depends on theservice provider. For example, the service provider might request that youestablish a BGP session with them or configure a static default route to theirnetwork.

Redundancy and SLA

Depending on your availability needs, you can configurePartner Interconnect to support mission-critical services orapplications that can tolerate some downtime. To achieve a specific level ofreliability, Google has two prescriptive configurations:

• Establish 99.99% availability for Partner Interconnect (recommended)
• Establish 99.9% availability for Partner Interconnect

We recommend that you use the 99.99% availability configuration forproduction-level applications with a low tolerance for downtime. If yourapplications aren't mission-critical and can tolerate some downtime, you can usethe 99.9% availability configuration.

For the 99.99% and 99.9% availability configurations, Google offers an SLAthat applies only to the connectivity between your VPC networkand the service provider's network. The SLA doesn't include the connectivitybetween your network and the service provider's network. If your serviceprovider does offer an SLA, you can get an end-to-end SLA based on theGoogle-defined topologies. For more information, ask your service provider.

99.99% availability topology

For the highest level availability, we recommend the 99.99% availabilityconfiguration. Clients in the on-premises network can reach the IP addresses ofvirtual machine (VM) instances in the selectedGoogle Cloudregion through at least one of the redundantpaths. If one path is unavailable, the other paths can continue to servetraffic.

99.99% availability requires at least four VLAN attachments across two metros,one in each edge availability domain (metro availability zone). You also needtwo Cloud Routers (one in each Google Cloud region of aVPC network). Associate one Cloud Router with each pairof VLAN attachments. You must alsoenable globalrouting forthe VPC network.

For Layer 2 connections, four virtual circuits are required, split between twometros. Layer 2 also requires that you add four BGP sessions to the on-premisesrouter, two for each Cloud Router, as shown in the following diagram.

For Layer 3 connections, four connections between Google and your serviceprovider are required. You create four VLAN attachments, and then your serviceprovider establishes two BGP sessions with each of your Cloud Routers.The VLAN attachments must be split between two metros, as shown in the followingdiagram.

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 localservice 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 adifferent metro. Ensure that this topology meets all your requirements foravailability.

Balancing egress traffic with redundant VLAN attachments

When you have a redundant topology similar to the 99.99% configuration, thereare multiple paths for traffic to traverse from the VPC networkto your on-premises network.

Google Cloud usesECMP to balance the egress traffic acrossconnections. To use ECMP, the Cloud Routers used by the VLANattachments must receive the same announcement with equal cost (the same CIDRrange and the same MED values).

Dedicated Interconnect does the following to balance trafficacross connections:

Google Cloud balances the traffic between the VLAN attachments basedupon the configured capacity of each VLAN attachment.

Create redundant connections with sufficient capacity

TheBest practices document describes best practices for creating redundant connections that have sufficient capacity in a failover scenario. Following these practices helps ensure that events such as planned maintenance orhardware failures do not cause loss of connectivity.

IPv6 support

Partner Interconnect supports IPv6 traffic for both Layer 2 andLayer 3 connectivity. You have the option to create an IPv4 and IPv6 (dualstack) VLAN attachment.

Dual-stack Partner Interconnect VLAN attachments must useseparate IPv4 and IPv6 BGP sessions. Multiprotocol BGP (MP-BGP)—IPv4 +IPv6 route exchange—on a single BGP session isn't supported.

Important: Encrypted VLAN attachments don't support IPv6 dual-stack sessions.

To support IPv6 traffic in a Partner Interconnect connection,do the following:

• Configure your VPC networks to use either IPv4 and IPv6 (dualstack) or IPv6-onlysubnets.

• Assign subnets withininternal IPv6ranges.

• Configure IPv6 addresses for VMs and instancetemplates within thesubnet.

For more information about configuring IPv6 within a subnet, see thefollowing:

• To create a custom mode VPC network with internal IPv6addresses, seeCreate a custom mode VPC network with adual-stack subnet.

• To create a subnet with IPv6 enabled, seeAdd a dual-stacksubnet.

• To enable IPv6 in an existing subnet, seeChange a subnet's stack type todual stack.

• To create or enable VMs with IPv6, seeConfigure IPv6 for instances andinstance templates.

For information about using internal IPv6 ranges in your VPCnetwork and subnets, seeInternal IPv6specifications.

After configuring IPv6 in your VPC network, subnets, and VMs,configure your VLAN attachments.

Custom IP address ranges

When you create a VLAN attachment for Partner Interconnect,you can configure custom IP address ranges for the Cloud Router andcustomer router ends of the attachment. For information about how it works,including limitations and best practices, see theCustom IP address ranges section inthe Cloud Interconnect overview.

The process for creating VLAN attachments differs based on whether you requesta Layer 3 or Layer 2 connection from your service provider:

• Layer 2: when you configure custom IP address ranges for VLAN attachments thatyou use with Partner Interconnect, you must provide the customIP address ranges during VLAN creation. You can also add IPv6 custom IPaddress ranges when you upgrade your stack type fromIPV4_ONLY toIPV4_IPV6. To configure custom IP address ranges for Layer 2 connections,seeUse custom IP address ranges with Layer 2 connections.
• Layer 3: after you create a VLAN attachment and share it with your serviceprovider, they configure the custom IP address. This means that you don'tmanually configure custom IP address ranges when you configure your VLANattachment. Your service provider can also configure custom IP addresses whenyou upgrade an attachment's stack type fromIPV4_ONLY toIPV4_IPV6.

Restrict Partner Interconnect usage

By default, any VPC network can use Cloud Interconnect.To control which VPC networks can use Cloud Interconnect, you can set anorganization policy. For more information, seeRestrict Cloud Interconnect usage.

Limitations

You can't send and learn MED values over a Layer 3Partner 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.

What's next?

• To find answers to common questions about Cloud Interconnectarchitecture and features, see theCloud Interconnect FAQ.
• To find out more about Cloud Interconnect, see theCloud Interconnect overview.
• To learn about best practices when planning for and configuringCloud Interconnect, seeBest practices.
• To find Google Cloud resource names, see theCloud Interconnect APIs.