Include and exclude spoke filters for hybrid spokes are available in public preview.

You can use export filters to control which subnets or routes a spoke can send to the hub. Import filters control which subnets or routes can be accepted by a spoke from the hub.

Producer VPC spokes support for Google Cloud NetApp Volumes is generally available.

Support for privately used public IPv4 addresses is generally available in Network Connectivity Center.

This feature lets you exchange privately used public IPv4 addresses with VPC spokes and producer VPC spokes.

Network Connectivity Center supports site-to-site data transfer in the following countries:

• Brazil
• Indonesia
• South Africa

Static routes for Network Connectivity Center are available in GA.

You can use static routes to define the next hop along the path that network traffic takes to reach a given destination. For more information about using static routes with Network Connectivity Center, see the Static routes overview.

IPv4 and IPv6 address range filtering for VPC spokes is available in GA.

This feature lets you change IPv4 and IPv6 address ranges for VPC spokes that are exported to a hub.

You can allow the exchange of privately used public IPv4 addresses with VPC spokes and producer VPC spokes.

Site-to-site data transfer locations in the following countries have been added to Network Connectivity Center:

• Qatar
• Switzerland

Static routes for Network Connectivity Center are available in public preview.

You can use static routes to define the next hop along the path that network traffic takes to reach a given destination. For more information about using static routes with Network Connectivity Center, see the Static routes overview.

Routes that NCC Gateway advertises don't show up in the list of a VPC network's effective routes.

NCC Gateway is available in public preview.

NCC Gateway is a regional product that enables security functions such as third-party Security Service Edge (SSE) for Cross-Cloud Network traffic. You can use Secure Access Connect with NCC Gateway to securely connect remote workforces to private applications in Google Cloud, on-premises, or other cloud providers and to public applications, like Palo Alto Networks Prisma Access and Symantec Cloud Secure Web Gateway.

You can use custom constraints to define your own restrictions on Google Cloud services for Network Connectivity Center resources. To learn about which Network Connectivity Center resources support custom constraints, and some sample use cases, see Use custom organization policies for Network Connectivity Center.

This feature is available in General Availability for the following resources:

• Hubs
• Spokes

It is available in Public preview for the Groups resource.

IPv4 address range filtering for VPC spokes is available in public preview.

This feature lets you change IPv4 address ranges for VPC spokes that are specified to be exported to hub.

IPv6 subnet exchange is generally available.

You can use export filters to configure a VPC spoke to exchange IPv6 subnet ranges or both IPv4 and IPv6 subnet ranges. For more information, see VPC connectivity with export filters.

Site-to-site data transfer locations in the following countries have been added to Network Connectivity Center:

• Belgium
• Canada
• Chile
• Finland
• Israel
• Mexico
• Sweden

VPC spoke updates for IPv6 subnet exchange is available in public preview.

You can update, or propose updates to, an existing VPC spoke to enable or disable the exchange of IPv6 subnet ranges. For information about updating spokes, see Update whether a VPC spoke exports IPv6 subnet ranges. For information about accepting proposed updates to spokes, see Review proposed spokes.

Producer VPC Spokes is generally available.

If you have a VPC network that consumes a service offered through private services access, you can use a Network Connectivity Center producer VPC spoke to make the service reachable by other spokes on a hub.

Private Service Connect connection propagation is asynchronous after spoke creation or deletion. When a VPC spoke is removed from a hub, it can take some time to update propagated Private Service Connect connections. While the Private Service Connect propagation connection update is in progress, traffic from the VM within the VPC network can flow to the backend, even after the VPC spoke is added to a new hub. To avoid this issue, we recommend that before adding the spoke to another hub, make sure that all of the propagation status entries for the VPC network in the previous hub, whether as a source spoke or a target spoke, are deleted.

Feature

Private Service Connect connection propagation is generally available.

Connection propagation through the Network Connectivity Center hub provides access to Private Service Connect endpoints from other VPC networks.

Route exchange with VPC spokes is generally available.

This feature lets you connect VPC spokes and hybrid spokes, such as Cloud Interconnect VLAN attachments, HA VPN tunnels, and Router appliance VMs on the same hub.

Note that you are billed for Advanced Data Networking (ADN) for traffic originating from Google Cloud Platform egressing through hybrid spokes.

Issue

See the following known issues for dynamic route exchange:

• Routing VPC networks that are also VPC spokes: A routing VPC network should typically contain hybrid spokes. However, if you do configure a routing VPC network as a VPC spoke, the following limitations apply:
  • A routing VPC network can also be a VPC spoke only if there are no other routing VPC networks on the hub. A hub supports two or more routing VPC networks only when none of the routing VPC networks are VPC spokes.
  • The site-to-site data transfer setting is not honored for hybrid spokes in a routing VPC network that is also a VPC spoke.
• Dynamic route interaction rules: Within a routing VPC network, for each unique dynamic route destination with a next hop in a hybrid spoke, you must ensure that all other dynamic routes, regardless of priority, whose destinations exactly match or fit within the unique dynamic route destination, have next hop Cloud VPN tunnels or VLAN attachments also in a hybrid spoke. Further, you must ensure that those hybrid spokes use the same site-to-site data transfer setting (either enabled or disabled).
  • If only some next hops for dynamic routes with a common destination are in hybrid spokes, Network Connectivity Center can't reliably exchange dynamic routes that use that destination with VPC spokes on the hub. Consequently, VPC spokes might not receive those dynamic routes.
  • Network Connectivity Center doesn't perform ECMP among all next hops of hybrid spoke dynamic routes if some hybrid spokes have site-to-site data transfer enabled but other hybrid spokes have site-to-site data transfer disabled. If dynamic routes with a common destination are in hybrid spokes without matching site-to-site data transfer settings, next hops for site-to-site data transfer or for connectivity between VPC spokes and on-premises networks might not be what you expect.
• Dynamic route and static route interaction rules: Within a routing VPC network, for each unique dynamic route destination that has a next hop in a hybrid spoke, you must ensure that no local static routes exist, regardless of priority, whose destinations exactly match or fit within the dynamic route destination.
  • If a local static route in the routing VPC network has the same destination as a hybrid spoke dynamic route, VPC spokes might lose connectivity to the dynamic route destination.
  • If a local static route in a routing VPC network has a destination that fits within the destination of a hybrid spoke dynamic route, VPC spokes lose connectivity to the static route destination.

IPv6 subnet exchange is available in public preview.

You can use export filters to configure a VPC spoke to exchange IPv6 subnet ranges or both IPv4 and IPv6 subnet ranges. For more information, see VPC connectivity with export filters.

Producer VPC Spokes is now available in public preview.

If you have a VPC network that consumes a service offered through private services access, you can use a Network Connectivity Center producer VPC spoke to make the service reachable by other spokes on a hub.

Preset topologies and include export filters are generally available.

Preset topologies let you specify the connectivity configuration across all VPC spokes. You can choose between mesh or star preset topologies. Include export filters lets you limit connectivity by specifying a list of permitted CIDR ranges, thereby blocking all but the permitted IP address ranges.

Route exchange with VPC spokes is now available in public preview.

This feature lets you lets you connect VPC spokes and hybrid spokes, such as Cloud Interconnect VLAN attachments, HA VPN tunnels, and Router appliance VMs on the same hub.

Include export filters is now available in public preview.

This feature lets you limit connectivity by specifying a list of permitted CIDR ranges, thereby blocking all but the permitted IP address ranges.

Private Service Connect connection propagation is now available in public preview.

The propagation of Private Service Connect services through the Network Connectivity Center hub enables VPC-hosted services in private VPC networks to be reachable across VPC networks.

Preset topologies are now available in public preview. Network Connectivity Center lets you specify connectivity configuration across all VPC spokes.

The Advanced Data Networking (ADN) traffic is accounted only for large-sized flows (approximately >20 Kbps) that cross VPC boundaries. Currently, small-sized flows are not accounted.

Connecting VPC networks by using Network Connectivity Center is now generally available.

This feature lets you connect two or more VPC networks, represented as spokes, to a hub in the same or a different project for full mesh connectivity.

The issue that you cannot get the status of a long-running operation for a spoke without the networkconnectivity.operations.get IAM permission in the spoke project is now resolved.

The new API and gcloud commands are documented on the Review proposed VPC spokes page. The previous API methods and gcloud commands are now deprecated.

The AcceptSpoke and RejectSpoke API methods and the network-connectivity spokes accept and network-connectivity spokes reject CLI commands have the following usability issue:

• As the user, if you do not have the networkconnectivity.operations.get IAM permission in a spoke project, you cannot get the status of a long-running operation for that spoke.

The issue is being worked on. The workaround is that the spoke administrator can grant the required permissions to the appropriate hub administrator. For information about granting permissions, see Give access.