Network Connectivity Center is a network connectivity product that employs a hub-and-spoke architecture for connectivity management. 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. When you use this approach, the appliance can exchange routes with Cloud Router by using Border Gateway Protocol (BGP).
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 appliance. This approach is known as site-to-cloud connectivity.
- Use a third-party network virtual appliance to manage connectivity between your Virtual Private Cloud networks.
- 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 third-party network virtual appliances. This approach is known as site-to-site data transfer.
How it works
With Network Connectivity Center, each connectivity resource is represented as a spoke. Each spoke is attached to a central management resource known as a hub.
Hubs
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.
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.
Resource |
Applicable use cases |
|---|---|
| Router appliance |
|
| Cloud VPN (HA VPN) tunnels, Cloud 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.
Router appliance
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.
Use cases
The following sections describe the main Network Connectivity Center use cases.
Use a third-party network virtual appliance
Network Connectivity Center lets you use any third-party network virtual appliance that supports BGP. You can use the appliance to connect an external network to your VPC network or to connect multiple VPC networks to one another. To configure a third-party appliance, you use the Router appliance feature. These approaches are described in the following sections.
You can also use a third-party appliance as part of a data-transfer strategy. For details on that approach, see Conduct data transfer over Google's network.
Connect an external network to Google Cloud
The following diagram shows an external topology that uses a Router appliance spoke to connect to an external site with 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 that use a third-party appliance.
Manage connectivity between VPC networks
You can use the Router appliance feature to connect multiple VPC networks. The appliance can be an SD-WAN router, a firewall, a load balancer, or something else.
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 mediate connectivity between the networks.
Although this topology shows a firewall appliance, you could use the same topology for another type of appliance.
For more information, see VPC-to-VPC topology that uses a third-party appliance.
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 the Google 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 the Google 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, 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.
Considerations
Before setting up Network Connectivity Center, review the following sections.
IP addressing
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).
Routing
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.
Prioritization
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.
ASNs
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.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.
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 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 are 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 the pricing, see Network Connectivity Center pricing.
What's next
- 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.