Professional Cloud Network Engineer

Creating Dedicated Interconnect connections and configuring VLAN attachments.

Dedicated Interconnect is a Google Cloud service that provides a direct, private physical connection between an on-premises network and Google's network. Planning and provisioning this infrastructure involves a multi-step workflow: you analyze bandwidth and redundancy needs, choose a colocation facility where Google's network is present, order the connection, and use a provided Letter of Authorization (LOA) to have your colocation vendor establish the physical cross-connect. After the physical Layer 1 and 2 connectivity is tested and active, you create logical VLAN attachments on top of it to enable Layer 3 routing.

A VLAN attachment allocates a specific VLAN on a Dedicated Interconnect connection, creating a logical path into a Virtual Private Cloud (VPC) network. Each attachment supports up to 100 Gbps, and you can create multiple attachments on a single physical connection to use its full capacity. When you create an attachment, you must select a Cloud Router in a supported region, assign a unique VLAN ID, and set properties like the Maximum Transmission Unit (MTU)—which can be 1440, 1460, 1500, or 8896 bytes (jumbo frames). Jumbo frames are only supported on unencrypted IPv4 and IPv6 attachments. The attachment automatically allocates a pair of link-local IP addresses from the 169.254.0.0/16 range for Border Gateway Protocol (BGP) peering between the Cloud Router and your on-premises router.

You configure BGP sessions by adding a BGP peer on the Cloud Router, specifying the peer ASN of your on-premises router and the peer IP address provided by the attachment. For high availability, you must create redundant connections and VLAN attachments. To achieve a 99.9% availability SLA, you need a primary and a redundant connection in different edge availability domains within the same metropolitan area. For 99.99% availability, you need two pairs of connections across two different metropolitan areas. To distribute traffic and maximize throughput across multiple VLAN attachments, you configure your on-premises router to advertise routes with identical Multi-Exit Discriminator (MED) values; Google Cloud then uses equal-cost multipath (ECMP) routing with a five-tuple hash to balance the load.

You can also create encrypted VLAN attachments for HA VPN over Cloud Interconnect, which uses IPsec to encrypt all traffic over the physical link. Encrypted attachments do not support dual-stack (IPv4 and IPv6) configurations. Monitoring and troubleshooting involve checking the physical link and LACP configurations, verifying BGP session states on the Cloud Router, and ensuring MTU settings match across the VPC network, VLAN attachment, and on-premises router to avoid fragmentation.

Creating Partner Interconnect connections, configuring VLAN attachments, and differentiating between layer 2 and layer 3 type interconnects.

Partner Interconnect connects an on-premises network to Google Cloud through a supported third-party service provider's network, which is useful when you cannot reach a Google colocation facility directly or need capacity below 10 Gbps. The key architectural choice is between Layer 2 and Layer 3 operation, which determines who manages the BGP routing.

A Layer 2 Partner Interconnect is a bridged VLAN where the service provider establishes a data link layer path. The customer is responsible for configuring and managing the BGP session directly between their on-premises router and the Google Cloud Cloud Router. This model gives you direct control over routing policies, allows the use of BGP attributes like the Multi-Exit Discriminator (MED) to influence traffic, and provides granular IP address management.

A Layer 3 Partner Interconnect is a routed VLAN where the service provider manages the BGP session between their router and the Cloud Router. The customer only creates the VLAN attachment; Google automatically configures the Cloud Router with the provider's ASN. Because MED values cannot traverse separate autonomous systems, you cannot use MED to influence route priorities in a Layer 3 setup. This model minimizes administrative overhead by offloading routing management to the provider.

For both types, you create a VLAN attachment in your Google Cloud project, associate it with a Cloud Router (which must use the Google ASN 16550), and receive a unique pairing key. You give this key to your service provider so they can provision their side of the link. The attachment lifecycle moves from PENDING_PARTNER (waiting for the provider) to PENDING_CUSTOMER (ready for you to activate) to ACTIVE. For Layer 3, you can enable pre-activation so the attachment becomes ACTIVE automatically after the provider finishes, skipping the manual step. For high availability, a 99.9% SLA requires at least two VLAN attachments in one region, split across two edge availability domains. A 99.99% SLA requires at least four attachments across two regions and two metros.

Creating Cross-Cloud Interconnect connections and configuring VLAN attachments.

Cross-Cloud Interconnect provides dedicated physical connections between Google Cloud and other cloud providers like AWS or Azure. High availability requires provisioning redundant physical circuits in the same metropolitan area but in different edge availability domains, which are physically isolated infrastructure segments. This ensures a facility or hardware failure doesn't take down both links. You must verify project bandwidth quotas and have the Compute Network Admin role (or equivalent permissions) to create these interconnects.

After the physical links are provisioned, you create VLAN attachments on each link to connect them to your Virtual Private Cloud (VPC) network. Each VLAN attachment is associated with a Cloud Router, which uses BGP to dynamically exchange routes between your Google Cloud subnets and the remote cloud's networks. This dynamic routing allows traffic to automatically fail over to the healthy link if one fails.

You can engineer traffic paths using BGP attributes. For example, when a VPC uses global dynamic routing, Cloud Router automatically adds a MED penalty (200 plus the round-trip time in milliseconds) to routes learned outside a VM's local region. This makes VMs prefer exiting through a local interconnect attachment. Redundant VLAN attachments can operate in Active-Active mode for load sharing or Active-Standby mode for deterministic failover. Traffic over these physical links is unencrypted by default; you can add encryption using MACsec on the physical links or by deploying HA VPN over Cloud Interconnect.

Configuring HA VPN over Cloud Interconnect.

HA VPN over Cloud Interconnect combines the high throughput of a physical Cloud Interconnect link with the encryption of IPsec VPNs. It is used to create a private, encrypted connection between an on-premises network and Google Cloud. In this architecture, IPsec tunnels terminate on private regional IP addresses assigned to the VLAN attachments, not on public IP addresses, so traffic never touches the public internet.

You deploy an HA VPN gateway, a regional resource with two interfaces, over your Dedicated or Partner Interconnect VLAN attachments. Each interface binds to a VLAN attachment. You then create VPN tunnels from each HA VPN gateway interface to corresponding interfaces on your on-premises VPN gateway, configuring matching IKE pre-shared keys and settings. IKE version 2 (IKEv2) is the default and is required for IPv6 traffic.

A dedicated Cloud Router manages dynamic BGP sessions inside these IPsec tunnels, using link-local IP addresses (typically from 169.254.0.0/30). The Cloud Router exchanges routes with your on-premises router, enabling automatic failover if a tunnel fails. To achieve a 99.99% availability SLA, you need a highly redundant topology: redundant HA VPN gateways, dual Cloud Routers, and dual Cloud Interconnect connections deployed across two separate metropolitan areas or regions.

Configuration requires careful attention to the Maximum Transmission Unit (MTU), as IPsec and VLAN encapsulation add overhead. Cloud VPN tunnels have a default MTU of 1460 bytes, but you may need to lower this if path MTU discovery finds a smaller MTU. You must also ensure cryptographic parameters (like IKE/IPsec lifetimes and Diffie-Hellman groups) match exactly between Google Cloud and your on-premises gateway to prevent tunnel instability.

Implementing 99.9% and 99.99% service-level agreements (SLAs) for interconnect topologies.

Implementing specific Service Level Agreements (SLAs) for Cloud Interconnect requires designing redundant physical and logical topologies. The SLA you can achieve depends on the number, location, and configuration of your connections and VLAN attachments.

To implement a 99.9% availability SLA, you need at least two connections in the same metropolitan area. These connections must be placed in different edge availability domains (like zone1 and zone2) to ensure they are in isolated maintenance zones. You then create VLAN attachments on each connection. For Partner Interconnect, these attachments must be in the same Google Cloud region. The VPC network should use regional dynamic routing so the Cloud Router can manage failover between the attachments.

To implement a 99.99% availability SLA, you need a more geographically dispersed design. This requires two pairs of connections, with each pair in a different metropolitan area. You need at least four VLAN attachments total—a pair in each metro, with each attachment in a pair placed in a different edge availability domain. Furthermore, the VPC network must be configured for global dynamic routing mode. This allows Cloud Routers in different regions to advertise all subnet routes everywhere, enabling cross-region failover if an entire region or metro becomes unavailable. This design protects against failures at the level of a metropolitan area or regional Google Cloud facility.

Key Facts

• A VLAN attachment allocates a logical VLAN on a Cloud Interconnect connection, supports up to 100 Gbps, and provides link-local IPs for BGP peering between Cloud Router and an on-premises router.
• Layer 2 Partner Interconnect requires the customer to manage the BGP session, while Layer 3 offloads BGP management to the service provider and cannot use MED values for traffic engineering.
• For physical redundancy, a secondary Interconnect connection must be in the same city as the primary but in a different edge availability domain.
• HA VPN over Cloud Interconnect terminates IPsec tunnels on private regional IP addresses assigned to VLAN attachments, not on public IPs, keeping all traffic on private links.
• A 99.9% SLA requires two connections/VLAN attachments in one metro across two edge availability domains; a 99.99% SLA requires four attachments across two metros with global dynamic routing enabled.

Frequently Asked Questions

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

In Layer 2, you configure and manage the BGP session between your on-premises router and Google's Cloud Router. In Layer 3, the service provider manages that BGP session with Google, so you do not configure BGP peers on the Cloud Router, but you lose the ability to use MED values for traffic influence.

How does Cross-Cloud Interconnect achieve high availability?

High availability is achieved by provisioning a redundant physical connection in the same metropolitan area as the primary connection, but placing it in a different edge availability domain. This ensures a facility or hardware failure affecting one domain does not impact the other.

Why is a dedicated Cloud Router required for HA VPN over Cloud Interconnect?

An HA VPN gateway requires a Cloud Router dedicated to managing its BGP sessions over the IPsec tunnels. This Cloud Router cannot be shared with BGP sessions for other services like unencrypted Partner Interconnect VLAN attachments, ensuring clean routing separation and management.

What are the infrastructure requirements to meet a 99.99% SLA for Cloud Interconnect?

You need two pairs of Cloud Interconnect connections, with each pair in a different metropolitan area. This requires at least four VLAN attachments total. Your VPC network must use global dynamic routing so routes are propagated across all regions, enabling traffic to reroute across metros if one fails.