Professional Cloud Network Engineer
Cloud Router is a managed Google Cloud service that uses the Border Gateway Protocol (BGP) to exchange routing information between a Virtual Private Cloud (VPC) network and external networks, such as an on-premises data center. It works with connectivity services like Cloud Interconnect, Cloud VPN, and router appliances. The VPC network operates in either regional or global dynamic routing mode. In regional mode, the Cloud Router only advertises and learns routes for resources within its own region. In global mode, it exchanges routes for all subnets across every region in the VPC network, preferring local paths by assigning them a better metric.
Establishing a BGP session requires configuring an Autonomous System Number (ASN) for both the Cloud Router and the external peer router. For Partner Interconnect, you must use Google's public ASN 16550. For Dedicated Interconnect, HA VPN, or router appliances, you configure a private ASN (such as 65001) for the Cloud Router. The IP addresses used for the BGP connection depend on the underlying service: Cloud Interconnect and Cloud VPN use link-local addresses (like 169.254.0.0/29), while router appliances use standard internal IPs from the VPC subnet. All BGP traffic uses TCP port 179, which must be allowed through any relevant firewalls.
Each BGP session on a Cloud Router pairs an interface with a peer configuration. You can tune session behavior by setting BGP timers, such as keepalive and hold-time intervals, to control how quickly the session detects a failure. For stability, you can enable graceful restart to maintain data flow during router maintenance. For security, you can enable MD5 authentication to validate BGP control packets. You can also set a Multi-Exit Discriminator (MED) value (called advertised route priority) on each session; a lower MED gives that path a higher preference for inbound traffic.
By default, Cloud Router advertises all subnet routes (ALL_SUBNETS mode). You can set it to CUSTOM advertisement mode to selectively advertise only specific IP ranges, including custom CIDRs, Google API addresses, or health-check ranges. This provides precise control over what you announce to peers. For redundant connections, path selection is managed via MED values. Equal MEDs on multiple sessions trigger Equal-Cost Multipath (ECMP) routing, balancing traffic evenly (active/active). Unequal MEDs create an active/passive setup, where traffic prefers the lower-MED path and fails over to the higher-MED backup only if the primary fails.
Bidirectional Forwarding Detection (BFD) is a protocol that provides sub-second link failure detection, which is much faster than standard BGP timers. When BFD is enabled on a VPN tunnel with dynamic routing, the Cloud Router can detect a failure and remove the affected routes from the routing table within the BGP hold timer period, accelerating convergence and reducing potential packet loss.
A static route is a manually created, permanent entry in a VPC routing table that directs traffic for a specific destination to a predefined next hop. Every static route is defined by its Network (the VPC), Destination range (a single CIDR block), Priority (a number from 0 to 65535, where lower is better), and Next hop (the target resource). You can optionally use Network tags to restrict the route to apply only to specific VM instances.
Supported next-hop types include: the default internet gateway, a next-hop instance (a specific VM with IP forwarding enabled), a next-hop internal passthrough Network Load Balancer, and a next-hop Classic VPN tunnel that uses static routing.
Google Cloud evaluates routes in a strict order when forwarding a packet. First, it checks for a matching subnet route; if one exists, it is used exclusively and all custom static routes are ignored. If no subnet route matches, the system then selects the most specific destination among the remaining static and dynamic routes. Among custom routes, local VPC routes are preferred over imported peering routes. Finally, if multiple routes have the exact same destination, the route with the highest priority (lowest numerical value) is selected.
Regional dynamic routing mode restricts the exchange and programming of dynamic routes to resources located strictly within the same Google Cloud region as the Cloud Router. In this mode, a Cloud Router shares only the subnet routes from its local region with the external BGP peer router. When the Cloud Router receives learned BGP routes from an external network or Cloud VPN tunnel, it installs those custom dynamic routes solely for subnets located in that specific region. Workloads residing in other Google Cloud regions do not receive these learned routes and cannot use the local hybrid connection for transit.
Global dynamic routing mode extends route exchange across the entire VPC network, allowing Cloud Routers to propagate and learn dynamic routes across all regions. In this mode, each Cloud Router advertises subnet IP address ranges from every region in the VPC network to the external peer network. Concurrently, BGP routes learned by a Cloud Router in one region are programmed into the route tables of subnets across all regions. Cloud Router applies predetermined path preferences based on regional proximity, directing traffic across Google's global backbone network to exit through the Cloud Router closest to the destination.
Choose regional dynamic routing when hybrid traffic must remain strictly localized to prevent cross-region transit costs and maintain isolated failure domains between regions. Choose global dynamic routing when building multi-region architectures, active-active or active-passive inter-domain redundancy, or centralized transit hub VPC networks. Global dynamic routing ensures that if a local hybrid connection fails, traffic from that region can automatically fail over to a functional Cloud Router located in an alternate region.
A BGP session establishes a dynamic routing relationship between a Cloud Router and an external peer router over Cloud Interconnect, Cloud VPN, or Router appliance instances. In regional dynamic routing mode, the Cloud Router advertises only local regional subnets to the peer. In global dynamic routing mode, Cloud Router advertises all VPC subnets across all regions, applying a Multi-Exit Discriminator (MED) penalty equal to 200 plus the round-trip time in milliseconds between regions to prefer local paths.
Custom route advertisements allow administrators to specify exactly which IP prefixes a Cloud Router announces to peer networks. Multi-Exit Discriminators (MED) and AS path prepending are BGP attributes used on Cloud Router to steer ingress traffic across multiple hybrid connections. MED acts as a priority metric where external peers prefer routes with lower MED values. AS path prepending artificially lengthens the autonomous system path, making a route look less attractive to external peers.
Network Connectivity Center provides a centralized hub-and-spoke control model that automates dynamic route exchange across VPC networks, hybrid connections, and third-party router appliances. The dynamic routing mode of the hub VPC network governs how learned routes propagate from hybrid spokes to attached VPC spokes. If the hub VPC uses regional dynamic routing, hybrid spoke routes reach only VPC spokes in that local region; if the hub VPC uses global dynamic routing, hybrid routes reach VPC spokes across all regions. Spoke administrators enable subnet route propagation by setting the includeImportRanges field to ALL_IPV4_RANGES or by configuring custom route advertisements on the hybrid Cloud Routers.
Multi-VPC architectures often employ a dedicated transit VPC network connected via Network Connectivity Center to avoid building a complex full mesh of point-to-point links. This centralized design consolidates external dynamic routing policies, simplifies peering topologies, and minimizes administrative overhead.
Google Cloud's route selection follows a strict ten-step sequence. First, it checks for special routing paths such as those for Private Google Access or VPC flow logs. It then evaluates policy-based routes solely by their priority, starting with the highest-priority policy. If a packet's characteristics match the highest-priority policy-based route, all lower-priority policy-based routes are disregarded. After policy-based routes, Google Cloud checks if the packet's destination matches a local, peering, or Network Connectivity Center (NCC) subnet route. If a destination matches a regular subnet route, that route is used exclusively and all other routes are ignored. For hybrid subnet routes, the packet is routed only if the destination matches a running VM instance or an internal forwarding rule. If no subnet route matches, the process continues to static and dynamic routes.
Among static and dynamic routes, Google Cloud first filters by the most specific destination (longest prefix). It then selects only the most favorable custom route type, preferring local custom routes over NCC dynamic routes, and NCC dynamic routes over peering custom routes. Finally, among routes with the same destination and type, the route with the highest priority (lowest numerical value) is selected. After validating next hops, if multiple equal-priority routes remain, Google Cloud uses internal algorithms to select a single next hop; it never performs ECMP across multiple load balancers. The packet is sent to the single remaining next hop; if no routes remain, the packet is dropped.
Network tags are metadata attributes assigned to VM instances to selectively apply custom routing policies and firewall rules within a VPC network. By attaching tags to VM instances, network administrators can target specific static routes so that traffic from tagged instances follows dedicated paths. By default, a static route applies universally to all VM instances. When an administrator specifies a network tag during route creation, the route applies exclusively to VMs matching that tag. This mechanism enables selective path steering, such as directing specific instance traffic to dedicated next-hop resources like a Cloud VPN tunnel or a gateway appliance.
Dynamic routing using Cloud Router and BGP does not support network tags. Learned routes from dynamic routing apply across the network according to the configured routing mode. To influence path preference in dynamic environments, network administrators configure BGP MED values on the BGP sessions rather than using tag-based destination filters.
Hierarchical routing policies combine network tags and priority attributes to control traffic flow between VPC networks, on-premises infrastructure, and hybrid connectivity scenarios. Secure Tags are IAM-governed identifiers that can replace network tags in firewall rules. When creating secure Tags, the --purpose field must be set to GCE_FIREWALL, and each secure Tag must be associated with a single target VPC network. The migration workflow involves generating a mapping JSON file that contains the network tags and service accounts from existing firewall rules, then creating corresponding secure Tag key-value pairs using the resource-manager tags API. After creation, the secure Tags are bound to VMs using the gcloud beta compute firewall-rules migrate command with the --bind-tags-to-instances flag.
Priority in Google Cloud networking controls the order in which rules are evaluated, with lower numeric values taking precedence. For VPC firewall rules, the priority determines which rule is applied when multiple rules match the same traffic. For HA VPN configurations, route priority is controlled through BGP MED values.
Policy-based routing (PBR) is a VPC networking capability that directs traffic to specific next hops by evaluating packet headers beyond destination IP addresses. While standard static routes match only destination IP ranges, policy-based routes evaluate the source IP address, destination IP address, protocol, and port numbers (the 5-tuple). This matching lets administrators redirect traffic to next-hop internal load balancers, network virtual appliances (NVAs), or a Secure Web Proxy. When deploying policy-based routes, administrators must create a specific route for the intended workload and a separate default-routing route using --next-hop-other-routes="DEFAULT_ROUTING" so unmatched inter-VM traffic continues to flow normally.
Route priority determines the sequence in which Google Cloud evaluates policy-based routes, with lower numerical values indicating higher priority from 0 (highest) to 65535 (lowest). Policy-based routes are evaluated before standard subnet routes and static routes in the routing order. When routing to a Secure Web Proxy, the default-routing policy-based route must have a lower numerical priority (higher priority) than the proxy redirection route to prevent non-proxy traffic from being blocked. If multiple policy-based routes share identical priorities and match a packet, an internal algorithm picks a single route that might not be the most specific match; assigning unique priorities avoids this ambiguity.
Policy-based routes differ from static routes because static routes filter traffic using network tags and destination ranges, whereas policy-based routes filter using source IP ranges. A Secure Web Proxy configured with NEXT_HOP_ROUTING_MODE only supports HTTP, HTTPS, and TCP proxy traffic; unsupported traffic, including cross-region traffic, is dropped without notification. Furthermore, a single VPC network in a given region can host only one Secure Web Proxy as a next-hop instance.
In global dynamic routing mode, Cloud Router distributes learned routes to resources in every region across the entire VPC network. Route propagation is restricted by regional capacity quotas: each target region enforces a "from-other-regions" quota of 250 unique destinations. Exceeding this limit causes the network to drop excess routes.
BGP path selection prioritizes paths with the highest Local Preference first, followed by the shortest AS path length. When AS path lengths are equal, the MED breaks the tie, with lower MED values being preferred. Cloud Router sets MED values to guide inbound traffic from on-premises networks, while Google Cloud adds an inter-region dynamic metric cost to steer outbound traffic through local regional paths.
Cloud Router base advertised priorities range from 0 to 65535, with 100 as the default. When two BGP sessions on Cloud VPN or Cloud Interconnect share identical base priorities, the network operates in an active-active topology using ECMP. Assigning different base priorities creates an active-passive failover configuration.
Google Cloud automatically generates region-to-region cost metrics between 201 and 9999 based on physical distance and network latency. The overall MED advertised over BGP equals the Cloud Router base priority added to this region-to-region cost. Administrators keep local base priorities between 0 and 200 to ensure local hybrid paths take precedence over remote region paths. Configuring a secondary path with a base priority of 10200 or higher guarantees that it stays in backup status behind any local path configured with a priority of 200 or less.
Network Connectivity Center applies a strict hierarchy to resolve overlapping route advertisements. When destination prefixes overlap in a hub routing table, the system selects landing VPC subnets first, hub subnets second, and Cloud Router custom routes last. If an administrator creates a custom route advertisement that overlaps with a landing VPC subnet or an imported hub subnet, Cloud Router ignores the custom route advertisement.
A static route can use an internal passthrough Network Load Balancer as its next hop. This configuration directs traffic matching the route's destination range to the load balancer, which then distributes the traffic across its backend group. To create this route, the load balancer must exist first. In the route selection order, a static route with an internal passthrough Network Load Balancer next hop is less preferred than static routes with instance or Classic VPN tunnel next hops, and it is more preferred than static routes with the default internet gateway. Google Cloud never performs ECMP across multiple internal load balancers; if multiple equal-priority routes with load balancer next hops remain, a single next hop is selected by internal algorithms.
Static routes can be exchanged with peered VPC networks, except for routes that use the default internet gateway or network tags. When a static route is created in one VPC, it can be imported into a peered VPC if the route's destination range does not overlap with a subnet route in the peering VPC. The route selection order treats peering custom routes as less preferred than local custom routes, so a local route always takes precedence over a route learned from a peered network.
Network Connectivity Center (NCC) automates dynamic route exchange across VPC networks, hybrid connections, and third-party router appliances. Spoke administrators control which subnet routes are propagated to the hub by setting the includeImportRanges field on the spoke VPC to ALL_IPV4_RANGES or by configuring custom route advertisements on the hybrid Cloud Routers attached to the spoke. The hub VPC's dynamic routing mode determines whether hybrid spoke routes reach VPC spokes in all regions (global mode) or only in the local region (regional mode). In the NCC hub routing table, overlapping route advertisements are resolved by prioritizing landing VPC subnets first, hub subnets second, and Cloud Router custom routes last.
Policy-based routing (PBR) allows you to create routes that evaluate packet headers beyond the destination IP address, using the 5-tuple: source IP, destination IP, protocol, and port numbers. To configure a policy-based route, you specify the 5-tuple matching criteria and a next hop, which can be an internal load balancer, a network virtual appliance (NVA), or a Secure Web Proxy. You must also create a separate default-routing policy-based route using --next-hop-other-routes="DEFAULT_ROUTING" to ensure that traffic not matching the specific policy-based route continues to flow normally.
Policy-based routes are evaluated before standard subnet routes and static routes. Their priority is determined by a numerical value from 0 (highest) to 65535 (lowest). When multiple policy-based routes match a packet, the highest-priority route is used. If multiple policy-based routes have the same priority, an internal algorithm picks a single route, which may not be the most specific match; to avoid ambiguity, assign unique priorities to each policy-based route.
A Secure Web Proxy configured with NEXT_HOP_ROUTING_MODE only supports HTTP, HTTPS, and TCP proxy traffic. Unsupported traffic, including cross-region traffic, is dropped without notification. Additionally, a single VPC network in a given region can host only one Secure Web Proxy as a next-hop instance. When a policy-based route matches a VM, all traffic from that VMāincluding background tasks and system updatesāis steered to the specified next hop.
StudyCerts
StudyCertsincludeImportRanges field and custom route advertisements control propagation.Regional dynamic routing restricts Cloud Router to share routes only with resources in the same region as the Cloud Router. Global dynamic routing distributes routes learned by a Cloud Router in one region to all resources in every region of the VPC, with a MED penalty added to prefer local paths.
Use policy-based routing when you need to steer traffic based on source IP, protocol, or port numbers (5-tuple) rather than just destination IP. Static routes only match destination IP ranges, while policy-based routes can redirect traffic to specific next hops like an internal load balancer or a Secure Web Proxy.
When destination prefixes overlap in a hub routing table, Network Connectivity Center prioritizes landing VPC subnets first, then hub subnets, and finally Cloud Router custom routes. If a custom route advertisement overlaps with a landing VPC subnet or an imported hub subnet, Cloud Router ignores the custom route advertisement.
No, dynamic routing using Cloud Router and BGP does not support network tags. To influence path preference in dynamic environments, you configure BGP MED values on the BGP sessions instead of using tags.
Prepare and test your skills
Prepare and test your skills