A VLAN attachment is a logical connection that allocates a VLAN on a Dedicated Interconnect or Partner Interconnect, enabling traffic exchange between an on-premises network and a Google Cloud Virtual Private Cloud (VPC) network through a Cloud Router. Each VLAN attachment supports a maximum bandwidth of 100 Gbps, and you can create multiple attachments on a single physical connection to use its full capacity. The attachment creates a pair of link-local IP addresses from the 169.254.0.0/16 rangeâone for the Cloud Router interface and one for your on-premises routerâused for Border Gateway Protocol (BGP) peering.
When you create a VLAN attachment, you must select a Cloud Router in a supported region and assign a unique VLAN ID between 2 and 4094 (or 100-4094 depending on the provider). The Cloud Router requires an autonomous system number (ASN)âyou can use 16550 or any private ASN in the range 64512-65534, excluding 65534. You can create the attachment through the Google Cloud console or by using the gcloud compute interconnects attachments dedicated create command, specifying the connection name, router, region, bandwidth, VLAN ID, and MTU. The default MTU is 1440 bytes, but you can also select 1460, 1500, or 8896 bytes; jumbo frames (8896) are supported only on unencrypted IPv4 and IPv6 attachments.
By default, Google Cloud automatically allocates a /29 IPv4 address range from the link-local space for the BGP session, assigning one address to the Cloud Router and another to your on-premises router. If you need custom IP addresses, you can specify a candidate link-local range using up to 16 prefixes within 169.254.0.0/16, each with a prefix length of /29 or shorter, or you can configure fully custom IP address ranges that are reserved as internal ranges within your VPC. For IPv6, you can specify custom address ranges using /125 or /126 prefixes, but you cannot use link-local or unique local addresses (ULA). Custom IP ranges require enabling the Network Connectivity API and the networkconnectivity.internalRanges.create permission granted by the Compute Network Admin role.
Each VLAN attachment requires a BGP session on the Cloud Router to exchange routes between your VPC network and on-premises network. To configure BGP, you create an interface on the Cloud Router linked to the VLAN attachment, then add a BGP peer that specifies the peer ASN (representing the on-premises router), the peer IP address (allocated by the attachment), and optional MD5 authentication for security. The peer ASN for on-premises routers varies by provider: AWS uses 64512-65534 or 4200000000-4294967294, Alibaba uses 45104, and Oracle Cloud Infrastructure uses 45104. MD5 authentication must be enabled and configured with the same secret key on both the Google Cloud side and the on-premises router side.
To fully utilize the bandwidth of a Dedicated Interconnect connection that exceeds 100 Gbps, you create multiple VLAN attachments in the same region and configure your on-premises router to advertise routes with the same Multi-Exit Discriminator (MED) value. When multiple routes have equal priority, Google Cloud uses equal-cost multipath (ECMP) routing with a five-tuple hash to distribute traffic across the attachments. Each attachment can have a different capacity setting (50 Mbps to 100 Gbps) that controls how much bandwidth that specific attachment can use, and the combined bandwidth of all attachments cannot exceed the physical connection capacityâfor example, a 20-Gbps attachment requires at least a 2x10-Gbps or 100-Gbps Dedicated Interconnect connection.
For HA VPN over Cloud Interconnect deployments, you create encrypted VLAN attachments using IPsec, which ensures all traffic through the attachment is encrypted. Encrypted VLAN attachments do not support dual-stack (IPv4 and IPv6) configurationsâattempting to create an encrypted dual-stack attachment fails. When deploying the 99.99% availability topology, you create encrypted attachments for both Cloud Interconnect connection pairs, using different regions and separate encrypted Cloud Routers for each pair. You must also specify regional internal IP address ranges (--ipsec-internal-addresses) for the HA VPN gateway interfaces created on each attachment.
If BGP sessions fail to establish, verify that the on-premises router is configured with multi-hop BGP (at least two hops for Dataplane version 1 attachments), that the neighbor IP address matches the cloudRouterIpAddress allocated to the VLAN attachment, and that the local ASN matches the peer ASN configured on the Cloud Router. Check that the VLAN ID on your on-premises router's subinterface matches the VLAN attachment's 802.1q tag, and confirm that the Cloud Interconnect connection and VLAN attachment are in an admin-enabled state. For HA VPN over Cloud Interconnect, ensure the BGP session for the Cloud Interconnect tier is established before troubleshooting the VPN tunnel tier, and verify that route advertisements include the HA VPN gateway addresses on both sides.
Dedicated Interconnect is a Google Cloud service that provides a direct, private physical connection between your on-premises network and Google's network. Planning and provisioning this infrastructure involves analyzing your bandwidth, redundancy, and latency needs, then executing a multi-step workflow to establish the connection and configure the logical network layer on top of it.
The provisioning workflow begins by analyzing your requirements to decide the number and location of connections. You must choose a colocation facility where Google's network is present, decide if you need MACsec for link-layer encryption, and determine the required bandwidth (e.g., 10 Gbps or 100 Gbps). You then order the Dedicated Interconnect connection. Google allocates resources and sends you a Letter of Authorization and Connecting Facility Assignment (LOA-CFA). You submit this LOA-CFA to your colocation vendor, who establishes the physical cross-connect between your router and Google's edge router. Finally, you and Google configure and test the Layer 1 and Layer 2 connectivity before the connection becomes ready for use.
After the physical connection is provisioned and active, you create VLAN attachments to establish the logical (Layer 3) network path. A VLAN attachment allocates a specific VLAN ID on the connection and associates it with a Cloud Router in your VPC network. The Cloud Router exchanges routes with your on-premises router via BGP. Routes advertised from on-premises become custom dynamic routes in your VPC, and the Cloud Router advertises your VPC subnet routes back to your on-premises network.
When creating a VLAN attachment, you must configure several key properties. You select a Cloud Router located in a region supported by your interconnect location. You specify a unique VLAN ID (between 2 and 4094). You can set the attachment's maximum transmission unit (MTU) to 1440, 1460, 1500, or 8896 bytes; using jumbo frames (8896) is only supported on unencrypted IPv4/IPv6 attachments. It is recommended to set the same MTU for all VLAN attachments connected to the same VPC network. You also define the attachment's capacity (bandwidth), which helps control how much of the connection's total bandwidth this specific logical path can use.
For production-level reliability, you must create redundant connections and VLAN attachments. The Cloud Interconnect SLA requires at least a primary and a redundant connection, each in a different edge availability domain within a metropolitan area, to achieve 99.9% availability. For 99.99% availability, you need two pairs of connections across two different metropolitan areas. You create a redundant pair of VLAN attachments by selecting both your primary and redundant interconnect ports during creation. You can associate them with the same Cloud Router or different routers in the same region, and you typically use the same VLAN ID for both attachments in the pair.
Dedicated Interconnect uses fixed port pricing. You are billed hourly for the connection and for each VLAN attachment. Data transfer out from your VPC through the interconnect is discounted compared to general network egress pricing. Pricing distinguishes between local connections (where the VLAN attachment's metro location and the destination Google Cloud region are the same) and remote connections (where they differ). Some Google Cloud regions only support fixed pricing for remote connections. For troubleshooting during provisioning, you should reply directly to the LOA-CFA email from Google for faster support.
Monitoring, troubleshooting, and optimizing Dedicated Interconnect involves diagnosing physical and data-link connectivity, verifying Border Gateway Protocol (BGP) session states on Cloud Router, and tuning routing parameters to maximize hybrid network throughput. Network engineers must ensure correct Link Aggregation Control Protocol (LACP) configurations, manage Maximum Transmission Unit (MTU) sizing across endpoints, and optimize BGP keepalive and hold timers to maintain high availability.
Physical link validation requires testing circuit connectivity and port channel aggregation before VLAN attachments can pass production traffic. During provisioning, Google validates connectivity by pinging temporary IP addresses configured on the customer router interfaces. For multiple-link bundles, testing occurs first on each individual physical link without LACP, after which testing moves to the port channel bundle interface with LACP enabled in active or passive mode. For single-link bundles, the port channel must still have LACP configured before the link can pass the single-circuit ping test. If Google cannot ping the on-premises router during testing, verify that the assigned test IP addresses are applied to the correct physical or bundle interfaces and that LACP settings match Google specifications. When testing production throughput and latency, do not ping the Cloud Router interface directly because control plane rate limiting distorts results; instead, deploy and test traffic between a Compute Engine virtual machine (VM) instance in the VPC network and an on-premises host.
BGP session failures on Cloud Router occur when Layer 3 configurations, Autonomous System Numbers (ASNs), or peering IP addresses mismatch between Google Cloud and the on-premises peer router. Administrators inspect the operational state of a BGP session by running the gcloud compute routers get-status command against the target Cloud Router. To establish peering, both the Dedicated Interconnect connection and the VLAN attachment must be in an admin-enabled and ACTIVE state. Each VLAN attachment allocates a /29 IPv4 link-local subnet from the 169.254.0.0/16 range, assigning cloudRouterIpAddress to the Cloud Router interface and customerRouterIpAddress to the on-premises subinterface. The on-premises router must configure its BGP neighbor address to match the Cloud Router link-local IP address and use the configured peer ASN. For VLAN attachments running Dataplane version 1, configure EBGP multi-hop on the customer router with a time-to-live (TTL) value of at least 2 (recommended value 4). VLAN attachments operating on Dataplane version 2 or higher do not require EBGP multi-hop unless specified by custom network architecture.
BGP timer optimization ensures rapid route convergence and minimal traffic loss during link transitions or scheduled Cloud Router maintenance. Configuring custom BGP keepalive and hold timers controls how fast routers detect path failures and redirect traffic to alternate paths. Setting the BGP keepalive timer to 20 seconds and the hold timer to 60 seconds allows Google Cloud and the on-premises peer to quickly detect link failures and shift traffic to redundant connections. Enabling BGP graceful restart on the on-premises router prevents session drops and packet loss during routine maintenance on Cloud Router. Set the graceful restart stalepath timer to 300 seconds so the on-premises router preserves existing forwarding paths while the Cloud Router control plane restarts. When utilizing Bidirectional Forwarding Detection (BFD) for rapid link failure detection, do not configure EBGP multi-hop because Google Cloud supports only single-hop BFD sessions.
Maximizing Dedicated Interconnect performance requires managing MTU packet limits and distributing traffic across multiple VLAN attachments. Google Cloud supports VLAN attachment MTU settings of 1440, 1460, 1500, and 8896 bytes (jumbo frames). To achieve higher throughput without packet fragmentation, the MTU on the VLAN attachment, the VPC network, and the on-premises router interfaces must all match; jumbo frame support (8896 bytes) applies only to unencrypted IPv4 and IPv6 attachments. When traffic demands exceed a single VLAN attachment limit, provision multiple attachments within the same Google Cloud region. When the on-premises router advertises dynamic routes with identical Multi-Exit Discriminator (MED) values across these attachments, Google Cloud implements Equal-Cost Multipath (ECMP) routing. Traffic distributes across the active attachments based on a five-tuple hash, balancing the workload across physical circuits. When utilizing MACsec for Cloud Interconnect on high-bandwidth 100-Gbps circuits, select the GCM-AES-256-XPN cipher suite instead of standard GCM-AES-256 to prevent packet drops caused by control plane overload.
Troubleshooting HA VPN over Dedicated Interconnect requires diagnosing the underlying physical interconnect tier before resolving the encrypted VPN overlay tier. If the base VLAN attachment or its associated BGP session is down, the HA VPN tunnels routed over that attachment cannot establish. Verify that the dedicated Cloud Router used for the Interconnect tier is exclusively assigned to the encrypted VLAN attachments and is not shared with unencrypted attachments or VPN tunnels. Run gcloud compute vpn-tunnels describe to check the status of the IPsec tunnel. If the tunnel fails to establish, inspect the advertisedRoutes field on the Interconnect Cloud Router using gcloud compute routers get-status to verify that regional internal IP address ranges (--ipsec-internal-addresses) are being advertised to the peer router. Ensure that on-premises BGP announcements include the customer VPN gateway addresses, and verify that there are no route conflicts with existing dynamic routes in the VPC network. Once the IPsec tunnel establishes, verify the secondary BGP session on the HA VPN Cloud Router to restore end-to-end VPC traffic forwarding.
Both provide a direct private connection between your on-premises network and Google Cloud, but Dedicated Interconnect uses dedicated physical ports at a Google colocation facility while Partner Interconnect uses a supported service provider's network to reach Google Cloud.
Set the BGP keepalive timer to 20 seconds and the hold timer to 60 seconds for faster failure detection, and enable BGP graceful restart with a 300-second stalepath timer to preserve forwarding during Cloud Router maintenance.
Use jumbo frames only on unencrypted IPv4 and IPv6 attachments, and ensure the MTU matches on the VLAN attachment, VPC network, and on-premises router interfaces to avoid fragmentation and maximize throughput.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts