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:

  • All subnets can communicate using internal IPv4 addresses.
  • Dual-stack subnets can also communicate using internal or external IPv6 addresses.

Peered VPC networks can be in the same project, different projects of the same organization, or different projects of different organizations.

VPC Network Peering provides the following benefits:

Benefits of VPC Network Peering

VPC Network Peering has the following benefits:

  • Network Latency: Connectivity that uses only internal addresses provides lower latency than connectivity that uses external addresses.
  • Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
  • Network Cost: Google Cloud charges egress bandwidth pricing for networks using external IP addresses to communicate even if the traffic is within the same zone. If however, the networks are peered they can use internal IP addresses to communicate and save on those egress costs. Regular network pricing still applies to all traffic.

For information about creating peering connections, see Use VPC Network Peering.

Specifications

VPC Network Peering has the following specifications.

General specifications:

  • VPC Network Peering works with Compute Engine, GKE, and App Engine flexible environment.
    • By default, VPC Network Peering with GKE is supported when used with IP aliases. If you don't use IP aliases, you can export custom routes so that GKE containers are reachable from peered networks.
  • Only VPC networks are supported for VPC Network Peering. Peering is not supported for legacy networks.
  • VPC Network Peering supports both IPv4 and IPv6 connectivity. You can configure VPC Network Peering on a VPC network that contains dual-stack subnets. However, for IPv6, only dynamic routes are exchanged.
  • A given VPC network can peer with multiple VPC networks, but there is a limit.
  • You cannot peer two different auto mode VPC networks because all auto mode VPC networks have the exact same subnets.
  • You can peer a custom mode VPC network and an auto mode VPC network such as the default network. However, you must make sure that none of the subnets in the custom mode VPC network overlap with the address space of the auto mode VPC network (10.128.0.0/9).

Administrative separation:

  • Peered VPC networks remain administratively separate. Routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks.
  • To establish peering connectivity, a Network Administrator for each VPC network must create a peering connection to the other VPC network. A Network Administrator for either VPC network can disconnect a peering connection.
  • Each side of a peering association is set up independently. Peering will be active only when the configuration from both sides matches. Either side can choose to delete the peering association at any time.
  • Creating a peering connection does not grant you any Identity and Access Management (IAM) roles on the other VPC network. For example, if you have the Compute Network Admin role or the Compute Security Admin role for one network, you don't become a Network Administrator or a Security Administrator for the other network.

IAM:

  • IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin role (roles/compute.networkAdmin).
  • You can use a custom role if it includes the following permissions:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Route exchange:

  • Peering and the option to import and export custom routes can be configured for one VPC network even before the other VPC network is created. Although route exchange only occurs after both sides have been configured.
  • VPC peers always export subnet routes.
  • VPC peers always import subnet routes if the subnet uses private IP addresses. If the subnet uses privately used public IP addresses, peered networks must explicitly import privately used public IP subnet routes to receive them from other networks. For more information about private IP addresses and privately used public IP addresses, see Valid ranges.
  • You can't disable the subnet route exchange or select which subnet routes are exchanged. After peering is established, all resources within subnet IP addresses are accessible across directly peered networks. VPC Network Peering doesn't provide granular route controls to filter out which subnet CIDR ranges are reachable across peered networks. You must use firewall rules to filter traffic if that's required. The following types of endpoints and resources are reachable across any directly peered networks:
    • Virtual machine (VM) internal IPs in all subnets
    • Internal load balanced IPs in all subnets
  • You can exchange custom routes (static and dynamic routes), depending on whether the peering configurations have been configured to import or export them. For more information, see Importing and exporting custom routes.
  • Subnet and static routes are global. Dynamic routes can be regional or global, depending on the VPC network's dynamic routing mode.
  • A subnet CIDR range in one peered VPC network cannot overlap with a static route in another peered network. This rule covers both subnet routes and static routes. Google Cloud checks for overlap in the following circumstances and generates an error when an overlap occurs.
    • When you peer VPC networks for the first time
    • When you create a static route in a peered VPC network
    • When you create a new subnet in a peered VPC network
  • A dynamic route can overlap with a subnet route in a peer network. For dynamic routes, the destination ranges that overlap with a subnet route from the peer network are silently dropped. Google Cloud uses the subnet route.

Limitations:

  • Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
  • VPC firewall rules cannot use a network tag or service account from a peered network. For details, see Network security.
  • Compute Engine internal DNS names created in a network are not accessible to peered networks. Use the IP address to reach the VM instances in peered network.
  • Policy-based routes are never exchanged through peering.

Importing and exporting custom routes

Network security

VPC Network Peering does not exchange any VPC firewall rules or hierarchical firewall policies. VPC firewall rules in one VPC network can't specify targets or sources using network tags or service accounts from the other VPC network. However, the same target network tag can be used in both networks.

Every VPC network contains implied firewall rules. Because of the implied deny ingress firewall rules, Security Administrators for a local VPC network must create appropriate allow ingress firewall rules or hierarchical firewall policies. These rules or policies permit packets from the required source IP address ranges in the peered VPC network.

Because of the implied allow egress firewall rules, you don't need to create allow egress firewall rules or hierarchical firewall policies to permit packets to the destinations in the peered VPC network. However, if Security Administrators for the local VPC network have created explicit egress deny rules, you must create egress allow rules or policies.

DNS support

Resources in a peered VPC network can't use Compute Engine internal DNS names created by a local VPC network.

A peered VPC network can't use Cloud DNS managed private zones that are authorized for only a local VPC network. To make the DNS names available to resources in a peered VPC network, use one of the following techniques:

Internal load balancer support

Clients in a local VPC network can access internal passthrough Network Load Balancers in a peer VPC network. For more information, see Use VPC Network Peering for internal passthrough Network Load Balancers. Peered networks can exchange custom static routes using internal passthrough Network Load Balancers as next hops. For more information, see Route exchange options.

Clients in a local VPC network can access internal Application Load Balancers in a peer VPC network. For more information, see Use VPC Network Peering for internal Application Load Balancers.

VPC Network Peering limits

VPC Network Peering limits control the following:

  • The number of resources, such as virtual machine (VM) instances or internal forwarding rules that can be present in a peering group.
  • The number of networks to which a given VPC network can connect.

The VPC peering limits depend on a concept called a peering group. Each VPC network has its own peering group consisting of itself and all other VPC networks connected to it by using VPC Network Peering. In the simplest scenario, if two VPC networks, net-a and net-b, are peered with each other, there are two peering groups: one from the perspective of net-a and the other from the perspective of net-b.

For more information, see VPC Network Peering limits.

Route exchange options

When a VPC network shares local routes with a peered VPC network, it exports the routes. The peered VPC network can then import the routes. Subnet routes, except for IPv4 subnet routes using privately used public IPv4 addresses, are always exchanged.

VPC Network Peering configuration lets you control the following:

  • If IPv6 routes are exchanged.
  • If routes for subnets that use privately used public IPv4 addresses are exported or imported.
  • If custom static and dynamic routes are exported or imported.

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

Options for exchanging subnet routes

The following table describes the route exchange options for subnet routes:

Route type Route export conditions Route import conditions
IPv4 subnet routes (primary and secondary IPv4 subnet ranges) using private IPv4 address ranges Always exported

Can't be disabled		 Always imported

Can't be disabled
IPv4 subnet routes (primary and secondary IPv4 subnet ranges) using privately 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 custom static routes

The following table describes the route exchange options for custom static routes.

Route type Route export conditions Route import conditions
Custom static routes with network tags (all next hop types) Can't be exported Can't be imported
Custom static routes that use the default internet gateway next hop Can't be exported Can't be imported
Custom IPv4 static routes—without network tags—that use the private IPv4 address of an internal passthrough Network Load Balancer as the next hop Always exported (like subnet IPv4 routes)

Can't be disabled 		Always imported (like subnet IPv4 routes)

Can't be disabled
Custom IPv4 static routes—without network tags—that use the forwarding rule name of an internal passthrough Network Load Balancer as the next hop 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
Custom IPv4 static routes—without network tags—that use other next hop types 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
Custom 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 for dynamic 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

Custom route exchange

When one VPC network exports custom routes and the other VPC network imports custom routes, the importing network can send packets directly to the next hop for each imported custom route in the peer VPC network. Custom static and custom dynamic routes are learned together and can't be configured independently. Changes in one network are reflected in the other network, subject to certain conditions. For more information, in this document, see Ignored routes, Subnet and peering subnet route interactions, and Subnet and static route interactions.

Importing custom routes from a peered VPC network can be useful in the following scenarios:

  • If the peered VPC network contains routes-based GKE clusters, and you need to send packets to the Pods in those clusters: Pod IP addresses are implemented as destination ranges for custom static routes located in the peered VPC network.
  • If the peered VPC network contains routes to on-premises resources and you need to access those resources in the local VPC network: You must also create routes for the subnet IP address ranges of the local VPC network in the on-premises network. You can use Cloud Router custom route advertisements in the peered VPC network to accomplish this additional requirement.

Ignored routes

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

  • 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.

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

For more details about the preceding situations, see Routing order.

For dual-stack peerings, if a local VPC network importing IPv6 routes doesn't have any dual-stack subnets, none of the IPv6 routes it receives from peered VPC networks can be used. Further, if the constraints/compute.disableAllIpv6 organization policy constraint has been set, a Network Administrator may not be able to create dual-stack subnets.

Subnet and peering subnet route interactions

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

  • Peering prohibits identical IPv4 subnet routes. For example, two peered VPC networks can't both have an IPv4 subnet route whose destination is 100.64.0.0/10.
  • Peering prohibits a subnet route from being contained within a peering subnet route. For example, if the local VPC network has a subnet route whose destination is 100.64.0.0/24, then none of the peered VPC networks can have a subnet route whose destination is 100.64.0.0/10.

Google Cloud enforces the preceding conditions for IPv4 subnet routes in the following 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, enabling import of subnet IPv4 routes with privately used public IP addresses.

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

IPv6 subnet routes (both internal and external) are unique by definition. No two VPC networks can use the same internal or external IPv6 subnet ranges. For example, if one VPC network uses fc:1000:1000:1000::/64 as an IPv6 subnet range, no other VPC network in Google Cloud can use fc:1000:1000:1000::/64, regardless of whether the VPC networks are connected by using VPC Network Peering.

Subnet and static route interactions

Google Cloud requires that subnet routes and peering subnet routes have the most specific destination IPv4 or IPv6 ranges. Within any VPC network, a local static route can't have a destination that exactly matches or fits within a local subnet route. For a more detailed discussion about this scenario, see Interactions with custom static routes.

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 or fits 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 network that already contains a subnet route that exactly matches or contains the local static route's destination if the peering configuration results in importing the conflicting subnet route. For example:

      • If a local static route with the 10.0.0.0/24 destination exists, you can't establish a new peering connection to a VPC network that contains an IPv4 subnet route whose destination exactly matches 10.0.0.0/24 or contains 10.0.0.0/24 (for example, 10.0.0.0/8).

      • When the intended peering stack type is IPV4_IPV6, if a local static route with the 2001:0db8:0a0b:0c0d::/96 destination exists, you can't establish a new peering connection to a VPC network that contains an IPv6 subnet route whose destination exactly matches or contains 2001:0db8:0a0b:0c0d::/96. In this situation, the only possible subnet IPv6 address range is 2001:0db8:0a0b:0c0d::/64 because subnet IPv6 address ranges in Google Cloud must use 64-bit subnet mask lengths.

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

      • Suppose two VPC networks are already peered, but they do not currently export and import IPv4 subnet routes by using privately used public IPv4 address ranges. A local static route with the 11.0.0.0/24 destination exists in the first VPC network, and a subnet route with the destination 11.0.0.0/8 exists in the peered VPC network. You can't simultaneously configure the peered VPC network to export subnet routes by using privately used public IPv4 addresses and configure the first VPC network to import subnet routes by using privately used public IPv4 addresses.

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

    • Conversely, if VPC networks are already connected by using VPC Network Peering, you can't perform the following operations:

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

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

  • A peering static route can't have a destination that exactly matches or 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 VPC network that already contains a static route that exactly matches or fits within the destination of the local VPC network's subnet route, if the peering configuration results in importing the custom route from the peer. As examples:

      • If a local subnet route for 10.0.0.0/8 exists, you can't establish a peering connection to a VPC network with a static route whose destination exactly matches 10.0.0.0/8 or fits within 10.0.0.0/8 (for example, 10.0.0.0/24).

      • When the intended peering stack type is IPV4_IPV6, if a local subnet route for 2001:0db8:0a0b:0c0d::/64 exists, you can't establish a peering connection to a VPC network with a static route whose destination exactly matches 2001:0db8:0a0b:0c0d::/64 or fits within 2001:0db8:0a0b:0c0d::/64 (for example, 2001:0db8:0a0b:0c0d::/96).

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

    • Conversely, if VPC networks are already connected by using VPC Network Peering, you can't perform the following operations:

      • Create a new local subnet route whose destination would exactly match or contain an imported peering static route.
      • Create a new static route in the peered VPC network whose destination 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 regions in which prefixes learned from Cloud Routers in that network are applied as local custom dynamic routes. For details about this behavior, see Effects of dynamic routing mode.

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

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

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

In both cases, the dynamic routing mode of the importing VPC network is not relevant.

For an example illustrating this behavior, see Local VPC network and peer VPC network with on-premises connectivity.

Subnet and dynamic route interactions

Conflicts between local or peering subnet routes and dynamic routes are resolved as described in Interactions with custom 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 to network-b, and network-b is peered to network-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 tunnels by using dynamic routing. (The same principles hold if the tunnels are replaced with Cloud Interconnect VLAN attachments.)
  • The peering connection for network-b is configured to export its custom routes, and the peering connection for network-a is configured to import its custom routes.

To provide connectivity from on-premises to subnets in network-a and network-b, the Cloud Router in network-b must be configured to use custom route advertisement. For example, the Cloud Router advertises only the custom prefix, custom-prefix-1, which includes the subnet ranges from network-b and the subnet ranges from network-a.

The Cloud Router in us-west1 learns on-premises-prefix from an on-premises router. on-premises-prefix does not create any conflict because it's broader than the subnet and peering subnet routes. In other words, on-premises-prefix does not exactly match and does not fit within any subnet 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 of network-a, the following routing characteristics apply:

  • When the dynamic routing mode of network-b is global, On-premises prefix learned by the Cloud Router in network-b are added as dynamic routes in all regions of network-b and as peering dynamic routes in all regions of network-a. If firewall rules are correctly configured, vm-a1, vm-a2, and vm-b can communicate with an on-premises resource with IPv4 address 10.5.6.7 (or IPv6 address fc:1000:1000:10a0:29b::).

  • If the dynamic routing mode of network-b is changed to regional, On-premises prefix learned by the Cloud Router in network-b are only added as dynamic routes in the us-west1 region of network-b and as peering dynamic routes in the us-west1 region of network-a. If the firewall rules are correctly configured, only vm-a1 and vm-b can communicate with an on-premises resource with IPv4 address 10.5.6.7 (or IPv6 address fc:1000:1000:10a0:29b::) because that is the only VM in the same region as the Cloud Router.

Transit network

In the following example, network-b acts as a transit network.

  • network-a is peered to network-b, and network-b is peered to network-a.
  • network-c is peered to network-b, and network-b is peered to network-c.
  • network-b is connected to an on-premises network with Cloud VPN tunnels using dynamic routing. (The same principles hold if the tunnels were replaced with Cloud Interconnect VLAN attachments.)
    • To provide connectivity from on-premises to subnets in network-a, network-b, and network-c, the Cloud Router in network-b must be configured to use custom route advertisement. For example, the Cloud Router advertises subnet routes from network-b plus custom prefixes which cover subnet routes in network-a and network-c.
    • Subject to subnet and dynamic route interactions, the Cloud Router in network-b learns on-premises prefixes and creates dynamic routes in network-b.
  • The peering connections from network-b to network-a and from network-b to network-c have been configured to export custom routes. The peering connections from network-a to network-b and from network-c to network-b have been configured to import custom routes.

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

  • VM instances in network-a can reach other VMs in network-b and on-premises systems.
  • VM instances in network-c can reach other VMs in network-b and on-premises systems.
  • VM instances in network-b can reach other VMs in both network-a and network-c, as well as systems in the on-premises network.

Because VPC Network Peering isn't transitive, VM instances in network-a and network-c can't communicate with each other unless you also connect networks network-a and network-c using VPC Network Peering.

What's next