Professional Cloud Network Engineer
Configuring and attaching Cloud VPN spokes to a Network Connectivity Center (NCC) hub connects on-premises or other cloud sites to Google Cloud using HA VPN tunnels. This setup allows for dynamic route exchange and data transfer between sites through a central hub.
A Cloud VPN spoke in NCC is a hybrid spoke type that uses one or more HA VPN tunnels as its connection point. When you create this spoke, you link it to an existing VPN tunnel, which then attaches to a central NCC hub. This allows the hub to learn routes from the on-premises network via BGP sessions over the VPN. For traffic to flow directly between two external sites through Google's network, a process called site-to-site data transfer, all involved hybrid spokes must be in the same VPC network and have this feature enabled on the hub.
For reliable connectivity, each Cloud VPN spoke must be configured for high availability to meet a 99.99% service level objective. This requires creating two VPN tunnels, each terminating on a different HA VPN gateway interface, to provide redundancy. The associated Cloud Router must have active BGP sessions with the on-premises router over each tunnel. Network Connectivity Center monitors the operational state of these spokes; a spoke only becomes active and can pass traffic after its underlying VPN tunnels and BGP sessions are successfully established.
You first create a global NCC hub with a topology like mesh or star. When creating a Cloud VPN spoke, you specify the hub and select the VPN tunnel resources for the attachment. The spoke's activation depends on project ownership: if the hub and spoke are in the same project, the spoke becomes active immediately. If they are in different projects, a spoke administrator proposes the spoke, and a hub administrator must review and accept the proposal before it becomes active. The hub administrator can enable auto-accept for specific projects to bypass manual review.
Once attached and active, the Cloud VPN spoke enables dynamic route exchange. The Cloud Router learns routes from the on-premises network via BGP over the VPN tunnels and advertises them to the NCC hub. The hub then propagates these routes to other spokes, such as other VPN spokes, VLAN attachments, or VPC spokes within the same hub. For site-to-site traffic, routes learned from one VPN spoke are advertised out through the BGP sessions of another VPN spoke in the same VPC network, allowing data to flow between two external sites through Google Cloud. The VPC network must use global dynamic routing mode for routes to be exchanged across different regions.
Site-to-site data transfer in Network Connectivity Center provides IPv4 connectivity between external networks using a Google Cloud VPC network and hybrid spokes. This lets organizations transfer data between multiple on-premises or other cloud networks by leveraging Google's global backbone, avoiding the need for direct connections between remote sites.
You enable the data transfer option when creating a hybrid spoke. When 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 resources associated with any hybrid spoke on that hub. This requires all hybrid spokes to refer to resources in a single VPC network. This re-advertisement creates full mesh connectivity, allowing any connected site to communicate with any other through Google's network.
Hybrid spokes in Network Connectivity Center support IPv4 only for site-to-site data transfer. Routes installed by NCC hybrid spokes are treated as dynamic routes and follow standard VPC routing order rules. When you create a Router appliance VM for a hybrid spoke, the VM's primary internal IPv4 address must be an RFC 1918 address.
All non-Google peering routers associated with a single spoke must use the same Autonomous System Number (ASN) when advertising prefixes to the Cloud Router. This is critical because if two peers advertise the same prefix with different ASNs, only one peer's information is re-advertised. Different spokes must have different ASNs. When using the data transfer feature, you must assign ASNs according to specific requirements, and BGP communities are not supported.
Dynamic routing is available on all hybrid solutions including HA VPN and Cloud Interconnect. It uses Google's Cloud Router as a BGP speaker. You can enable either of the Cloud Router's two modes on each VPC network: regional routing only advertises subnets in the Cloud Router's region, while global routing advertises all subnets of the VPC network across all regions but penalizes routes learned outside their region to maintain routing symmetry.
When you set up a network connectivity product with Cloud Router, you establish BGP sessions between the Cloud Router and the router on the peer network. Each BGP session is unique to the specific network connectivity product; different products cannot share the same session. For sufficient redundancy, you might need multiple BGP sessions, such as with HA VPN. For Partner Interconnect VLAN attachments, the Cloud Router must use the ASN 16550.
Network Connectivity Center (NCC) allows enterprises to manage hybrid connectivity by attaching Cloud Interconnect VLAN attachments as hybrid spokes to a central hub. This connects on-premises data centers to Google Cloud Virtual Private Cloud (VPC) networks and enables communication with other external sites. When registered with site-to-site data transfer enabled, dynamic BGP routes learned by one hybrid spoke are propagated across Google's backbone and advertised to other spokes. The associated VPC network must use global dynamic routing mode for cross-region communication.
High-availability for Cloud Interconnect hybrid spokes requires physical and logical redundancy. Google Cloud defines two availability models:
StudyCerts
StudyCertszone1 and zone2) within a single metropolitan area. They terminate on at least one Cloud Router in the local region. This protects against single-circuit failures but not a full regional outage.For continuous data flow, both attachments in a redundant pair must have enough bandwidth to carry full traffic. On-premises routers must advertise identical IP prefixes over all active BGP sessions to prevent routing issues during failover.
Cloud Router exchanges dynamic routes between VPC networks and external routers over VLAN attachments. For Partner Interconnect, the Cloud Router must use ASN 16550. For Dedicated Interconnect, private ASNs in specified ranges can be used. Cloud Router automatically generates a BGP peer when a VLAN attachment is provisioned.
The BGP peering setup varies by service tier: for Layer 2 Partner and Dedicated Interconnect, you configure BGP directly with the on-premises router. For Layer 3 Partner Interconnect, the service provider manages the BGP sessions. With global dynamic routing mode active, Cloud Router propagates learned routes to all subnets across every region and advertises all global subnet prefixes back to the on-premises network.
Provisioning Partner Interconnect VLAN attachments requires generating and exchanging a secure pairing key with an authorized service provider. The attachment's lifecycle begins in PENDING_PARTNER until the provider fulfills the connection. It then shifts to PENDING_CUSTOMER, requiring the administrator to activate it, transitioning it to ACTIVE. Administrators can optionally enable pre-activation for Layer 3 connections to skip manual approval. Configuring the correct maximum transmission unit (MTU) is crucial. Cloud Interconnect supports MTU sizes of 1440, 1460, 1500, and 8896 bytes (jumbo frames). The MTU on the VLAN attachment must match the MTU on the VPC network and all peered on-premises routers and VMs to avoid fragmentation. A setting of 1460 bytes ensures baseline compatibility.
Registering VLAN attachments as hybrid spokes in an NCC hub creates a managed mesh or star routing architecture. For site-to-site data transfer, all backing VLAN attachments must reside within the exact same VPC network. Cloud Routers in different regions exchange learned prefixes across Google's backbone, allowing distant branches to communicate directly. Traffic engineering is managed by tuning BGP metrics like multi-exit discriminators (MED) or AS path lengths. If a primary VLAN attachment fails, Cloud Router dynamically diverts traffic to a secondary hybrid spoke in another region.
16550 for Partner Interconnect VLAN attachments and can use private ASNs for Dedicated Interconnect.Both are hybrid spoke types in Network Connectivity Center, but they use different underlying resources. A Cloud VPN spoke is backed by HA VPN tunnels, while a VLAN attachment spoke is backed by a Dedicated or Partner Interconnect VLAN connection. Both can be attached to an NCC hub to enable route exchange and site-to-site data transfer.
Enable site-to-site data transfer when you need to allow traffic to flow directly between two or more external on-premises or cloud networks through Google's backbone, without the traffic needing to terminate in your VPC. This requires all involved hybrid spokes to be in the same VPC network and have the feature enabled.
Site-to-site data transfer works by re-advertising routes learned by one hybrid spoke out through the BGP sessions of another. This route propagation and the subsequent data flow are managed within the context of a single VPC network's routing table. Using the same VPC network ensures consistent and predictable routing across all connected sites.
A pairing key is a secure token required to provision a Partner Interconnect VLAN attachment. You generate the key in Google Cloud and provide it to an authorized service provider. The key contains a unique identifier, target region, and edge availability domain, allowing the provider to establish the physical connection to Google's network on your behalf.
Prepare and test your skills
Prepare and test your skills