Professional Cloud Network Engineer
Evaluating traffic flow patterns and identifying bandwidth bottlenecks on Cloud Interconnect requires understanding the traffic management tools available. Application-Aware Interconnect (AAI) is a traffic differentiation feature that allocates and shapes bandwidth across up to six traffic classes labeled TC1 through TC6. A bandwidth percentage policy assigns a specific percentage of the total interconnect capacity to each traffic class, and the assigned values across all configured classes must sum to exactly 100. Administrators can also apply a traffic shaping profile to define the maximum average bandwidth percentage that each traffic class can consume, with each value set to less than or equal to 100. Network control traffic, including Border Gateway Protocol (BGP) and Bidirectional Forwarding Detection (BFD), must always be included in the bandwidth policy to prevent routing failures. Traffic differentiation can be temporarily disabled on an interconnect or removed permanently by clearing the policy fields.
Physical and logical failures across hybrid connection components cause distinct service interruptions depending on network redundancy and protocol configurations. A physical link failure between the Google edge router and an on-premises router results in several minutes of downtime in the worst-case scenario, but traffic recovers in seconds if alternate paths exist. Failures of the Google edge router device cause a similar disruption, with traffic quickly rerouting when redundant physical links are available. In contrast, a Cloud Router maintenance event typically lasts less than 60 seconds and causes no traffic interruption when graceful restart is enabled. An on-premises router control plane failure causes a brief service pause when redundant routers exist, but it can result in several minutes of disruption in single-router environments.
Performance Dashboard is a network monitoring tool that tracks historical packet loss and latency metrics across Google Cloud zones and regions for up to six weeks. The dashboard displays directional traffic flows separately, allowing administrators to determine whether packet loss or latency spikes affect inbound or outbound paths for a specific zone pair. The latency summary view provides heatmaps where darker colors indicate high round-trip times between regions. Selecting a specific latency event opens a detailed timeline showing the exact duration of the spike and the virtual machines (VMs) involved. This diagnostic data helps administrators determine whether performance bottlenecks originate from inter-region transport delays or localized VM performance constraints.
Resource exhaustion occurs when a virtual machine network interface or operating system receives more traffic than it can process, leading to dropped packets, timeouts, and increased latency. Administrators can diagnose host performance by querying Cloud Logging for VM system events, such as host maintenance migrations, automatic restarts, or node preemptions. If VM lifecycle events are absent, running OS-level diagnostics like netstat -s reveals dropped ICMP packets, socket buffer overruns, and rejected TCP connections. In Linux environments, checking kernel logs for connection tracking table saturation identifies dropped packets, which can be resolved by increasing the net.netfilter.nf_conntrack_max limit or scaling workloads across additional instances. Intermittent issues occur unpredictably and require monitoring usage thresholds, whereas transient issues last for brief intervals and are typically managed by TCP retransmissions.
Cloud Load Balancing controls traffic distribution during degraded states by monitoring backend health and shifting requests away from saturated instances. A backend service uses a failover threshold, configured as a percentage between 1 and 99 with a default value of 70, to determine when primary backends are too degraded to serve traffic safely. When the proportion of healthy endpoints in the primary pool falls below this threshold, the load balancer shifts traffic to designated failover backends with remaining capacity. Setting the threshold too high causes unnecessary failovers during temporary health fluctuations, while setting it too low keeps traffic directed at failing instances. To prevent regional cascading failures during localized outages, administrators can configure traffic isolation in NEAREST mode to allow failover to neighboring regions, or STRICT mode to drop excess traffic rather than overloading adjacent regions.
Cloud Interconnect failures fall into four primary categories, each requiring specific corrective approaches. A link failure occurs when the physical connection between the Google edge router and the on-premises router goes downâin the best case, traffic reroutes through alternate paths within seconds, while the worst case involves several minutes of interruption. A Google edge router failure affects the connection between Cloud Router and the on-premises router, producing similar impacts with traffic shifting to redundant paths when available. A Cloud Router failure typically stems from maintenance events that complete in under 60 seconds and causes no impact when graceful restart is enabled on the BGP session. An on-premises router control plane failure creates the most significant disruption, potentially causing several minutes of service interruption while the on-premises equipment recovers.
Traffic differentiation policies let administrators influence how Cloud Interconnect handles traffic during both normal operations and failure scenarios. The configuration uses six traffic classes (TC1 through TC6), where each class receives a bandwidth percentage defining its guaranteed allocation and a shape average percentage controlling how traffic is metered. When implementing corrective actions, administrators adjust these traffic class percentages to prioritize critical workloads over less sensitive traffic. A critical requirement is including network control traffic such as BGP and BFD within the appropriate bandwidth percentage configurationâwithout this inclusion, control plane traffic may be starved during congestion, potentially worsening an existing failure.
Restoring service after a Cloud Interconnect failure requires verification through both active testing and monitoring. End-to-end connectivity tests confirm that traffic flows correctly between on-premises networks and Google Cloud resources, validating that BGP sessions have reestablished and that routing tables point to the appropriate next-hop interfaces. Cloud Interconnect Monitoring metrics provide visibility into link utilization, latency, and packet loss, allowing operators to confirm that performance has returned to acceptable levels. When redundant links exist, failover validation ensures traffic successfully traverses the alternate path and that the primary link can be restored without disrupting service. Monitoring dashboards should be checked continuously for a period after remediation to catch any intermittent issues that may not appear during initial testing.
The physical connectivity foundation is the Cloud Interconnect connection itself, which can be a Dedicated or Partner Interconnect. Its health is reflected in the state of the VLAN attachment resource. A VLAN attachment progresses through a defined lifecycle: it is first created in a PENDING_PARTNER state, moves to PENDING_CUSTOMER after the service provider completes their configuration, and finally becomes ACTIVE once the customer activates it. If an attachment remains stuck in PENDING_PARTNER for an extended period, the root cause typically lies with the service provider's configuration, and you must contact them for resolution. You can view the attachment's state, partner metadata, and pairing key using the console or the gcloud compute interconnects attachments describe command to verify the correct provider is involved.
Logical connectivity is established through Border Gateway Protocol (BGP) sessions between the Cloud Router and the on-premises or provider router. For Layer 2 Partner Interconnect and Dedicated Interconnect, you must configure the peer's ASN on the Cloud Router's BGP session. Session failures can stem from ASN mismatches, incorrect IP addressing, or authentication issues. The documentation specifies that for Partner Interconnect, the Cloud Router must use a fixed ASN of 16550. You can verify BGP peer details and session status using Cloud Router logs. Notably, you should not enable Bidirectional Forwarding Detection (BFD) at the Cloud Interconnect level for HA VPN over Interconnect deployments, as it does not accelerate failure detection for VPN tunnel traffic.
To isolate root causes, use Cloud Monitoring metrics and Interconnect Diagnostics. Key metrics to monitor include packet error counts and LACP status. For encrypted Interconnect scenarios like HA VPN over Interconnect, you must also monitor the health of the separate Cloud Router dedicated to the Interconnect tier (ASN 16550) and the HA VPN tier. The physical link state, including MACsec operational status if configured, can be diagnosed via the Interconnect details page or CLI. If a VLAN attachment is administratively enabled but traffic is not flowing, check that the on-premises router configuration matches the Cloud-side VLAN ID, BGP IPs, and MTU settings.
StudyCerts
StudyCertsPENDING_PARTNER, PENDING_CUSTOMER, and ACTIVE states, with a stuck PENDING_PARTNER state indicating a service provider configuration issue.16550.Configure traffic isolation in STRICT mode when you want to drop excess traffic during a regional outage rather than allow failover to neighboring regions, preventing those regions from becoming overloaded. Choose NEAREST mode when you want the load balancer to distribute traffic to healthy neighboring regions during localized failures.
Intermittent issues occur unpredictably and require continuous monitoring of usage thresholds to identify their patterns and causes. Transient issues last for brief intervals and are typically managed by TCP retransmissions, which handle the temporary drops in data without requiring direct administrative intervention.
BGP and BFD traffic must be included in the bandwidth percentage policy because without this inclusion, control plane traffic may be starved during congestion. If this traffic starves, the routing sessions can fail, potentially worsening an existing failure or causing a new one.
Prepare and test your skills
Prepare and test your skills