Producer VPC spokes

This page provides an overview of producer Virtual Private Cloud (VPC) spokes in Network Connectivity Center.

Introduction

Some service providers let you access managed services by using a VPC Network Peering connection between their VPC network and your VPC network, such as services offered through private services access. In these cases, the producer VPC network is in a producer-owned project that you are unable to access directly.

If you have a VPC network that consumes a service from a producer network in another project through VPC Network Peering, you can use a Network Connectivity Center producer VPC spoke to make the service reachable by other networks.

How it works

When you create a producer VPC spoke, you provide the following:

The existing VPC spoke of your consumer network that is peered with the producer network.
The name of the peering connection.

Then, Network Connectivity Center uses that information to identify the VPC network of the service producer and add a corresponding producer VPC spoke to a hub in your project.

After the producer VPC spoke is part of the hub, its subnet routes are exported and the other spokes on that hub can access its services.

Example configuration

The example configuration in the following diagram includes:

A Service producer network that is a producer VPC spoke on the hub.
A Peered consumer network that is a VPC spoke on the hub.
Additional networks, Network 3 and Network 4, that are also VPC spokes on the hub.

All of the networks attached to the hub as VPC spokes can access the services in the producer network:

The peered consumer network continues to access services by using the subnet routes exported from the service producer network through the existing VPC Network Peering connection.
Network 3 and Network 4 have the same access to services in the producer network through Network Connectivity Center. The subnet routes from the service producer network are exported to the hub and advertised to the VPC spokes associated with Networks 3 and 4.

Network Connectivity Center producer VPC spoke. — Network Connectivity Center producer VPC spoke (click to enlarge).

Supported services

To use a producer VPC spoke, the service must be consumed by using private services access. That is, the name of the peering connection between your VPC network and the producer VPC network must be servicenetworking-googleapis-com.

Most Google services consumed through private services access can be used with producer VPC spokes, such as Cloud SQL and Filestore. However, Google services that rely on dynamic routes are not supported because producer VPC spokes export only subnet routes.

You can check whether a service producer exports only subnet routes by listing peering routes and ensuring that the associated peering connection only has routes of type Peering subnet.

Producer VPC spokes don't support third-party services.

Considerations

The following sections describe considerations for using producer VPC spokes.

Shared properties with VPC spokes

Producer VPC spokes are a type of VPC spoke, which means they inherit most of the properties of VPC spokes described in the VPC spokes overview. For example, both spoke types do the following:

Connect a VPC network to a Network Connectivity Center hub.
Export subnet routes to the Network Connectivity Center hub, which advertises those routes to other VPC spokes and routing VPC networks. This includes any new subnets added to the producer VPC spoke, which means that other spokes can access newly provisioned services from a producer VPC spoke.
Import dynamic routes from the Network Connectivity Center hub routing table, providing connectivity to hybrid spokes. The hub topology must also support dynamic route exchange.
Limit which subnets are exported by using export filters.
Use the same quotas and limits, including:
- The limit of 250 active VPC spokes per hub.
- The quota for the Number of subnet routes per hub route table.
If you don't have enough route quota for each producer VPC subnet being peered, you can't add the producer VPC spoke. To resolve this, you can apply export filters to limit which subnets are exported.

The limitations of VPC spokes also apply to producer VPC spokes.

Properties unique to producer VPC spokes

Producer VPC spokes have the following unique properties and requirements:

Property	Description
Dependencies	Creating a producer VPC spoke requires that you have the following existing resources and connections: A VPC network that consumes a supported service from a producer network through VPC Network Peering. The consumer VPC network is a VPC spoke on the hub.
Creation steps	When you create a producer VPC spoke, you don't enter the service producer network directly. Instead, you enter: The VPC spoke of your consumer network that is peered with the producer network. The name of the peering connection. If your hub is configured for star topology, the producer VPC spoke and its corresponding VPC spoke must belong to the same group.
Resource locations	A producer VPC spoke and its backing VPC network are in different projects: The service producer's VPC network is in a producer-owned project that you don't have access to. The producer VPC spoke resource is created in your project, and this is always the same project as the VPC spoke of your peered consumer network.
Connectivity exceptions	Creating a producer VPC spoke does not establish connectivity through Network Connectivity Center between the following resources: The producer VPC spoke and other producer VPC spokes. The producer VPC spoke and the VPC spoke of its peered consumer network that you entered at creation time. Instead, these two networks remain connected through their existing VPC Network Peering connection.

Avoid overlap with allocated IP ranges

If you want to create a producer VPC spoke for a supported service offered through private services access, consider the following:

Network Connectivity Center does not check for overlaps with allocated IP ranges. Ensure that the IP address ranges of the VPC spokes on your hub don't overlap with an allocated IP range configured for private services access.
If your VPC spokes overlap with allocated IP ranges, private services access might not be able to create new resources when needed and you'll get an error. To resolve this, expand or modify the allocated IP range.

For more information, see Allocated IP address ranges for services.