Professional Cloud Network Engineer

Provisioning Physical Cross-Cloud Interconnect Ports and High Availability Topologies

Cross-Cloud Interconnect provides dedicated physical network connections between Google Cloud and other cloud service providers. High availability designs require provisioning redundant physical circuits across separated infrastructure within a shared metropolitan region. Matching bandwidth capacity across all physical circuits ensures that the remaining links can support the full traffic load during a hardware failure.

Edge Availability Domains and Fault Isolation

Edge availability domains—also known as metro availability zones—are physically isolated network infrastructure segments within a metropolitan area that prevent a single facility or hardware failure from interrupting both connections. To configure a redundant physical topology, an administrator must provision the secondary connection in the same city as the primary connection while placing it in a different edge availability domain. Deploying two connections within the exact same edge availability domain creates a single point of failure and does not provide physical redundancy. Administrators can provision the redundant link inside the same colocation facility if that facility supports multiple edge availability domains, or they can choose a different colocation facility within that city.

Port Capacity and Identity Access Management

Port capacity settings and Identity and Access Management (IAM) permissions determine how physical Interconnect links are created and managed in a Google Cloud project. Administrators must verify project bandwidth quotas before placing an order to confirm that the project can support the requested circuit size. The bandwidth capacity of the secondary connection must match the primary connection to maintain symmetrical throughput during a failover. Provisioning these physical links requires specific IAM permissions:

• compute.interconnects.create
• compute.interconnects.get
• compute.interconnectLocations.get
• compute.interconnectLocations.list

Administrators obtain these permissions through the Compute Network Admin role (roles/compute.networkAdmin), or through broad project-level roles such as Owner (roles/owner) or Editor (roles/editor).

Configuring VLAN Attachments, Cloud Routers, and BGP Sessions

A VLAN attachment (also known as an interconnectAttachment) is a virtual interface that connects a single Google Cloud Virtual Private Cloud (VPC) network to a physical Interconnect connection. Deploying redundant VLAN attachments across separate physical circuits and linking them to Cloud Router instances establishes the foundation for dynamic routing between Google Cloud and external cloud environments.

Creating Redundant VLAN Attachments Across Interconnect Links

Redundant VLAN attachments provide continuous data path availability by connecting a VPC network to redundant physical links in different edge availability domains. To create a secondary connection in the Google Cloud console, an administrator inspects the primary connection under the Physical connections tab to identify its city, filters available locations by that same city, and selects a different edge availability domain. The secondary circuit capacity is configured to match the existing circuit capacity to prevent bandwidth bottlenecks during failover events. Once the physical links are established, administrators create VLAN attachments on each link and associate them with a Cloud Router to pass traffic into the VPC network.

Dynamic BGP Routing and Cloud Router Configuration

A Cloud Router uses the Border Gateway Protocol (BGP) to exchange dynamic network topology information between Google Cloud and remote routers. Each VLAN attachment links to a dedicated BGP session hosted on the Cloud Router. Through these BGP sessions, the Cloud Router advertises Google Cloud VPC subnet routes to the external cloud provider and dynamically learns routes to the remote cloud subnets. This dynamic exchange ensures that network traffic automatically redirects to an alternate healthy path if a specific VLAN attachment or circuit fails.

Implementing Multicloud Dynamic Routing Policies and Traffic Engineering

Multicloud dynamic routing policies use BGP path attributes to direct traffic along optimal network paths, prevent asymmetric routing, and protect stateful network appliances. Custom route advertisements and BGP metric controls determine how traffic enters and leaves Google Cloud across redundant VLAN attachments.

Traffic Engineering with BGP Metrics and Route Attributes

BGP attributes such as the Multi-Exit Discriminator (MED) and Autonomous System (AS) path prepending allow network administrators to influence inbound and outbound traffic paths. When a VPC network uses global dynamic routing mode, Google Cloud automatically adds a MED penalty equal to 200 plus the round-trip time (TTL) in milliseconds to routes learned outside a virtual machine's local region. This calculation ensures that Google Cloud VMs prefer local Interconnect attachments before using cross-region transit routes. When using a Network Connectivity Center hub to route traffic between spokes, all non-Google peer routers attached to the same hybrid spoke must use the same Autonomous System Number (ASN), while different spokes must use different ASNs to ensure valid route propagation.

Redundancy Modes, Traffic Symmetry, and Network Security

Redundant VLAN attachments operate in either Active-Active mode for distributed load sharing or Active-Standby mode for strict deterministic failover. In Active-Standby mode, setting different base route priorities on the Cloud Router BGP sessions makes the router prefer the primary attachment and route traffic through the standby attachment only if the primary fails. In Active-Active mode, total network throughput must not exceed the capacity of a single VLAN attachment, ensuring that a link outage does not overload the remaining attachment. By default, traffic traversing physical Interconnect links is unencrypted, but administrators can secure multicloud data in transit using MACsec encryption on the physical links or by establishing High Availability VPN (HA VPN) over Cloud Interconnect using IPsec tunnels.

Key Facts

• A redundant physical Interconnect connection must be provisioned in the same metropolitan area (city) as the primary connection but in a different edge availability domain.
• The Compute Network Admin role (roles/compute.networkAdmin) supplies the required permissions (compute.interconnects.create, compute.interconnects.get, compute.interconnectLocations.get, and compute.interconnectLocations.list) to manage Interconnect resources.
• Under global dynamic routing, Cloud Router automatically applies a MED penalty calculated as 200 plus the round-trip time in milliseconds to routes learned from outside the local region.
• Peer routers attached to a single Network Connectivity Center spoke must share the same ASN, whereas distinct spokes require distinct ASNs.
• Traffic over Cloud Interconnect is unencrypted by default, requiring MACsec on physical links or HA VPN over Cloud Interconnect tunnels when data encryption in transit is mandated.

Frequently Asked Questions

How do edge availability domains provide redundancy for physical Interconnect links?

Edge availability domains are isolated physical zones within a single metropolitan area. Placing the secondary connection in a different edge availability domain ensures that a power, hardware, or facility-level failure affecting the primary connection will not disrupt the secondary connection.

How does global dynamic routing prevent suboptimal cross-region transit paths?

Google Cloud automatically adds a MED penalty (200 plus the round-trip time in milliseconds) to BGP routes learned in distant regions. This metric penalty causes virtual machines to prefer exiting Google Cloud through local Interconnect attachments rather than routing through remote regions.

What is the bandwidth rule for operating VLAN attachments in an Active-Active configuration?

The combined peak traffic across all Active-Active VLAN attachments must not exceed the bandwidth limit of a single attachment. This restriction prevents network congestion and packet loss when one attachment fails and all traffic shifts onto the remaining healthy link.