Design, implement, and secure Google Cloud networks, from VPCs and hybrid connectivity to load balancing and Cloud Armor, and track your readiness for the Professional Cloud Network Engineer exam.
Prepare and test your skills
Prepare and test your skills
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:
zone1 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.Achieving 99.99% availability requires at least four VLAN attachments partitioned evenly across two distinct Google Cloud regions and two separate metropolitan areas. Each region must host two VLAN attachments in separate edge availability domains managed by a regional Cloud Router. Additionally, both attachments in a redundant pair must have enough bandwidth to carry full traffic, and on-premises routers must advertise identical IP prefixes over all active BGP sessions.
All non-Google peering routers associated with a single spoke must use the same ASN when advertising prefixes to the Cloud Router, and different spokes must have different ASNs. For Partner Interconnect VLAN attachments, Cloud Router must use ASN 16550, whereas Dedicated Interconnect can use private ASNs in specified ranges. Additionally, BGP communities are not supported when using the site-to-site data transfer feature.
A VPC network must use global dynamic routing mode because regional dynamic routing only advertises subnets within the Cloud Router's local region. Global dynamic routing mode enables Cloud Router to advertise all VPC subnets across all regions and exchange learned routes across Google's backbone, allowing hybrid spokes in different regions to communicate.
Last updated