Business Challenge
#79 and #80 covered sharing one network across many projects. This is the other shape: joining two networks that stay separate. Google Cloud VPC Network Peering connects two Virtual Private Cloud (VPC) networks so that resources in each network can communicate with each other, and it reaches further than Shared VPC does — peered VPC networks can be in the same project, different projects of the same organization, or different projects of different organizations.
The performance claim is unqualified and worth having in writing: peering traffic (traffic flowing between peered networks) has the same latency, throughput, and availability as traffic within the same VPC network. So this is not a tunnel or an overlay; it is route exchange, and peered VPC networks remain administratively separate because only routes are exchanged, according to the peering configuration.
Non-transitivity is the fact everyone already knows, and it turned out to be the least interesting thing on the page.
They are, for addressing. Routing stops at one hop: VPC Network Peering does not provide transitive routing, and Google's example is explicit that VPC Network Peering does not provide connectivity between net-b and net-c. But the overlap rule reaches past that boundary. Google's own scenario has network-1 peered with network-2, network-2 peered with network-3, and network-3 is not peered with network-1 — and the instruction is still: in this scenario, you must coordinate with a network administrator for the network-2. Specifically, ask the network administrator for network-2 to list peering routes in their VPC network.
Treat an address plan as a property of the whole peering graph, not of your own network. Before allocating a new subnet range, establish what every network one hop away already imports, because a collision there blocks you even though you could never have sent a packet to the network that owns it.
That is the one case the feature refuses outright. You can't connect two auto mode VPC networks by using VPC Network Peering, and the reason is arithmetic rather than policy: each subnet in an auto mode VPC network uses a subnet IP address range that fits within the 10.128.0.0/9 CIDR block. Since no subnet IP range can exactly match, contain, or fit within another subnet IP range in a peered VPC network, two networks drawing from the same block always collide.
Correct approachUse custom mode for anything you might ever peer. A mixed pair does work — you can connect a custom mode VPC network to an auto mode VPC network as long as the custom mode VPC network doesn't have any subnet IP address ranges that fit within 10.128.0.0/9 — so the auto mode network can stay, but the custom one must keep clear of that block entirely.
Not in the case that matters. Local routes win cleanly: when the local VPC network has a route with an identical or a more specific destination (longer subnet mask), the local VPC network always uses its local route. But when two peers offer the same most-specific destination, Google Cloud uses an internal algorithm to select a next hop from just one of the peered VPC networks — and critically, this selection takes place before route priority is considered , and you can't configure the behavior.
Correct approachDo not build it. Google's own advice is to avoid the shape: as a best practice, avoid this configuration because adding or removing peered VPC networks can lead to unintended changes to the routing order. Keep destination ranges distinct across peers, so the ambiguous case never arises and priority never has to be reached for.
Architecture
Two networks, one hop of connectivity, a transitive constraint, and a route exchange that both sides configure separately.
Why auto mode forecloses this, months in advance
This is the clearest example I have hit of an early decision closing a door much later. #62 was about auto versus custom mode, and the trade-off then looked like convenience against control. It was also, silently, a decision about who you can ever peer with.
The mechanism is worth stating precisely. Every auto mode subnet, in every region, lands inside the single block 10.128.0.0/9. Two auto mode networks therefore do not merely risk a collision — they are guaranteed one, because both are allocating from the same space by design. There is no range either side can choose to avoid it.
The asymmetric case is the practically useful one: a custom mode network can peer with an auto mode network, provided the custom one never allocates inside 10.128.0.0/9. So the rule for any network that might one day join a peering graph is to stay out of that block, which is a one-line addition to an address plan and impossible to retrofit once subnets carry workloads.
It is worth separating the two statements carefully, because they are easy to collapse. Routing is not transitive: packets do not traverse a peering to reach a third network. Address uniqueness is enforced across the peering, and because your peer imports its own peers' subnet routes, a range that collides in their table blocks you. The documentation's remedy is social rather than technical — ask the middle network's administrator to list their peering routes. So the feature gives you less connectivity than you might expect and more coupling, and both halves of that are in the same section of one page.
What crosses, and who decides
Only routes cross, and the matrix is more restrictive than "configurable" suggests. The baseline is mandatory: subnet routes, except for IPv4 subnet routes using privately used public IPv4 addresses, are always exchanged, and for private IPv4 subnet routes the table reads always exported can't be disabled always imported can't be disabled. You cannot peer two networks and withhold their subnets from each other.
| Route type | Exchanged? | Controlled by |
|---|---|---|
| Private IPv4 subnet routes | Always, both directions | Nothing — cannot be disabled |
| Privately used public IPv4 subnet routes | Exported by default, not imported by default | --export-subnet-routes-with-public-ip / --import-subnet-routes-with-public-ip |
| IPv6 subnet routes, internal or external | Off by default | --stack-type=IPV4_IPV6 |
| Static and dynamic routes | Off by default | --export-custom-routes on one side, --import-custom-routes on the other |
| Static routes with network tags | Can't be exported Can't be imported | Nothing — never available |
| Static routes via the default internet gateway | Can't be exported Can't be imported | Nothing — never available |
| Policy-based routes | Not supported | — |
Two rows deserve attention. The tagged-static-route row is a quiet casualty of #70's material: a static route carrying network tags is how you scope a route to particular instances, and such a route can never cross a peering in either direction. If your egress design depends on tagged routes, peering does not carry it.
And the static-and-dynamic row describes a two-party arrangement that is easy to misread as one setting. A network administrator of a local VPC network controls the export of that network's static and dynamic routes — together, with no per-route selection — by using the --export-custom-routes flag, while a network administrator of the corresponding peered VPC network controls the import of those static and dynamic routes by using the --import-custom-routes flag. Four combinations exist and only one produces connectivity, so a working hybrid path depends on two administrators in two projects, each of whom can revoke it alone without touching the peering itself.
The granularity limit is stated as an absence, and it is the honest framing: peering does not provide a granular method to control the exchange of specific subnet routes, static routes, and dynamic routes, nor support for exchanging policy-based routes. It is per-category, all-or-nothing.
The hybrid step that is easy to miss
Extending an on-premises connection to a peer needs a third piece, in a different product, and it is called out in an Important note: Cloud Routers don't advertise received peering subnet routes when using default advertisement mode. The fix is deliberate configuration — to advertise peering subnet routes or aggregate ranges of peering subnet routes, you must enable custom advertised mode.
So the full path from on-premises to a peered network is three separate decisions by up to three administrators: custom route export on the local network, custom route import on the peer, and custom advertised mode on the Cloud Router carrying the BGP session. Any one missing produces a one-way or absent path, and only the third involves a product most people would not think to check.
Why This Architecture Holds Up
Routes cross. Almost nothing else does, and the exceptions are precise.
Firewalls stay home: VPC Network Peering doesn't exchange VPC firewall rules or firewall policies. That alone would be unremarkable — but the identity-based targeting this series spent #72 on degrades in a specific way. Firewall rules whose targets are defined using network tags are only resolved to instances in the firewall rule's VPC network, and the same holds for service accounts: firewall rules whose targets are defined using service accounts are only resolved to instances in the firewall rule's VPC network. The limitation section restates it as a flat prohibition: you cannot reference a tag or service account pertaining to a VM from one peered network in a firewall rule in the other peered network.
The consequence is that across a peering you are back to addresses. Security administrators for each VPC network must create ingress allow firewall rules or rules in firewall policies, and sources for those rules can include IP address ranges of a peered VPC network. Range-based rules are exactly what #72 argued were the weakest form of targeting, and over a peering they are the only form available — with one exception.
Secure tags, from #73 onward, behave differently from network tags here. As a target they stop at the boundary: when used to specify a target for an ingress or egress rule in a network firewall policy, a Tag can only identify targets in the VPC network to which the Tag is scoped. As a source they do not: when used to specify a source for an ingress rule in a network firewall policy, a Tag can identify sources in both the VPC network to which the Tag is scoped and any peered VPC networks that are connected to the VPC network to which the Tag is scoped. So you can write "allow ingress from instances tagged X in my network or any peer", but you cannot write "apply this rule to instances tagged X in a peer". That is a genuine reason to prefer secure tags over network tags in any estate with peering, and it is the first real functional advantage this series has found for them beyond the IAM argument.
DNS stops at the boundary too, in both directions. Resources in a peered VPC network can't use Compute Engine internal DNS names created by a local VPC network, and a peered VPC network can't use Cloud DNS managed private zones that are authorized for only a local VPC network. The limitations section is blunter: Compute Engine internal DNS names created in a network aren't accessible to peered networks, so to reach the VM instances in the peered network, use the IP address of the VM.
There are two supported ways out, and they differ in who holds the zone. Use Cloud DNS peering zones, or authorize the same managed private zone to every peered network. The second is simpler and couples the networks' DNS configuration; the first keeps ownership with the zone's network. Either way this is configuration somebody has to do, and the failure mode without it is a name that resolves on one side of the peering and not the other — which looks like a DNS outage rather than a missing feature.
Quotas count the group, not the link
One concept matters for capacity planning and is easy to skim: each VPC network has its own peering group consisting of itself and all other VPC networks connected to it by using VPC Network Peering. Quotas apply to that group, from each network's own perspective, which means two peers see two different groups and can be at different distances from a limit. A network with many peers constrains all of them, and none of them can see the whole picture — the same visibility problem as the overlap check, in a different register.
Two capabilities do carry across and are worth knowing because they are commonly assumed not to. Clients in a local VPC network can access internal load balancers in a peer VPC network, and peered networks can exchange static routes that use internal passthrough Network Load Balancers as next hops — so a load balancer can act as a next hop across a peering, provided custom route exchange is enabled on both sides.
And the familiar exclusion, for the fourth time in this block: VPC Network Peering supports connecting VPC networks , not legacy networks.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Any network that might ever be peered | Custom mode, and keep every range out of 10.128.0.0/9 |
Two auto mode networks can never peer, and that block is where auto mode allocates. |
| Allocating a new subnet range | Check what your peers' peers already use | The overlap constraint is transitive even though routing is not. |
| Needing A to reach C through B | Peer A to C directly, or use a different product | Peering provides no transitive routing, full stop. |
| Two peers offering the same destination range | Redesign so they do not | Selection is by internal algorithm, before priority, and unconfigurable. |
| Enabling a hybrid path through a peer | Expect three changes by up to three administrators | Export, import, and Cloud Router custom advertised mode are separate. |
| Relying on tagged static routes | Do not expect them over a peering | Static routes with network tags can never be exported or imported. |
| Writing firewall rules for peer traffic | Use IP ranges, or secure tags as sources | Network tags and service accounts resolve only within their own network. |
| Choosing a tag type in a peered estate | Prefer secure tags | Only a secure tag can identify sources in a peered network. |
| Expecting hostnames to work across a peering | Configure Cloud DNS peering zones, or share one private zone | Internal DNS names are not accessible to peers. |
| Planning peering capacity | Count per peering group, per network | Each network has its own group and its own distance from the limits. |
| Peering across organizations | Supported, unlike Shared VPC | Peers may be in different projects of different organizations. |
| Worrying about peering performance | Do not | Latency, throughput and availability match traffic inside one VPC network. |
The one to look at today
For each of your peerings, ask the administrator on the other side to list their peering routes, and reconcile the result against your address plan. That is Google's own instruction for the three-network case, and it is the only way to discover a range that will block your next subnet — because the collision will be with a network you have no route to, cannot query, and may not know exists. Then check whether any two of your peers advertise the same destination range, since that is the configuration whose routing Google selects by an algorithm you cannot influence.
Closing Thought
Non-transitivity gets quoted as a limitation, and framed that way it is unremarkable — of course a route exchange between two networks does not create a third path. The interesting half is what is transitive. Address uniqueness propagates one hop further than connectivity does, so peering hands you a constraint from a network you cannot reach and offers, as the remedy, asking somebody to read their routing table to you. A design that is deliberately non-transitive in its data plane is accidentally transitive in its planning.
The other thing I will carry forward is the auto mode wall. #62 presented auto versus custom mode as convenience against control, and that was accurate as far as it went. It was also a decision about future peering, taken before anyone involved was thinking about peering, and it is not reversible once subnets hold workloads. Twenty-one posts in, that is the most expensive kind of finding in this series: not a trap in the feature you are reading about, but a door that a reasonable earlier choice quietly closed.
#82 takes the product that exists because of everything above: Network Connectivity Center and hub-and-spoke topologies — what you reach for when non-transitive peering stops scaling.
Comments