VPC Network Peering

Google Cloud VPC Network Peering connects two Virtual Private Cloud (VPC)networks so that resources in each network can communicate with each other.Peered VPC networks can be in the same project, differentprojects of the same organization, or different projects of differentorganizations.

Specifications

VPC Network Peering lets you do the following:

• Publishsoftware as a service(SaaS) offerings between VPC networks.
• VPC Network Peering works withCompute Engine,GKE, andApp Engineflexible environment.
  • VPC Network Peering supports VPC-nativeGKE clusters byexchanging subnetroutes.
  • VPC Network Peering supports routes-based GKEclusters when configured toexchange staticroutes.

Connectivity

• VPC Network Peering supports connectingVPCnetworks, notlegacy networks.
• VPC Network Peering provides internal IPv4 and IPv6connectivity between pairs of VPC networks. Peering traffic(traffic flowing between peered networks) has the samelatency, throughput, and availability as traffic within the sameVPC network.
  • VPC Network Peering does not provide transitive routing. For example,if VPC networksnet-a andnet-b are connected usingVPC Network Peering, and VPC networksnet-a andnet-c are also connected using VPC Network Peering,VPC Network Peering does not provide connectivity betweennet-b andnet-c.
  • You can't connect two auto mode VPC networks by usingVPC Network Peering. This is because peered VPCnetworks always exchange subnet routes that use private internal IPv4addresses, and each subnet in an auto mode VPC networkuses a subnet IP address range that fits within the10.128.0.0/9 CIDRblock.
  • You can connect acustom mode VPCnetwork to an auto mode VPCnetwork as long as the custom mode VPC network doesn't haveany subnet IP address ranges that fit within10.128.0.0/9.
• VPC Network Peering also provides certainexternal IPv6 connectivityto the destination external IPv6 address ranges of the following resourceswhen the routes to those destination external IPv6 addresses are exchangedby VPC Network Peering:
  • Dual-stack and IPv6-only virtual machine (VM) instance network interfaces
  • Forwarding rules for external protocol forwarding
  • Forwarding rules for external passthrough Network Load Balancers
• VPC Network Peering supports both IPv4 and IPv6 connectivity. You can configureVPC Network Peering on a VPC network that contains subnetswith IPv6 address ranges.

Administration

Peered VPC networks remain administratively separate. Onlyroutes are exchanged, according to the peering configuration. For moreinformation, seeAbout peering connections.

Network security

VPC networks connected using VPC Network Peering onlyexchange routes, based on theroute exchangeoptions configured by anetworkadministrator of each VPCnetwork.

VPC Network Peeringdoesn't exchangeVPC firewallrules orfirewallpolicies.

For VPC firewall rules:

• Firewall rules whose targets are defined using network tags are only resolvedto instances in the firewall rule's VPC network. Even though asecurity administrator of a peered VPC network can use the samenetwork tag to define targets of firewall rules in a peered VPCnetwork, the targets of the firewall rules in the peered VPCnetwork don't include instances in your VPC network. Similarly,ingress firewall rules whose sources are defined using network tags are onlyresolved to instances in the firewall rule's VPC network.

• Firewall rules whose targets are defined using service accounts are onlyresolved to instances in the firewall rule's VPC network.Subject to IAM permissions, a security administrator of apeered VPC network might be able to use the same serviceaccount to define targets of firewall rules in a peered VPCnetwork, but the targets of the firewall rules in the peeredVPC network don't include instances in your VPCnetwork. Similarly, ingress firewall rules whose sources are defined usingservice accounts are only resolved to instances in the firewall rule'sVPC network.

Rules in network firewall policies can use secureTags, which are different fromnetwork tags, to identify targets and sources:

• When used to specify a target for an ingress or egress rule in a networkfirewall policy, a Tag can only identify targets in the VPCnetwork to which the Tag is scoped.

• When used to specify a source for an ingress rule in a network firewallpolicy, a Tag can identify sources in both the VPC network towhich the Tag is scopedand any peered VPC networks thatare connected to the VPC network to which the Tag is scoped.For more information, seeTags forfirewalls.

Every VPC network contains implied firewall rules. Because of theimplied deny ingress firewallrules, security administrators foreach VPC networkmust create ingress allow firewall rules orrules in firewall policies. Sources for those rules can include IP addressranges of a peered VPC network.

Because of theimplied allow egress firewallrules, you don't need to createegress allow firewall rules or rules in firewall policies to permit packets todestinations in the peered VPC network unless your networksinclude egress deny rules.

DNS support

Resources in a peered VPC network can't useCompute Engine internal DNS namescreated by a local VPC network.

A peered VPC network can't useCloud DNS managedprivate zones that are authorized for only alocal VPC network. To make the DNS names available to resourcesin a peered VPC network, use one of the following techniques:

• UseCloud DNS peering zones.
• Authorize (make visible) the same managed private zoneto all the peered VPC networks.

Internal load balancer support

Clients in a local VPC network can access internal load balancersin a peer VPC network. For more information, see theUseVPC Network Peering sections of the following load balancer documentation:

• Internal passthrough Network Load Balancers and connectednetworks
• Internal proxy Network Load Balancers and connectednetworks
• Internal Application Load Balancers and connectednetworks

Peered networks can exchange static routes that use internal passthrough Network Load Balancers asnext hops. For more information, seeRoute exchangeoptions.

Peering group & quotas

The VPC peering quotas depend on a concept called apeeringgroup. Each VPC network has its own peering group consisting ofitself and all other VPC networks connected to it by usingVPC Network Peering. In the simplest scenario, if two VPCnetworks,net-a andnet-b, are peered with each other, there are two peeringgroups: one from the perspective ofnet-a and the other from the perspectiveofnet-b.

For more information about VPC Network Peering quotas see:

• Per network quotas
• Effective limits for per-peering groupquotas

Limitations

VPC Network Peering has the following limitations.

Subnet IP ranges can't overlap across peered VPC networks

No subnet IP range can exactly match, contain, or fit within another subnet IPrange in a peered VPC network. At the time of peering,Google Cloud checks if subnets with overlapping IP ranges exist; if they do, then the peering fails. For already peered networks, if you performan action that results in the creation of a new subnet route,Google Cloud requires the new subnet route to have a unique destination IPaddress range.

Before creating new subnets, you canlist the routes from peeringconnections to ensure that thenew subnet IPv4 address range is not already used.

This limitation and Google Cloud's corresponding checks also apply toscenarios such as the following:

• Your VPC network,network-1, is peered with a second VPCnetwork,network-2.
• network-2 is also peered with a third VPC network,network-3.
• network-3 is not peered withnetwork-1.

In this scenario, you must coordinate with a network administrator for thenetwork-2. Ask the network administrator fornetwork-2tolist peering routesin the their VPC network.

For more information about overlap checks, seeSubnet and peering subnet route interactions.

Internal DNS names don't resolve in peered networks

Compute Engine internal DNS names createdin a network aren't accessible to peered networks. To reach the VM instances inthe peered network, use the IP address of the VM.

Tags and service accounts are not usable across peered networks

You cannot reference a tag or service account pertaining to a VM from onepeered network in a firewall rule in the other peered network. For example, ifan ingress rule in one peered network filters its source based on a tag, it willonly apply to VM traffic originating from within that network, not itspeers,even if a VM in a peered network has that tag. This situation holdssimilarly for service accounts.

Route exchange options

When a VPC network shares local routes with a peeredVPC network, itexports the routes. The peeredVPC network can thenimport the routes. Subnet routes, exceptfor IPv4 subnet routes using privately used public IPv4 addresses, are alwaysexchanged.

VPC Network Peering configuration lets you control the following:

• If IPv6 routes are exchanged. Configuring a dual-stack peering connectionlets you exchange IPv6 routes from both dual-stack and IPv6-onlysubnets.
• If routes for subnets that use privately used public IPv4 addresses areexported or imported.
• If static and dynamic routes are exported or imported.

You can update the configuration before the peering has been established orwhile the peering connectivity is active.

VPC Network Peering doesn't provide:

• A granular method to control the exchange of specific subnet routes, staticroutes, and dynamic routes.
• Support for exchangingpolicy-based routes.

Options for exchanging subnet routes

The following table describes the route exchange options forsubnet routes:

Route type	Route export conditions	Route import conditions
IPv4 subnet routes (primary and secondary IPv4 subnet ranges) usingprivate IPv4 address ranges	Always exported Can't be disabled	Always imported Can't be disabled
IPv4 subnet routes (primary and secondary IPv4 subnet ranges) usingprivately used public IPv4 address ranges	Exported by default Export is controlled using the--export-subnet-routes-with-public-ip flag	Not imported by default Import is controlled using the--import-subnet-routes-with-public-ip flag
Internal IPv6 subnet ranges (ipv6-access-type=INTERNAL)	Not exported by default Export is enabled by setting--stack-type=IPV4_IPV6	Not imported by default Import is enabled by setting--stack-type=IPV4_IPV6
External IPv6 subnet ranges (ipv6-access-type=EXTERNAL)	Not exported by default Export is enabled by setting--stack-type=IPV4_IPV6	Not imported by default Import is enabled by setting--stack-type=IPV4_IPV6

Options for exchanging static routes

The following table describes the route exchange options forstaticroutes.

Route type	Route export conditions	Route import conditions
Static routes with network tags (allnext hop types)	Can't be exported	Can't be imported
Static routes that use the default internet gateway next hop	Can't be exported	Can't be imported
IPv4 static routes—without network tags—that use a next hop different from default internet gateway	Not exported by default Export is controlled by using the--export-custom-routes flag	Not imported by default Import is controlled by using the--import-custom-routes flag
IPv6 static routes—without network tags—that use a VM instance as the next hop	Not exported by default Export is controlled by using the--export-custom-routes flag when the stack type of the peering is set to--stack-type=IPV4_IPV6	Not imported by default Import is controlled by using the--import-custom-routes flag when the stack type of the peering is set to--stack-type=IPV4_IPV6

Options for exchanging dynamic routes

The following table describes the route exchange options fordynamic routes.

Route type	Route export conditions	Route import conditions
Dynamic IPv4 routes	Not exported by default Export is controlled by using the--export-custom-routes flag	Not imported by default Import is controlled by using the--import-custom-routes flag
Dynamic IPv6 routes	Not exported by default Export is controlled by using the--export-custom-routes flag when the stack type of the peering is set to--stack-type=IPV4_IPV6	Not imported by default Import is controlled by using the--import-custom-routes flag when the stack type of the peering is set to--stack-type=IPV4_IPV6

Benefits of exchanging static and dynamic routes

When one VPC network exports static and dynamic routes and theother VPC network imports those routes, the importing network cansend packets directly to the next hop for each imported static or dynamic routewhose next hop is in the peer VPC network.

A network administrator of a local VPC network controls theexport of that network's static and dynamic routes—together—by usingthe--export-custom-routes flag. A network administrator of the correspondingpeered VPC network controls the import of those static anddynamic routes by using the--import-custom-routes flag. For more information,seeIgnored routes,Subnet and peering subnet routeinteractions, andSubnet and static routeinteractions.

Importing static and dynamic routes from a peered VPC network canbe useful in the following scenarios:

• If the peered VPC network containsroutes-basedGKEclusters, and you needto send packets to the Pods in those clusters. Pod IP addresses areimplemented as destination ranges for static routes located in the peeredVPC network.

• If you need to provide connectivity between an on-premises network and apeered VPC network. Suppose a local VPCnetwork contains dynamic routes with a next hop Cloud VPN tunnel,Cloud Interconnect attachment (VLAN), or Router appliance thatconnects to an on-premises network. To provide a path from the peeredVPC network to the on-premises network, a networkadministrator for the local VPC network enables custom routeexport, and a network administrator for the peered VPCnetwork enables custom route import. To provide a path from the on-premisesnetwork to the peered VPC network, a network administratorfor the local VPC network must configureCloud Router custom advertisementmodeon the Cloud Router that manages the BGP session for theCloud VPN tunnel, Cloud Interconnect attachment (VLAN), orRouter appliance that connects to the on-premises network. The contentof those custom advertised routes must include the subnet IP addressranges of the peered VPC network.

Important: Cloud Routers don't advertisereceived peering subnetroutes when usingdefault advertisementmode.To advertise peering subnet routes or aggregate ranges of peering subnet routes,you must enable custom advertised mode, and ensure that the custom advertisedroutes include the IP address ranges of the subnets in the peeredVPC network.

Ignored routes

Even when a VPC network imports a route, it can ignore theimported route in situations like the following:

• When the local VPC network has a route with an identical or amore specific destination (longer subnet mask), the local VPC networkalways uses its local route.

• When the local VPC network doesn't contain the most-specificroute for a packet's destination, but two or more peered VPCnetworks contain the same, most-specific destination for the packet,Google Cloud uses an internal algorithm to select a next hopfrom just one ofthe peered VPC networks. This selection takes placebeforeroute priority is considered, and you can't configure the behavior. As a bestpractice, avoid this configuration because adding or removing peeredVPC networks can lead to unintended changes to the routing order.

For more details about the preceding situations, seeRouting order.

For dual-stack peerings, if a local VPC network importing IPv6routes doesn't have any dual-stack or IPv6-only subnets, none of the IPv6 routesit receives from peered VPC networks can be used. Further, if theconstraints/compute.disableAllIpv6organization policy constraint has been set, a Network Administrator may not beable to create subnets with IPv6 address ranges.

Subnet and peering subnet route interactions

IPv4 subnet routes in peered VPC networks can't overlap:

• Peering prohibits identical IPv4 subnet routes. For example, twopeered VPC networks can't both have an IPv4 subnet routewhose destination is100.64.0.0/10.
• Peering prohibits a subnet route from beingcontained within apeering subnet route. For example, if the local VPC networkhas a subnet route whose destination is100.64.0.0/24, then none of thepeered VPC networks can have a subnet route whose destinationis100.64.0.0/10.

Google Cloud enforces the preceding conditions for IPv4 subnet routes in thefollowing cases:

• When you connect VPC networks for the first time using VPC Network Peering.
• While the networks are peered.
• When you make a peering configuration change—for example, enablingimport of subnet IPv4 routes with privately used public IP addresses.

While you peer networks, Google Cloud returns an error if any of the followingoperations result in an overlap:

• Adding a new subnet.

• Adding a subnet secondary IPv4 address range.

• Expanding the subnet primary IPv4 address range.

IPv6 subnet routes (both internal and external) areunique bydefinition. No two VPC networkscan use the same internal or external IPv6 subnet ranges. For example, if oneVPC network usesfc:1000:1000:1000::/64 as an IPv6 subnet range,no other VPC network in Google Cloud can usefc:1000:1000:1000::/64, regardless of whether the VPC networksare connected by using VPC Network Peering.

Subnet and static route interactions

Google Cloud requires that subnet routes and peering subnet routes have the mostspecific destination IPv4 or IPv6 ranges. Within any VPC network,a local static route can't have a destination that exactly matches or fitswithin a local subnet route. For a more detailed discussion about this scenario,seeInteractions with staticroutes.

This concept is extended to VPC Network Peering by the following two rules:

• A local static route can't have a destination that exactly matches orfits within a peering subnet route. If a local static route exists,Google Cloud enforces the following:

  • You can't establish a new peering connection to a VPC networkthat already contains a subnet route that exactly matches or containsthe local static route's destination if the peering configurationresults in importing the conflicting subnet route. For example:

    • If a local static route with the10.0.0.0/24 destination exists,you can't establish a new peering connection to a VPCnetwork that contains an IPv4 subnet route whose destination exactlymatches10.0.0.0/24 or contains10.0.0.0/24 (for example,10.0.0.0/8).

    • When the intended peering stack type isIPV4_IPV6, if a local static routewith the2001:0db8:0a0b:0c0d::/96 destination exists, you can't establisha new peering connection to a VPC network that contains anIPv6 subnet route whose destination exactly matches or contains2001:0db8:0a0b:0c0d::/96. In this situation, the only possible subnet IPv6address range is2001:0db8:0a0b:0c0d::/64 because subnet IPv6 address rangesin Google Cloud must use 64-bit subnet mask lengths.

  • You can't update an existing peering connection if the updated peeringconfiguration results in importing the conflicting subnet route. For example:

    • Suppose two VPC networks are already peered, but theydon't export and import IPv4 subnet routes by using privately used publicIPv4 address ranges. A local static route with the11.0.0.0/24 destinationexists in the first VPC network, and a subnet route with thedestination11.0.0.0/8 exists in the peered VPC network. Youcan't simultaneously configure the peered VPC network to exportsubnet routes by using privately used public IPv4 addressesand configure thefirst VPC network to import subnet routes by using privately usedpublic IPv4 addresses.

    • Suppose two VPC networks are already peered, and the peeringstack type is IPv4 only. A local static route with the2001:0db8:0a0b:0c0d::/96 destination exists in the first VPCnetwork, and an IPv6 subnet route with the destination2001:0db8:0a0b:0c0d::/64exists in the peered VPC network. You can't change thepeering stack type toIPV4_IPV6.

  • Conversely, if VPC networksare already connected by usingVPC Network Peering, youcan't perform the following operations:

    • Create a new local static route whose destination would exactly match orfit within an imported peering subnet route.

    • Create a new subnet address range in the peered VPC networkif that range would exactly match or contain an existing local static route.

• A peering static route can't have a destination that exactly matchesor fits within a local subnet route. If a local subnet route exists,Google Cloud prohibits the following:

  • You can't establish a new peering connection to a VPCnetwork that already contains a static route that exactly matches orfits within the destination of the local VPC network'ssubnet route, if the peering configuration results in importing thestatic route from the peer. As examples:

    • If a local subnet route for10.0.0.0/8 exists, you can't establish apeering connection to a VPC network with a static routewhose destination exactly matches10.0.0.0/8 or fits within10.0.0.0/8(for example,10.0.0.0/24).

    • When the intended peering stack type isIPV4_IPV6, if a local subnet routefor2001:0db8:0a0b:0c0d::/64 exists, you can't establish a peering connectionto a VPC network with a static route whose destinationexactly matches2001:0db8:0a0b:0c0d::/64 or fits within2001:0db8:0a0b:0c0d::/64 (for example,2001:0db8:0a0b:0c0d::/96).

  • You can't update an existing peering connection if the updatedpeering configuration results in importing the conflicting static route.

  • Conversely, if VPC networksare already connected by usingVPC Network Peering, youcan't perform the following operations:

    • Create a new local subnet route whose destination would exactly match orcontain an imported peering static route.
    • Create a new static route in the peered VPC network whosedestination would exactly match or fit within an existing local subnet route.

Effects of the dynamic routing mode

The dynamic routing mode of a VPC network determines the regionsin which prefixes learned from Cloud Routers in that network areapplied as local dynamic routes. For details about this behavior, seeEffectsof dynamic routingmode.

This concept is extended to VPC Network Peering. The dynamic routing mode oftheexporting VPC network—the network that contains theCloud Routers that learned the prefixes for those dynamic routes—determines the regions in which the peering dynamic routes can be programmed inpeer networks:

• If the dynamic routing mode of the exporting VPC network isregional, then that network exports dynamic routes only in the same regionas its Cloud Routers that learned the prefixes.

• If the dynamic routing mode of the exporting VPC network isglobal, then that network exports dynamic routes in all regions.

In both cases, the dynamic routing mode of theimporting VPCnetwork is not relevant.

For an example illustrating this behavior, seeLocal VPC networkand peer VPC network with on-premisesconnectivity.

Subnet and dynamic route interactions

Conflicts between local or peering subnet routes and dynamic routes areresolved as described inInteractions with dynamic routes.

VPC Network Peering examples

The following examples demonstrate two common VPC Network Peering scenarios.

Local VPC network and peer VPC network with on-premises connectivity

In this example, the following network peering is set up:

• network-a is peered tonetwork-b, andnetwork-b is peered tonetwork-a.
• network-a contains two subnets where each subnet is in a separate region.network-b contains a single subnet.
• network-b is connected to an on-premises network with Cloud VPN tunnelsby using dynamic routing. (The same principles hold if the tunnels arereplaced with Cloud Interconnect VLAN attachments.)
• The peering connection fornetwork-b is configured with the--export-custom-routes flag, and the peering connection fornetwork-a isconfigured with the--import-custom-routes flag.

To provide connectivity from on-premises to subnets innetwork-a andnetwork-b, the Cloud Router innetwork-bmust beconfigured to usecustom advertisement mode.For example, the Cloud Router advertises only the custom prefix,custom-prefix-1, which includes the subnet ranges fromnetwork-b and thesubnet ranges fromnetwork-a.

The Cloud Router inus-west1 learnson-premises-prefix froman on-premises router.on-premises-prefix does not create any conflict becauseit'sbroader than the subnet and peering subnet routes. In otherwords,on-premises-prefix does not exactly match and does not fitwithin anysubnet or peering subnet route.

The following table summarizes the network configuration specified in the preceding example:

Network name	Networking component	IPv4 range	IPv6 range	Region
network-a	subnet-a	10.0.0.0/24	fc:1000:1000:1000::/64	us-west1
network-a	subnet-b	10.0.1.0/24	fc:1000:1000:1001::/64	europe-north 1
network-b	subnet-c	10.0.2.0/23	fc:1000:1000:1002::/64	us-west1
network-b	Cloud Router	10.0.0.0/22	fc:1000:1000:1000::/64	us-west1
On-premises network	On-premises router	10.0.0.0/8	fc:1000:1000:1000::/56	N/A

Regardless of the dynamic routing mode ofnetwork-a, the following routingcharacteristics apply:

• When the dynamic routing mode ofnetwork-b is global,On-premises prefixlearned by the Cloud Router innetwork-bare added as dynamic routes in all regions ofnetwork-band as peeringdynamic routes in all regions ofnetwork-a. If firewall rules arecorrectly configured,vm-a1,vm-a2, andvm-b can communicate with anon-premises resource with IPv4 address10.5.6.7 (or IPv6 addressfc:1000:1000:10a0:29b::).

• If the dynamic routing mode ofnetwork-b is changed to regional,On-premises prefix learned by the Cloud Router innetwork-bare only added as dynamic routes in theus-west1 region ofnetwork-b and aspeering dynamic routes in theus-west1 region ofnetwork-a. Ifthe firewall rules are correctly configured, onlyvm-a1 andvm-b cancommunicate with an on-premises resource with IPv4 address10.5.6.7 (or IPv6addressfc:1000:1000:10a0:29b::) because that is the only VM in the sameregion as the Cloud Router.

Transit network with multiple peerings

Consider a scenario in whichnetwork-b is connected to an on-premisesnetwork and acts as atransit network for two other networks,network-aandnetwork-c. To let VMs in both of these networksaccessnetwork-b and its connected on-premises network by using only internalIP addresses, the following configuration is required:

• network-a is peered tonetwork-b, andnetwork-b is peered tonetwork-a.
• network-c is peered tonetwork-b, andnetwork-b is peered tonetwork-c.
• network-b is connected to an on-premises network with Cloud VPNtunnels using dynamic routing. The same principles hold if the tunnels werereplaced with Cloud Interconnect VLAN attachments.
  • To provide connectivity from on-premises to subnets innetwork-a,network-b, andnetwork-c, the Cloud Router innetwork-b is configured to usecustom advertisement mode.For example, the Cloud Router advertises subnet routes fromnetwork-b plus custom prefixes that cover subnet routes innetwork-aandnetwork-c.
  • Subject tosubnet and dynamic route interactions,the Cloud Router innetwork-b learns on-premises prefixes andcreates dynamic routes innetwork-b.
• The peering connections fromnetwork-b tonetwork-a and fromnetwork-btonetwork-c are configured with the--export-custom-routes flag.The peering connections fromnetwork-a tonetwork-b and fromnetwork-ctonetwork-b are configured with the--import-custom-routes flag.
  • Subject tosubnet and dynamic route interactions,the Cloud Router innetwork-b also creates peering dynamicroutes innetwork-a andnetwork-c.

If firewalls are configured correctly, the following connectivity scenarios are possible:

• VM instances innetwork-a can reach other VMs innetwork-b andon-premises systems.
• VM instances innetwork-c can reach other VMs innetwork-b andon-premises systems.
• VM instances innetwork-b can reach other VMs in bothnetwork-a andnetwork-c, as well as systems in the on-premises network.

Because VPC Network Peering isn't transitive, VM instances innetwork-a andnetwork-c can't communicate with each other unless you also connect networksnetwork-a andnetwork-c using VPC Network Peering.

Pricing

Regularnetwork pricing applies to VPC Network Peering.

What's next

• To learn about administering VPC Network Peering connections, seeAbout peering connections.
• To set up and troubleshoot VPC Network Peering, seeSet up and manage VPC Network Peering.