Network Connectivity Center is a network connectivity product that employs a hub-and-spoke architecture for management of hybrid connectivity. With this architecture, each connectivity resource is represented as a spoke. Each spoke is attached to a central management resource known as a hub.
Network Connectivity Center includes Router appliance. This feature lets you install a third-party network virtual appliance in Google Cloud and use it to exchange routes with Cloud Router.
With these capabilities, you can do the following:
- Connect an external network to Google Cloud by using a third-party SD-WAN router or another virtual appliance. This approach is known as site-to-cloud connectivity.
- Use Google's network as a wide area network (WAN) to connect sites that are outside of Google Cloud. You can establish full mesh connectivity between your external sites by using resources such as Cloud VPN, Cloud Interconnect, and Router appliance. This approach is known as site-to-site data transfer.
- Monitor traffic within your Google Cloud project by using a third-party firewall appliance.
- Use a third-party virtual router to connect your VPC networks to one another. Use this approach if you want an alternative to VPC Network Peering and other hybrid connectivity products.
How it works
This section describes Network Connectivity Center and its components.
A hub is a global management resource to which you attach spokes.
The function of the hub varies depending on whether its spokes are using the site-to-site data transfer feature. When you use this feature, the hub provides full mesh connectivity between all spokes that have the feature enabled.
If data transfer is not enabled for any spokes, then the hub provides connectivity only to Google Cloud resources. The hub does not establish connectivity between these 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 sometimes called a backing resource.
A spoke can use any of the following Google Cloud resources as its backing resource.
Applicable use cases
|Cloud VPN (HA VPN) tunnels,
Dedicated Interconnect VLAN attachments,
and/or Partner Interconnect VLAN attachments
A single spoke can be associated with more than one resource, but all resources must be of the same type. For example, although a single spoke might be associated with multiple VPN tunnels, it can't be associated with both VPN tunnels and router appliance instances.
Each spoke has a data transfer option. When you enable this option for multiple spokes, the hub provides full mesh connectivity between those spokes. This option also has other ramifications. For example, if multiple spokes use data transfer, then the backing resources for those spokes must be located in the same VPC network. For more information, see Site-to-site data transfer overview.
The Router appliance feature lets you install a network virtual appliance within Google Cloud and use it as the backing resource for a spoke.
To create a router appliance instance, you install a virtual appliance image on a Compute Engine virtual machine (VM) and complete certain other setup steps. This setup includes establishing Border Gateway Protocol (BGP) peering between the VM and a Cloud Router. BGP enables the dynamic exchange of routes between the Cloud Router and the router appliance instance. Route exchange lets you establish connectivity between your VPC network and other networks.
For more information, see the Router appliance overview.
The following sections describe the main Network Connectivity Center use cases.
Conduct data transfer over Google's network
Data transfer is the transmission of data between two sites that are outside of Google Cloud. Network Connectivity Center lets you use Google's network for data transfer between multiple on-premises sites or other cloud workloads. This approach lets you take advantage of the reach and reliability of Google's network whenever you need to move data.
When you create a spoke, you can enable or disable data transfer for that spoke. If data transfer is enabled for one or more spokes that are connected to the same hub, then these spokes can all transfer data between one another.
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, Dedicated Interconnect, Partner Interconnect, and Router appliance.
For more information about this use case, see Site-to-side data transfer overview.
Connect an external network to Google Cloud
The Router appliance feature lets you use a third-party network virtual appliance to connect your external site to Google Cloud.
The following topology shows an external site that uses a Router appliance spoke to connect to two VPC networks. In this scenario, the VM that hosts the router appliance image has interfaces in both networks. You use each interface to create a spoke—one for each network. The external network is then able to exchange prefixes with both VPC networks.
For more information about this use case, see Site-to-cloud topologies.
Manage connectivity between VPC networks
The Router appliance feature lets you use a third-party network virtual appliance to enhance your Google Cloud network configuration. For example, you can run a third-party firewall appliance within your Google Cloud project.
The following topology shows a router appliance instance that is running a firewall appliance image. The router appliance VM has interfaces in both networks. You use each interface to create a spoke—one for each network. The firewall appliance is then able to manage connectivity between the networks.
Alternatively, you might want to use a third-party SD-WAN router to provide connectivity between two VPC networks. The preceding topology would also work for this use case.
For more information about this topology, see Sample topology.
Before setting up Network Connectivity Center, review the following sections.
Network Connectivity Center supports IPv4 addressing. It does not support IPv6. For example:
If a spoke has site-to-site data transfer enabled, the resources associated with the spokes support IPv4 traffic. These spokes cannot exchange IPv6 traffic. This statement applies to all spoke types: Router appliance, VLAN attachment, and VPN spokes.
Site-to-cloud Router appliance spokes support IPv4 traffic. IPv6 traffic is not supported.
When you create a VM to use as a Router appliance instance, the VM must use an IPv4 address (specifically, an RFC 1918 address).
Routes installed by a Network Connectivity Center hub 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.
All spoke resources use Cloud Router. Within a single Cloud Router task, AS path is used for best-path selection. Otherwise, only MED is used to prioritize routes. For more information, see AS path prepending and AS path length in the Cloud Router overview.
ASNsAll 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.
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 communities are not supported.
Compatibility with existing network configurations
When you add a VLAN attachment or VPN tunnel to a spoke, the only change to these resources is that more routes are potentially advertised to them. In other words, adding a resource to a spoke does not reduce or lessen existing route propagation to that resource. Rather, the only change is that additional routes can be propagated to the resource to support connectivity with other Network Connectivity Center spokes.
Support for other products
The following sections describe how Network Connectivity Center works with other networking products and features.
VPC Network Peering
You can use VPC Network Peering with Network Connectivity Center as follows: You can peer a network associated with the hub with one or more of your other VPC networks. However, for the network peered with the hub network to send and receive traffic to and from on-premises networks attached to the hub, you must also do the following:
- Use custom route advertisements to announce peer VPC subnets to on-premises networks attached to the hub.
- Enable the import and export of custom routes. This setup makes routes from the on-premises networks attached to the hub visible from the subnets in the peered VPC networks.
Shared VPC networks
When using Shared VPC networks, you must create the hub in the host project.
We recommend assigning the
to administrators of service projects. For details on this role and other
Network Connectivity Center roles, see
Roles and permissions.
Spoke resources cannot be part of a legacy VPC network.
Classic VPN tunnels are not supported.
If you are using data transfer, review the Considerations section in the site-to-site data transfer overview.
- To create hubs and spokes, see Work with hubs and spokes.
- To work through a tutorial on site-to-site data transfer, see Connecting two sites by using Cloud VPN spokes.
- To view a list of partners whose solutions are integrated with Network Connectivity Center, see Network Connectivity Center partners.
- For Network Connectivity Center quotas and limits, see Quotas and limits.