Professional Cloud Network Engineer

Differentiate Between Layer 2 and Layer 3 Interconnect Architectures

Layer 2 Partner Interconnect

A Layer 2 Partner Interconnect connection is a bridged VLAN that connects your on-premises network to Google Cloud at the data link layer. The interconnect itself does not make routing decisions; instead, you configure the Border Gateway Protocol (BGP) session directly between your on-premises router and Cloud Router. After creating the VLAN attachment, you must add your on-premises Autonomous System Number (ASN) to each BGP peer on the Cloud Router. Choose Layer 2 when you need direct control over routing policies, want to use Multi-Exit Discriminator (MED) values to influence traffic flow, or require granular control over IP address assignment and route propagation.

Layer 3 Partner Interconnect

A Layer 3 Partner Interconnect connection is a routed VLAN in which the service provider manages the BGP session between their on-premises router and Cloud Router. You only need to create the VLAN attachment and ensure the Cloud Router has the required ASN of 16550; Google automatically configures the Cloud Router with your service provider’s ASN. Because MED values cannot pass through autonomous systems, Cloud Router cannot learn MED values from your on-premises router or send MED values to it, so you cannot use MED to set route priorities. Choose Layer 3 when you want to minimize administrative overhead, offload routing management to the service provider, or run a simpler operational model without BGP configuration responsibilities.

Comparing Operational Models and Administrative Overhead

The fundamental difference between Layer 2 and Layer 3 Partner Interconnect is who owns BGP configuration and route management. With Layer 2, your team must configure the on-premises router with interface addresses, peering addresses, and ASN values, and you handle troubleshooting. With Layer 3, the service provider handles BGP peer establishment, route filtering, and path selection, so you interact mainly with the VLAN attachment on the Google Cloud side. MED values are usable only in Layer 2 because you directly control the BGP session. Layer 3 also supports pre-activation, which lets a VLAN attachment pass traffic immediately after the provider finishes configuration without a separate activation step in the console.

Network Design and IP Address Management Implications

Layer 2 gives you more flexibility in network design because you control the full path and can implement complex routing policies. With Layer 2, you can configure custom BGP peering IP ranges, specify VLAN IDs, and influence traffic with BGP attributes such as MED, local preference, and AS path manipulation. Layer 3 limits these options because the service provider controls the routing domain and you inherit the provider’s addressing and topology. Both models support redundant VLAN attachments in different edge availability domains within the same metro, but Layer 2 gives you more control over failover behavior through BGP path selection.

Configure and Manage VLAN Attachments

Creating a VLAN Attachment

A VLAN attachment for Partner Interconnect is a Google Cloud resource that logically connects your Virtual Private Cloud (VPC) network to your on-premises network through a service provider. You create it in a specific Google Cloud region and associate it with a pre-configured Cloud Router. The Cloud Router must use the local ASN 16550 for all Partner Interconnect connections. When the attachment is created, Google Cloud generates a unique pairing key; you share this key with your service provider, not your project or resource names, to request the physical connection. The attachment starts in the PENDING_PARTNER state and remains there while the provider configures their side of the link.

Activating a VLAN Attachment

After the service provider completes their configuration, the VLAN attachment changes from PENDING_PARTNER to PENDING_CUSTOMER. You must then activate the attachment in Google Cloud before it can pass traffic, using the --admin-enabled flag in the gcloud command or the Activate button in the console. For Layer 3 connections, you can optionally pre-activate the attachment during creation. Pre-activation skips the manual step, so traffic flows as soon as the provider finishes configuration.

Configuring BGP for Layer 2 Connections

For Layer 2 Partner Interconnect, the customer is responsible for the BGP session between the on-premises router and Cloud Router. Google Cloud automatically creates a BGP peer on the associated Cloud Router when the VLAN attachment is made, but you must update that peer with the ASN of your on-premises router. The command flow is to first describe the Cloud Router to find the name of the managed BGP peer, then update that peer with your on-premises ASN. For Layer 3 connections, the service provider manages the BGP session, so no customer BGP configuration is needed on Cloud Router.

Managing Attachment Lifecycle and Redundancy

You manage VLAN attachments over their lifecycle, including updates and deletions. For high availability, create redundant attachments in separate edge availability domains within the same metropolitan area. For a 99.9% availability SLA, you need at least two attachments in one region, and each redundant attachment should use the same Cloud Router; Cloud Router uses multiple software tasks for failover. Retrieve a unique pairing key for each attachment and give all of them to the service provider so the redundant connections can be established.

Design and Provision Partner Interconnect Connections

Partner Interconnect Overview

Partner Interconnect is a Google Cloud hybrid connectivity service that connects an on-premises network to a Virtual Private Cloud (VPC) network through a supported third-party service provider. It is used when a data center cannot physically reach a Google colocation facility or needs capacity lower than the standard dedicated 10 Gbps or 100 Gbps links. The service provider owns and manages the underlying physical connection in their project, while the customer creates and manages the logical VLAN attachments and Cloud Router in their own Google Cloud project.

Layer 2 versus Layer 3 Partner Interconnect

Partner Interconnect can operate as a Layer 2 or Layer 3 connection, and that choice determines who manages the Border Gateway Protocol (BGP) session with Google Cloud. In both models, the customer configures a Cloud Router with the mandatory Google ASN 16550, and Google automatically allocates BGP peering IP addresses from the 169.254.0.0/16 link-local range. In a Layer 2 connection, the provider establishes a data link layer path and the customer configures and maintains the BGP session between the on-premises router and Cloud Router, manually providing the on-premises ASN in Google Cloud. In a Layer 3 connection, the provider terminates the BGP session on their router and exchanges routes directly with Cloud Router, and Google automatically configures the provider’s ASN without customer input. Because MED values do not traverse separate autonomous systems, Layer 3 cannot propagate or learn MED values between the two sides.

Provisioning Workflow and Pairing Keys

Provisioning Partner Interconnect follows an ordered sequence: create resources in Google Cloud, share a pairing key with the service provider, and activate the attachment. First, create a VPC network with custom subnets and deploy a Cloud Router assigned to ASN 16550. Second, create a VLAN attachment (interconnectAttachment), which starts in the PENDING_PARTNER state and outputs a unique pairing key. Third, provide the pairing key, desired capacity, and connection location to the service provider so they can provision the VLAN circuit. After the provider finishes, the attachment changes to PENDING_CUSTOMER; the customer inspects the partnerMetadata to confirm the correct provider fulfilled the request, then activates the attachment with --admin-enabled to move it to ACTIVE. For Layer 3, pre-activation can be enabled during creation so the attachment becomes ACTIVE automatically once the provider finishes, bypassing manual verification and activation.

Designing for 99.9% and 99.99% Availability

High-availability Partner Interconnect designs place VLAN attachments across isolated maintenance zones called edge availability domains (zone1 and zone2) and use dynamic routing across Google Cloud regions. Scheduled maintenance windows are isolated between edge availability domains within the same metro, but they are not coordinated across different metros. For 99.9% availability, deploy at least two VLAN attachments within a single region and single metro, split across two edge availability domains, and connect both to at least one Cloud Router; Cloud Router uses two internal software tasks for route processing redundancy. For 99.99% availability, deploy at least four VLAN attachments across two separate regions and two metros, with a pair in each metro split across two edge availability domains and connected to a dedicated Cloud Router in that region. To reach 99.99%, set the VPC dynamic routing mode to global so Cloud Routers advertise all subnets across all regions and propagate learned on-premises routes everywhere, allowing cross-region traffic rerouting during a regional failure.

Key Facts

• In Layer 2 Partner Interconnect, the customer configures and manages the BGP session between the on-premises router and Cloud Router; in Layer 3 Partner Interconnect, the service provider manages that BGP session.
• Every Partner Interconnect Cloud Router must use the Google ASN 16550, and Google allocates BGP peering IP addresses from the 169.254.0.0/16 link-local range.
• A VLAN attachment starts in PENDING_PARTNER, changes to PENDING_CUSTOMER after the service provider finishes, and becomes ACTIVE only after the customer activates it, unless Layer 3 pre-activation is enabled.
• A 99.9% availability Partner Interconnect design needs at least two VLAN attachments in one region split across two edge availability domains; a 99.99% design needs at least four attachments across two regions and two metros.
• MED values cannot cross autonomous systems, so Layer 3 Partner Interconnect cannot use MED to set route priorities.

Frequently Asked Questions

What is the difference between Layer 2 and Layer 3 Partner Interconnect?

Layer 2 Partner Interconnect is a bridged VLAN where the customer manages the BGP session between the on-premises router and Cloud Router. Layer 3 Partner Interconnect is a routed VLAN where the service provider manages the BGP session and route exchange, so the customer does not configure BGP on Cloud Router.

When should I choose Layer 3 instead of Layer 2 Partner Interconnect?

Choose Layer 3 when you want to minimize administrative overhead and let the service provider handle routing management. Choose Layer 2 when you need direct control over routing policies, BGP attributes such as MED, or granular IP address management, because Layer 3 cannot use MED values.

What is pre-activation and when would I use it?

Pre-activation is a Layer 3 option that lets a VLAN attachment move to ACTIVE automatically as soon as the service provider finishes configuration. Use it to skip the manual activation step and allow traffic to flow immediately after the provider completes their side.

How many VLAN attachments do I need for high availability?

For a 99.9% availability SLA, use at least two VLAN attachments in one region split across two edge availability domains. For a 99.99% availability SLA, use at least four VLAN attachments across two regions and two metros, with global dynamic routing enabled in the VPC.