GCP Architecture Series #84 — Dynamic Routing Mode: Regional Versus Global

Business Challenge

#83 deferred to this setting three times, which is a fair measure of how much rests on it. The definitions are short. Regional dynamic routing mode: each region's dynamic route control plane only processes learned routes from the Cloud Router BGP tasks in its own region, and consequently the resulting dynamic routes created in a particular region of a VPC network have next hops only within that specific region. Global adds one step — each region's dynamic route control plane also sends the best path for each prefix to the dynamic route control planes in all other regions used in the VPC network — so the resulting dynamic routes created in a particular region of a VPC network can have next hops in any region.

Read that way it is a reachability switch, and that reading is half the setting. Three things make it more than that.

Architecture

One value on the network, acting on both directions, implemented as arithmetic on MED.

Distance becomes a number added to MED

This is the part worth understanding properly, because it is how global mode avoids being merely "everything reaches everything". On the advertising side the two cases are precise. For same-region ranges, the advertised MED matches the configured base priority of the BGP session. For distant ones, the advertised MED of subnet ranges in different regions is the sum of the configured base priority of the BGP session and an inter-regional cost.

So your peer receives your whole network's subnets with your local ones looking cheapest, and it will prefer them if it honours MED. Global mode does not flatten geography; it publishes geography as a metric.

The same arithmetic runs inbound. When a region receives best paths from elsewhere, when adding each next hop, the dynamic route control plane adjusts the MED value by adding an inter-regional cost, and each adjusted MED value is the sum of the original MED value plus an inter-regional cost. The scale is anchored at home: next hops in the dynamic route control plane's own region have an inter-regional cost of 0.

There is a decisive filter in global mode that makes local paths win outright rather than merely rank better: when the dynamic routing mode of the VPC network is global, the dynamic route control plane removes from consideration all next hops except for the next hops that have the smallest inter-regional cost. Since the own-region cost is zero, any locally learned next hop eliminates every remote one before MED comparison even matters. Global mode therefore behaves like regional mode whenever a local path exists, and only reaches across regions when it does not — which is exactly the failover behaviour people want, achieved without a failover mechanism.

One exemption is worth remembering because it is a useful lever: the dynamic routing mode has no effect on the advertised MED for custom IP address ranges. Custom ranges always advertise at the session's base priority, wherever their addresses nominally live. If you want a prefix advertised at a predictable metric regardless of mode, a custom range is the way to get it. The matching trap: a custom IP address range is ignored if it exactly matches a subnet route that a Cloud Router advertises according to the dynamic routing mode of its VPC network — so in global mode a custom entry duplicating any region's subnet does nothing, where in regional mode the same entry for a distant region's subnet would have worked.

Two control planes, two places a route can vanish

#83 established the shape: both types of Cloud Router learned routes are processed by a dynamic route control plane and then a VPC network control plane. The mode operates in the first, and the second gets a veto.

Between regions, only the best survives: the dynamic route control plane sends only the next hops that have the lowest MED value to the dynamic route control planes in other regions, though ties are preserved — if more than one next hop has the same lowest MED value, then they're all exported to the dynamic route control planes in other regions. So a second-best path in one region is not merely deprioritised elsewhere; it is never offered.

Downward, the winners are defined precisely: the dynamic route control plane sends all next hops with the highest rank and smallest inter-regional cost to the VPC control plane, and these dynamic routes have Andromeda route priority 65536. But the hand-off is lossy and the documentation is careful to promise little: the dynamic route control plane only guarantees that it sends the routes with the lowest MED values to the VPC control plane. Higher-MED routes may arrive and may not. When they do, they are visibly second-class — but they use lower Andromeda route priorities—for example, 65537 , 65538.

Then the final filter, which has nothing to do with regions: each region's VPC control plane receives candidate dynamic routes from the region's dynamic route control plane, and evaluation results in either creating a dynamic route in the VPC network that contains the Cloud Routers or suppression of the candidate dynamic route. The commonest reason for suppression is a collision you may not have considered — the candidate dynamic route destination prefix conflicts with a local, peering, or NCC subnet route.

Why This Architecture Holds Up

The mode belongs to one network, but its effects do not stop at that network's edge — and where they land is not always intuitive.

Across a peering, the exporter decides: when using VPC Network Peering, the dynamic routing mode of the VPC network that exports custom routes controls how dynamic routes are created in peer VPC networks that import custom routes. So if you import custom routes from a peer, the regionality of what you receive is set by their configuration, not yours. Combined with #81 — where custom route export and import are separate flags held by separate administrators — a hybrid path through a peer depends on three decisions in two projects, one of which is this mode.

For NCC the ownership is likewise elsewhere: NCC dynamic routes apply to one region or all regions of the VPC network according to the dynamic routing mode of the VPC network that contains the hybrid spoke. The spoke's network decides, not the workload network receiving the routes. After #82, where a VPC spoke has no import filter at all, this is the second respect in which a spoke inherits a routing decision made by somebody else's network.

Within your own network the applicability rule is stated plainly in the routes documentation: dynamic routes can apply to VM instances, VLAN attachments, and Cloud VPN tunnels in either the region containing the dynamic route's next hop or all regions, based on the dynamic routing mode of the VPC network. And the creation rule names both settings together, which is the right mental model after #83: dynamic routes are created in one region or in all regions based on the dynamic routing mode and best path selection mode of the VPC network that contains the Cloud Router. Mode decides how far; best path selection decides which.

Two things neither mode changes

The first is the ceiling, and it is the most important sentence to carry out of both posts: dynamic routes always have a lower VPC network route priority compared to static routes. Global mode buys reach and it buys failover. It does not buy precedence. A static route for the same destination wins in either mode, so if a hybrid path is being ignored, the mode is not the thing to change.

That is not a policy layered on top — it is arithmetic, and knowing the numbers makes it memorable. The best dynamic routes land at priority 65536, and the 65536 priority number is purposefully chosen because it's one value larger than 65535, which is the lowest a static route can hold. One off the bottom of the static range, by construction, so if both static and dynamic routes exist for the same destination prefix, a static route is preferred by the routing order. There is no priority you can set on a BGP session, and no mode, that reaches above 65535. Lower-ranked dynamic routes sit further down still, at 65537 and beyond.

The second is withdrawal, which is the property that makes dynamic routing worth the complexity at all: if a next hop for a dynamic route becomes inaccessible, the Cloud Router that manages its BGP session instructs the VPC network to remove the dynamic route. That holds in both modes, and in global mode it is what turns the inter-regional cost filter into real failover — the local zero-cost next hop disappears, and the remote ones that were filtered out become eligible.

For completeness, the MED comparison behaviour from #83 interacts with the inter-regional cost through one configuration value. With it enabled, the dynamic route control plane uses adjusted MED values when repeating the Consider neighbor ASN step; with it off or unset, the dynamic route control plane repeats the Consider neighbor ASN step using original MED values. Whether regional distance participates in the neighbour-ASN comparison is therefore itself a choice, which is one more reason the arithmetic here is not worth trying to predict precisely.

Choosing, in practice

The honest summary is that global is usually right and regional is occasionally necessary. Global gives cross-region reachability over a single hybrid link, automatic failover with no failover configuration, and a MED scale that already prefers local paths. Regional gives a smaller advertised prefix set, strict regional blast radius, and a routing table that is easier to reason about per region.

The cases where regional genuinely wins are narrower than they look: a peer that cannot accept your full prefix count, a regulatory requirement that one region's traffic not egress through another, or an estate where each region has its own hybrid link and you want a failure to stay local rather than silently reroute across the backbone and change the latency profile without telling anybody. That last one is the real argument for regional, and it is an operational preference rather than a technical limit.

Key Architecture Decisions

The one to look at today

For each VPC network with a Cloud Router, read the dynamic routing mode and then count how many subnet ranges each BGP session is advertising. If the mode is global and the network spans several regions, that count is the number of prefixes you are pushing at every peer, and it grows every time anyone adds a subnet anywhere — #83 established that subnet advertisements update automatically. Then ask whoever operates the peer router what their prefix limit is. Those two numbers are the thing most likely to break, and neither is visible from your own console.

Closing Thought

The misreading worth correcting is that this is a reachability setting. It is a scope setting, and scope has two directions. Half the documentation describes what your VMs can reach and half describes what your peer is told, and the two halves are in different pages — the learned-routes page and the advertised-routes page — which is exactly why the outbound half is the one that surprises people. Nothing in the console says "this will also change what you advertise".

The mechanism underneath is more elegant than the switch suggests. Rather than a mode that toggles reachability on and off, Google expresses geography as a number added to MED, anchors it at zero for your own region, and then filters on smallest cost before comparing anything else. The result is that global mode behaves identically to regional mode while a local path exists and only differs when one does not. That is a failover feature implemented entirely as arithmetic, with no failover logic anywhere — and twenty-four posts in, it is the most quietly well-designed thing I have found in this block.

Official Google Cloud Reference

• Learned routes
• Advertised routes
• Routes overview
• VPC networks overview
• Choosing networks and routing for Cloud VPN
• Cloud Router overview
• How Cloud Router works
• Advertise and remove routes
• Best practices for Cloud Router
• VPC Network Peering overview
• Network Connectivity Center overview