Professional Cloud Network Engineer
Drain mode is a backend configuration that gracefully halts new connections while allowing existing, active sessions to finish before scheduled maintenance begins. When an administrator places a backend service into a draining state, the Application Load Balancer immediately stops routing new client requests to those instances. The load balancer continues forwarding traffic for established connections, such as active file transfers or WebSocket sessions, until they finish or time out. Health checks continue running while a backend drains, but the draining state overrides a healthy status so the load balancing data plane excludes the instance from new traffic pools. After maintenance concludes, an administrator must manually remove the backend from drain mode, as it does not return to service automatically.
Weighted backend services enable gradual traffic shifting between different backend groups by assigning relative weight values to each service in a routing rule. Traffic flows to each backend proportionally based on its assigned numerical weight, allowing operators to route a small fraction of traffic to a new software version before shifting the full workload. When weighted traffic splitting is applied within a route rule, it takes precedence over and overrides any session affinity configured on the target backend services. For high-availability architectures, regional and global Application Load Balancers support active-passive and active-active failover designs. In active-passive setups, Cloud DNS failover routing policies redirect traffic to standby regional load balancers when health checks detect primary failures, while active-active setups use Cloud DNS geolocation routing to direct users to the nearest healthy region.
A URL map serves as the central control plane component that evaluates incoming request attributes to direct traffic to backend services, backend buckets, or redirection endpoints. Incoming requests pass from a forwarding rule through a target HTTP proxy or target HTTPS proxy, which references the URL map to process the traffic. The URL map first evaluates host rules against the domain name; once matched, it directs the request to a designated path matcher. Simple path routing matches requests using a longest-prefix-wins approach regardless of rule order, whereas advanced route rules evaluate matches sequentially according to integer priority values where 0 is the highest priority. If an incoming request fails to match specific host or path rules, it flows to defined fallback defaults, such as the top-level defaultService or a path matcher's default redirect.
StudyCerts
StudyCertsIncoming Request
│
▼
[ Forwarding Rule ]
│
▼
[ Target Proxy ] (HTTP / HTTPS)
│
▼
[ URL Map ] ──(Evaluates Host Rules)──► [ Path Matcher ]
│
┌─────────────────────────────┴─────────────────────────────┐
▼ ▼
[ Simple Path Rules ] [ Advanced Route Rules ]
(Longest prefix matches) (Evaluated by priority: 0, 1, 2...)
│ │
└─────────────────────────────┬─────────────────────────────┘
│
▼
[ Target Backend / Redirection ]
Traffic routing components must strictly align with the regional or global scope and the load balancing scheme of the deployment. Global external Application Load Balancers require global URL maps (urlMaps) referencing global backend services (backendServices), whereas regional external Application Load Balancers require regional URL maps (regionUrlMaps) referencing regional backend services (regionBackendServices) located in that same region. Administrators can test routing logic before deployment by embedding a test array within the URL map YAML configuration and running the command gcloud compute url-maps validate. This command verifies the rules against specified test scenarios without applying changes to live environments. If a test fails during validation or import, the system generates an error identifying the route mismatch and blocks the configuration from deploying.
A Google Cloud High Availability VPN (HA VPN) gateway is a regional networking resource that provides encrypted hybrid connectivity backed by a 99.99% availability service level agreement (SLA). The HA VPN gateway provisions two interfaces, interface 0 and interface 1, each assigned a unique external IP address. To achieve the 99.99% SLA, active VPN tunnels must be established across both interfaces to an external peer VPN gateway. Google Cloud supports three external peer gateway redundancy models:
SINGLE_IP_INTERNALLY_REDUNDANT for a single peer device using one IP address on interface 0.TWO_IPS_REDUNDANCY for two distinct peer devices or a dual-homed device using IP addresses on interfaces 0 and 1.FOUR_IPS_REDUNDANCY for peer networks, such as alternative cloud providers, that expose four IP addresses across interfaces 0 through 3. ┌──────────────────────────────┐
│ Google Cloud HA VPN │
│ ┌────────────┐┌────────────┐ │
│ │Interface 0 ││Interface 1 │ │
└─┴─────┬──────┴┴─────┬──────┴─┘
│ │
Tunnel 0 │ │ Tunnel 1
▼ ▼
┌──────────────────────────────┐
│ External Peer VPN Gateway │
│ • SINGLE_IP_INTERNALLY_... │
│ • TWO_IPS_REDUNDANCY │
│ • FOUR_IPS_REDUNDANCY │
└──────────────────────────────┘
Dynamic routing for HA VPN tunnels is managed exclusively by Cloud Router using Border Gateway Protocol (BGP) sessions over link-local addresses. When an administrator creates a Cloud Router, they assign a private autonomous system number (ASN) from 64512 through 65534 or 4200000000 through 4294967294, which remains fixed for the router's lifecycle. Each BGP session uses a /30 link-local IPv4 subnet from the 169.254.0.0/16 range to peer with the on-premises gateway. When both tunnels advertise identical BGP route priorities, Cloud Router balances egress traffic across both paths in an active/active Equal-Cost Multi-Path (ECMP) setup. Setting asymmetric advertised route priorities configures an active/passive model, directing all outbound traffic to the tunnel with the lower numerical priority metric until that session fails.
Diagnosing VPN connectivity failures requires verifying cryptographic handshakes, packet size limits, and firewall access in a specific order. IPsec negotiations fail during Phase 1 if the pre-shared key (PSK) contains a character mismatch or if the gateways disagree on cipher suites, and negotiations fail during Phase 2 if traffic selectors do not match. Encapsulating network packets inside IPsec headers increases overall frame size, causing packet drops when the packet exceeds the path Maximum Transmission Unit (MTU); enabling TCP Maximum Segment Size (MSS) clamping prevents this data path fragmentation. Network security policies must allow inbound and outbound User Datagram Protocol (UDP) port 500 for IKE, UDP port 4500 for NAT traversal, Encapsulating Security Payload (ESP) traffic, and Transmission Control Protocol (TCP) port 179 for BGP. For HA VPN over Cloud Interconnect architectures, administrators must confirm that the physical Interconnect connection and its base BGP session are operational before troubleshooting the overlay IPsec configuration.
Application-Aware Interconnect (AAI) is a capacity management feature that allocates and shapes bandwidth across up to six distinct traffic classes labeled TC1 through TC6. Administrators apply a bandwidth percentage policy where the allocations across all defined classes must sum to exactly 100 percent. A traffic shaping profile sets the maximum average bandwidth percentage each class can consume, with each value configured to less than or equal to 100. Network control plane traffic, specifically BGP and Bidirectional Forwarding Detection (BFD), must always be assigned bandwidth within the policy to prevent session drops during high-utilization periods. If traffic differentiation is no longer needed, administrators can temporarily pause the policy or delete it entirely to restore standard default queuing.
Hybrid interconnect failures impact traffic differently depending on the specific component that fails. A physical link or Google edge router failure causes brief interruptions, but traffic recovers within seconds if redundant physical connections exist. Scheduled maintenance on a Cloud Router lasts under 60 seconds and produces zero data plane disruption when BGP graceful restart is enabled. The Performance Dashboard tracks historical packet loss and latency heatmaps across Google Cloud regions for up to six weeks to help isolate network transport bottlenecks. Host-level resource exhaustion—such as Linux connection tracking table saturation—can be identified in kernel logs and resolved by raising the net.netfilter.nf_conntrack_max limit or distributing traffic across additional virtual machine instances.
A VLAN attachment connects a dedicated or partner physical link to a Cloud Router and progresses through a sequential lifecycle. The attachment begins in a PENDING_PARTNER state upon creation, transitions to PENDING_CUSTOMER after the interconnect service provider completes their configuration, and becomes ACTIVE once the customer confirms and activates the attachment. If an attachment remains in PENDING_PARTNER, the issue resides with the service provider's provisioning steps. For Partner Interconnect deployments, the Cloud Router must use Google's fixed ASN of 16550. For Layer 2 Partner and Dedicated Interconnects, logical BGP sessions establish between Cloud Router and the remote router, but administrators should not configure BFD at the Interconnect layer when deploying HA VPN over Interconnect.
[ PENDING_PARTNER ] ──(Provider configures)──► [ PENDING_CUSTOMER ] ──(Customer activates)──► [ ACTIVE ]
Establishing a BGP peering session requires verifying underlying Layer 3 reachability, port availability, and protocol parameter matching. Cloud Router requires bidirectional communication across TCP port 179 between the local interface and the peer IP address. Cloud VPN tunnels use a unique /30 link-local subnet from 169.254.0.0/16, whereas Cloud Interconnect VLAN attachments allocate a /29 subnet from the same range, and Network Connectivity Center (NCC) Router Appliance instances require internal RFC 1918 addresses within the VPC subnet. Peer ASN values must match symmetrically on both ends, and multi-hop BGP with a time-to-live (TTL) of at least 2 must be configured on on-premises routers for Interconnect links. Cloud Router BGP keepalive timers range from 20 to 60 seconds (defaulting to 20 seconds), the graceful restart timer is fixed at 120 seconds, and peer stalepath timers should be set to match the 300-second Cloud Router default.
Layer 3 & Peering Checklist:
┌────────────────────────────────────────────────────────┐
│ [ ] Bidirectional TCP Port 179 open on firewalls │
│ [ ] Subnet mask: /30 for VPN, /29 for Interconnect │
│ [ ] Symmetric local and remote ASN configuration │
│ [ ] Multi-hop BGP TTL >= 2 (Interconnect links) │
│ [ ] Timers aligned: Keepalive, Restart (120s), Stalepath│
└────────────────────────────────────────────────────────┘
Dynamic route distribution fails when session settings, route limits, or cross-network peering policies are misconfigured. For dual-stack dynamic routing, both the underlying attachment and Cloud Router BGP peer settings must have IPv4 and IPv6 enabled with valid next-hop addresses. When on-premises prefixes do not appear in the VPC route table, administrators can inspect the route table using gcloud compute routers get-status to identify whether prefixes are marked with an inactive or filtered status. Routes become inactive or filtered due to session errors, peer-side prefix suppression, Cloud Router dynamic prefix quota exhaustion, or attached BGP route policies. For learned BGP routes to propagate across a VPC Network Peering connection into a peered network, the routing VPC must enable custom route exporting, and the receiving VPC must enable custom route importing.
Cloud Router outputs diagnostic logs and performance metrics to track BGP state changes and enforce route integrity. Cloud Logging captures operational log events including "BGP peering came up", "BGP peering went down", "LINK_DOWN" alerts when physical edge links fail, and "NOTIFICATION 6/1" when a session shuts down because a peer exceeded dynamic route limits. Cloud Monitoring tracks real-time counts for advertised and learned routes to help engineers identify asymmetric routing patterns. In addition, Network Intelligence Center's Network Analyzer runs automated checks to detect misconfigurations, such as dynamic routes shadowed by static routes or routes pointing to invalid next hops like stopped virtual machines or detached VPN tunnels.
VPC Flow Logs, firewall rules logging, and Packet Mirroring provide distinct levels of visibility into network performance, security boundaries, and packet transit across Google Cloud environments. VPC Flow Logs record metadata for network flows sent and received by virtual machine instances and can be sampled to analyze network traffic patterns, trace source-destination paths, and diagnose connection anomalies. Firewall rules logging captures state transitions directly from the security layer, allowing administrators to verify whether specific egress or ingress traffic was allowed or denied by security rules. When deep protocol inspections or payload verifications are required, Packet Mirroring clones entire raw data packets—including full payload and packet headers—directly from selected VM instances and forwards the mirrored traffic to collector instances for analysis without altering the primary production traffic path.
0 and interface 1 to qualify for the 99.99% availability SLA.64512 through 65534 or 4200000000 through 4294967294 and cannot be modified after creation.TC1 through TC6 using a bandwidth percentage policy that must sum to exactly 100 percent and must include BGP and BFD control traffic.Drain mode is an intentional backend state change initiated by an operator that stops new requests while allowing active connections to complete, and the backend remains draining even if health checks pass. Connection draining is an automated backend service setting with a predefined timeout window that permits in-flight requests to finish whenever an instance is removed or deregistered from a backend group.
BGP and BFD control plane traffic must be included in the bandwidth percentage policy so routing and liveness packets are never starved during periods of heavy data congestion. If control traffic is dropped due to lack of bandwidth allocation, BGP sessions can drop and cause full network outages.
A BGP session remains in an Active or Idle state if firewall rules block TCP port 179, if the local and remote ASN configurations do not match symmetrically between the routers, or if link-local IP addressing is mismatched. For Cloud Interconnect deployments, missing multi-hop BGP settings on the on-premises router will also prevent the session from reaching an Established state.
When weighted traffic splitting is configured within an advanced route rule across multiple backend services, the traffic splitting weights take precedence over session affinity. As a result, incoming requests are divided strictly according to the configured percentages, and existing client sticky sessions are not maintained across the backend services.
Prepare and test your skills
Prepare and test your skills