Network Connectivity Center is an orchestration framework that simplifies network connectivity among spoke resources that are connected to a central management resource called a hub. Network Connectivity Center supports three types of spokes:
- Virtual Private Cloud (VPC) spokes
- Producer VPC spokes (Preview)
- Hybrid spokes, consisting of:
- HA VPN tunnels
- Cloud Interconnect VLAN attachments
- Router appliance VMs
With the hub and spoke connectivity, you can do the following:
- Connect multiple VPC networks to one another. The VPC networks can be located across different projects in the same Google Cloud organization or different organizations.
- Connect multiple VPC networks to on-premise or other cloud provider networks. These external networks can be reachable through any type of hybrid spoke. This approach is known as site-to-cloud connectivity.
- Use Router appliance VMs to manage connectivity between your VPC networks.
- Use a Google Cloud VPC network as an enterprise wide area network (WAN) to connect networks that are outside of Google Cloud. You can establish connectivity between your external sites by using any type of hybrid spoke. This approach is known as site-to-site connectivity.
How it works
When a hub uses VPC spokes, you can configure connectivity between these VPC networks connected to the hub by exchanging subnet routes between all or some of the VPC networks.
When a hub uses both VPC spokes and hybrid spokes, any to any connectivity is supported across all of these spokes.
When a hub uses hybrid spokes located in a single VPC network, you can also configure site-to-site data transfer so that the dynamic routes whose next hops are a hybrid spoke—for example, a Cloud Interconnect VLAN attachment—are advertised to an on-premises network by the BGP sessions of the other hybrid spokes in that VPC network.
See the following sections for a detailed description of hubs and spokes.
Hubs
A Network Connectivity Center hub is a global resource to which you attach spokes. A single hub can contain spokes from multiple regions. However, if any of the spokes of a hub use the site-to-site data transfer feature, the resources associated with those spokes must all be in the same VPC network. Spokes that don't use site-to-site data transfer can be associated with any VPC network in your project.
Spokes
A spoke represents one or more Google Cloud network resources that are connected to a hub.
When you create a spoke, you must associate it with at least one supported connectivity resource, which is also called a backing resource.
A spoke can use any of the following Google Cloud resources as its backing resource.
VPC spokes
VPC spokes let you connect two or more VPC networks to a hub so that the networks exchange subnet routes. VPC spokes attached to a single hub can reference VPC networks in the same project or a different project (including a project in a different organization).
For detailed information about VPC spokes, see VPC spokes overview.
VPC spokes provide connectivity among IPv4 and IPv6 (Preview) subnet ranges from multiple VPC networks. You can configure each VPC spoke to export subnet ranges as follows:
- Only IPv4 subnet ranges
- Both IPv4 and IPv6 subnet ranges
- Only IPv6 subnet ranges
Consider a spoke whose VPC network has a mix of subnet stack types. If you configure the spoke to export only IPv6 subnet ranges, then IPv6 subnet ranges from dual-stack and IPv6-only subnets are exchanged, but IPv4 subnet ranges from IPv4-only and dual-stack and subnets aren't exchanged.
Producer VPC spokes (Preview)
If you have an existing VPC spoke that consumes a service from a producer network in another project through VPC Network Peering, you can make the service reachable by the other spokes in your Network Connectivity Center hub by creating a producer VPC spoke.
For detailed information about producer VPC spokes, see Producer VPC spokes.
Hybrid spokes
A hybrid spoke represents one or more network connectivity resources that are connected to a hub. A hybrid spoke type can be any of the following resources that a spoke is associated with:
- Router appliance VMs
- HA VPN tunnels
- Cloud Interconnect VLAN attachments
A single hybrid spoke can be associated with more than one resource of the same type. For example, a hybrid spoke can reference two or more HA VPN tunnels, but that same hybrid spoke cannot also reference Router appliance VMs or Cloud Interconnect VLAN attachments. A hybrid spoke must be in the same project as the Network Connectivity Center hub.
Site-to-site data transfer using hybrid spokes requires that the spokes be located in the same VPC network. For more information, see Site-to-site data transfer overview.
Router appliance spokes
A spoke associated with a Router appliance VM instance supports the following use cases:
- IPv4 site-to-cloud connectivity: establish connectivity between an external site and your VPC network resources.
- IPv4 site-to-site data transfer: use Google's network as part of a wide area network (WAN) that includes your external sites to move data between all the sites.
- IPv4 connectivity between VPC networks: use a third-party network virtual appliance to establish connectivity between your VPC networks.
All of the site-to-site spokes that are connected to the same hub must have all of their backing resources in the same VPC network.
HA VPN tunnel spokes
A spoke associated with Cloud VPN (HA VPN) tunnels supports the following use cases:
- IPv4 site-to-cloud connectivity: Establish connectivity between an external site and your VPC network resources.
- IPv4 site-to-site data transfer: Use Google's network as part of a wide area network (WAN) that includes your external sites to move data between all the sites.
All of the appliances linked to from a single spoke, and all of the Cloud VPN tunnels, VLAN attachments, must be in the same VPC network.
Cloud Interconnect VLAN attachment spokes
A spoke associated with Cloud Interconnect VLAN attachments supports the following use cases:
- IPv4 site-to-cloud connectivity: all of the appliances linked to from a single spoke must be in the same VPC network.
- IPv4 site-to-site data transfer: all of the Cloud VPN tunnels, VLAN attachments, or both, must be in the same VPC network.
Route exchange with VPC connectivity
Network Connectivity Center VPC spokes support exchanging the following subnet ranges:
- IPv4 subnet ranges that use private addresses, excluding privately used public IPv4 addresses
- IPv6 subnet ranges (Preview)
IPv4 dynamic routes—that is, routes learned by hybrid spokes through BGP—can also be exchanged with VPC spokes or other hybrid spokes.
Import of hub subnets for hybrid spokes
You can achieve the automatic advertisement of VPC spoke IP subnet ranges to on-premises and other cloud provider networks through BGP by enabling the import of hub subnets for hybrid spokes. When enabled, any new VPC subnets that are created or deleted, and are in the hub route table, are automatically imported by hybrid spokes and advertised through BGP to their remote peers.
To automatically advertise VPC spoke subnet IP address ranges
to hybrid spokes, use the --include-import-ranges flag with the
ALL_IPV4_RANGES field during spoke creation. By default, the
--include-import-ranges field is empty, which means that no hub subnets are
imported to new or existing hybrid spokes until the ALL_IPV4_RANGES is
specified.
For detailed information about how to create hybrid spokes, see Work with spokes.
Custom route advertisement
Custom route advertisement in Cloud Router
gives you manual control over the prefixes that are advertised by hybrid spokes.
You can specify custom advertised routes
(including default routes, 0.0.0.0/0 for IPv4 routes or ::/0 for
IPv6 routes) for all BGP sessions when you don't need automatic advertisement
of VPC spoke subnets. By default, other VPC spoke
subnets are not advertised, which means that on-premises locations don't
automatically learn about the reachability to these IP address ranges.
Considerations for importing hub subnets
Keep the following considerations in mind when using the import hub subnets feature.
- All VPC spoke subnets in the hub route table are
advertised to a hybrid spoke by default if the hybrid spoke has
ALL_IPV4_RANGESspecified in the--include-import-rangesfield. - The route priority followed is landing VPC network subnets, hub subnets, and Cloud Router custom routes in that order.
- Network Connectivity Center prevents overlaps between routing VPC subnets and hub subnets from other VPC spokes.
- If a Cloud Router custom route is exactly the same or overlaps with the landing VPC subnets or hub subnets, that Cloud Router's custom route is ignored.
- The BGP attributes of hub subnets are the same as the hybrid spoke's landing VPC's subnets.
- Cloud Router policies on the BGP session are also applied to Network Connectivity Center imported hub subnets.
- If the routing VPC network of the hybrid spoke sets the dynamic
routing mode to
regional, only hub subnets in the same region as the hybrid spoke are advertised.
Example use cases
The following sections describe the main Network Connectivity Center use cases.
Connect different VPC networks with Network Connectivity Center
When you attach two or more VPC spokes to a hub, Network Connectivity Center provides connectivity through subnet routes among all the VPC networks that are represented by the spokes. Using a hub simplifies the management of large-scale mesh subnet connectivity. See quotas for how many VPC networks can be connected to a hub.
The following diagram shows two VPC spokes.
On-premises connectivity for VPC spokes
VPC spokes can connect to on-premises networks by using hybrid spokes located in other (routing) VPC networks. Each Network Connectivity Center hub supports multiple VPC spokes and Cloud Interconnect VLAN attachments, HA VPN tunnels, or Router appliance VMs added as hybrid spokes. The following diagram shows an example hub with both VPC spokes and hybrid spokes in the same Network Connectivity Center hub.
Connect networks using Router appliance VMs
Network Connectivity Center can use Router appliance VMs in the following two IPv4 connectivity scenarios:
- Connecting a VPC network to an on-premises or other cloud provider network using dynamic routes
- Connecting two VPC networks to each other using dynamic routes
With this option, Cloud Router manages the BGP sessions for Router appliance VMs.
Connect an external network to Google Cloud
The following diagram uses a hybrid spoke with a Router appliance VM to connect two VPC networks to an external network. The Cloud Router VM has one network interface (NIC) in each VPC network.
For more information about this use case, see Site-to-cloud topologies that use a third-party appliance.
Manage connectivity between VPC networks
The following diagram uses a hybrid spoke with a Router appliance VM running specialized firewall or packet inspection software to connect two VPC networks.
For more information, see VPC-to-VPC topology that uses a third-party appliance.
Conduct data transfer over Google's network (site-to-site)
Data transfer provides IPv4 connectivity between external networks using a Google Cloud VPC network and hybrid spokes. You can transfer data between multiple on-premises networks or to other cloud networks.
When you create a hybrid spoke, you can enable the data transfer option for that spoke. When data transfer is enabled for hybrid spokes connected to the same hub, the dynamic routes learned by each Router appliance VM, Cloud VPN tunnel, or Cloud Interconnect VLAN attachment are re-advertised to the other VMs, tunnels, or VLAN attachments associated with any hybrid spoke connected to the same hub. Data transfer requires that all hybrid spokes refer to Router appliance VMs, Cloud VPN tunnels, or Cloud Interconnect VLAN attachments in a single VPC network.
For example, suppose you have data centers in New York, Sydney, and Tokyo. After you use supported resources to connect your VPC network to each of these sites, you could create a spoke to represent each network. After you complete this setup, Network Connectivity Center would provide full mesh connectivity between all three sites.
As shown in the following diagram, you can create spokes that rely on connectivity resources such as Cloud VPN, Cloud Interconnect, and Router appliance.
The diagram doesn't show Cross-Cloud Interconnect, but you can also use Cross-Cloud Interconnect VLAN attachments.
For more information about this use case, see Site-to-site data transfer overview.
Network Connectivity Center considerations
Before setting up Network Connectivity Center, review the following sections.
IP addressing
IP version support depends on the spoke type:
VPC spokes: Network Connectivity Center supports the following IP versions:
Hybrid spokes: Network Connectivity Center supports IPv4 only. For example:
If a spoke has site-to-site data transfer enabled, the resources associated with the spokes support IPv4 traffic only. This statement applies to all hybrid spoke types: Router appliance, VLAN attachment, and VPN spokes.
Site-to-cloud Router appliance spokes support IPv4 traffic only.
When you create a Router appliance VM, the VM's primary internal IPv4 address must be an RFC 1918 address.
Routing
Routes installed by Network Connectivity Center hybrid spokes are treated as dynamic routes.
For information about how dynamic routes are handled in comparison with other types of routes, see Applicability and order in the VPC documentation.
| Resource | Applicable use cases |
|---|---|
| Prioritization | All hybrid spoke resources use Cloud Router. For details about the path selection model used by Cloud Router, see AS path prepending and AS path length in the Cloud Router overview. |
| ASN | All non-Google peering routers that are associated with a single spoke must use the same ASN when advertising prefixes to the Cloud Router. This is important because, if two peers advertise the same prefix with different ASNs or AS paths, only one peer's ASN and AS path is readvertised for that prefix. Different spokes must have different ASNs. That is, if two BGP sessions belong to different spokes, they must have different ASNs. Also, if you are using the data transfer feature, you must assign ASNs as described in ASN requirements for site-to-site data transfer. |
| BGP sessions | BGP communities are not supported. |
Route advertisement changes when using site-to-site data transfer
When you add an Cloud Interconnect VLAN attachment or Cloud VPN tunnel to a hybrid spoke, Network Connectivity Center updates the corresponding BGP session for the VLAN attachment or Cloud VPN tunnel so that it re-advertises the prefixes learned by BGP sessions of the other Cloud Interconnect VLAN attachments or Cloud VPN tunnels connected to any of the hub's hybrid spokes that have the site-to-site data transfer option enabled.
Support for other products
The following sections describe how Network Connectivity Center works with other networking products and features.
VPC spokes and VPC Network Peering
Network Connectivity Center VPC spokes support exchanging the following:
- Valid IPv4 subnet ranges that use private addresses, excluding privately used public IPv4 addresses
- IPv6 subnet ranges (Preview)
- IPv4 dynamic routes
For more information about Network Connectivity Center VPC spokes, see VPC spokes overview.
For details about how routes are exchanged using VPC Network Peering, see route exchange options in the VPC Network Peering documentation.
Even though Network Connectivity Center VPC spokes don't support exchanging static routes, a spoke VPC network can still import the static and routes from another VPC network by using VPC Network Peering.
Additionally, a VPC spoke can still import dynamic routes from another VPC network by using VPC Network Peering. If the other VPC network has dynamic routes with next hop Cloud Interconnect VLAN attachments or Cloud VPN tunnels that connect to an on-premises network, you can connect the spoke VPC network to the on-premises network by using Cloud Router custom route advertisements and VPC Network Peering route exchange options as described in the transit network example of the VPC Network Peering documentation.
Shared VPC networks
When using Shared VPC networks, you must create the hub in the host project. This limitation only applies to hybrid spokes.
We recommend assigning the networkconnectivity.googleapis.com/spokeAdmin role
to administrators of service projects. For details on this role and other
Network Connectivity Center roles, see
Roles and permissions.
Legacy networks
Spoke resources cannot be part of a legacy network.
VPN tunnels
Classic VPN tunnels are not supported.
Data transfer
If you're using data transfer, review the Considerations section in the site-to-site data transfer overview.
Service level agreement
For information about the Network Connectivity Center service level agreement, see Network Connectivity Center Service Level Agreement (SLA).
Pricing
For information about pricing, see Network Connectivity Center pricing.
What's next
- To learn how to manage hubs and spokes, see Work with hubs and spokes.
- To learn how to use Cloud VPN spokes, see Connect two sites by using Cloud VPN spokes.
- To obtain a list of partners whose solutions are integrated with Network Connectivity Center, see Network Connectivity Center partners.
- To view Network Connectivity Center quotas and limits, see Quotas and limits.