Professional Cloud Network Engineer
A Router Appliance (RA) is a third-party virtual machine instance running on Compute Engine that acts as a network routing and security gateway for hybrid and multicloud environments. Within Network Connectivity Center (NCC), the Router Appliance attaches to a hub as a hybrid spoke, enabling dynamic route exchange and traffic forwarding between on-premises data centers, other cloud environments, and your Virtual Private Cloud (VPC) networks. The NCC uses a hub-and-spoke architecture where the hub serves as central management infrastructure connecting multiple external networks and VPC networks.
A Router Appliance spoke connects third-party router instances to an NCC hub, allowing the appliance to manage data plane traffic while Cloud Router manages dynamic route exchanges through Border Gateway Protocol (BGP). The Router Appliance VM instance deploys inside a VPC network and establishes BGP sessions with Cloud Router over internal IP addresses. Multiple hybrid spoke types—including Router Appliance instances, Cloud Interconnect VLAN attachments, and Cloud VPN tunnels—can attach to the same hub to exchange connectivity across sites. When deploying appliances across multiple networks, a single VM instance with multiple network interfaces can associate with multiple spokes only if each interface connects to a different spoke and site-to-site data transfer is disabled.
Administrators create the Router Appliance spoke using the Google Cloud console, the gcloud network-connectivity spokes linked-router-appliances create command, or the REST API projects.locations.spokes.create method. During creation, administrators specify the target hub, the Google Cloud region, the VM instance URIs, and the corresponding internal IP addresses of each router appliance interface. Two important configuration options exist: enabling site-to-site data transfer allows traffic to flow directly between hybrid spokes across different sites through Google's network, and setting the --include-import-ranges parameter to ALL_IPV4_RANGES instructs the spoke to import and propagate advertised subnet routes from the hub to the hybrid spoke endpoints.
Cloud Routers and external peering appliances integrated with NCC hubs must follow strict Autonomous System Number (ASN) rules to ensure deterministic route propagation and avoid routing loops. All Cloud Routers managing BGP sessions for hybrid spokes attached to a single NCC hub must use the same Cloud Router ASN within a given region, and this ASN must be a private ASN defined by RFC 6996 (range 64512-65534 or 4200000000-4294967294). On the peer network side, all peering router instances associated with a single spoke must use the same ASN when advertising routes to Cloud Router, while different spokes attached to the hub must use distinct ASNs to differentiate route origins. If two peer appliances in the same spoke advertise identical IP prefixes with mismatched ASNs or AS paths, Cloud Router only readvertises one peer's ASN and path across the hub.
Managing a Router Appliance spoke involves updating instance associations, monitoring resource usage, and detaching resources when decommissioning connectivity. Administrators can add or remove VM instances from an active spoke using the Google Cloud console or modify the underlying instance using the gcloud network-connectivity spokes linked-router-appliances update command or a REST API PATCH request. Any replacement VM instance must reside in the exact same VPC network as the original instance. Deleting an NCC spoke removes the spoke configuration and disassociates the underlying Compute Engine VM instances from the hub without deleting the VMs themselves. Router Appliance spokes incur a billing charge of $0.075 per spoke hour while in an active state, alongside applicable site-to-site data transfer fees per gibibyte when routing traffic between distinct hybrid endpoints.
Deploying a Router Appliance requires careful planning of its underlying infrastructure and integration with NCC. The primary components are the Compute Engine VM instance running the third-party routing software, the Cloud Router that manages the BGP peering, and the NCC spoke that links them to the hub. The RA instances must be deployed in the same VPC network used for hybrid connectivity, and each instance's network interface must have an internal IP address configured for BGP peering. The RA software image, specifications, and licensing are provided by the third-party vendor, and you must contact that vendor for first-level support.
The deployment model must account for high availability, which typically involves creating a spoke with a pair of redundant RA instances forming a high-availability (HA) pair. For the NCC integration to function, the Cloud Router associated with the RA spoke must be configured with a private ASN as defined in RFC 6996, and both HA shards in a region must use the same Cloud Router ASN. Both shards must always be present to qualify for SLA coverage.
Router Appliance spokes are subject to the same route quotas and limits as Cloud Router, including the maximum number of unique destination prefixes a VPC network can hold, which varies by region. If this quota is exceeded, Cloud Router drops learned routes, starting with IPv6 prefixes, which can cause connectivity loss. There is also a per-project, per-region quota for the number of Router Appliance spokes you can create. Because the RA uses third-party software, the support model is bifurcated: you must contact the software vendor for first-level support on the appliance itself, while Google provides support for the NCC infrastructure, Compute Engine instance, and Cloud Router components.
BGP peering sessions between Router Appliances and Cloud Routers require careful ASN configuration to function correctly. All Cloud Routers in hybrid spokes associated with a single hub must use the same Cloud Router ASN, and this ASN must be a private ASN as defined in RFC 6996 when managing BGP sessions for Router Appliances. The on-premises routers' peering ASNs must all be the same within a single spoke, but different spokes must have different ASNs. When two peers advertise the same prefix with different ASNs or AS paths, only one peer's ASN and AS path gets readvertised for that prefix, which can cause routing inconsistencies if not properly configured.
Cloud Router advertises routes to on-premises or other cloud environments using custom IP range advertisements. The router can advertise the range of the region's proxy-only subnet, which is required for Envoy-based regional load balancers to function properly in hybrid architectures. For hybrid subnet routing scenarios, you must update custom route advertisements by removing routes for migrated workloads while continuing to advertise the subnet range of subnets that had hybrid subnet routing enabled. This ensures that connectivity between migrated workloads and on-premises networks remains intact while removing unnecessary route advertisements.
Route propagation from hub to spoke is controlled through the hybrid spoke filter configuration. When creating a Router Appliance spoke, you can enable the "Include all IPv4 ranges from hub to spoke" option to propagate subnets advertised to the hub down to the hybrid spokes. The includeImportRanges field accepts only the ALL_IPV4_RANGES keyword; if left empty, the hybrid spoke doesn't import any subnets from the hub. Custom routes on VPC Network Peering, combined with custom route advertisement on Cloud Router, enable full route exchange and connectivity between on-premises environments and all spoke VPC networks in hub-and-spoke topologies.
High availability for Router Appliance configurations requires redundant interfaces connected to the same router appliances, with both HA shards in each region going to each peer using the same Cloud Router ASN. You can mix Partner Interconnect (which requires ASN 16550) and other connection types as long as there are correctly configured HA pairs for each connection type. Different Cloud Router ASNs can be used in different regions, providing flexibility for multi-region deployments while maintaining consistency within each region.
StudyCerts
StudyCertsincludeImportRanges field set to ALL_IPV4_RANGES is required for Router Appliance spokes to import subnet routes from the hub; if empty, no hub subnets are imported.Site-to-site data transfer allows traffic to flow directly between hybrid spokes (RA, VPN, or Interconnect) in different sites through Google's network, while subnet route importing (includeImportRanges) controls whether the Router Appliance learns the subnet routes advertised to the hub. If multiple spokes use data transfer, all participating spokes must reside within the same VPC network.
Yes, a single VM instance with multiple network interfaces can associate with multiple spokes only if each interface connects to a different spoke and site-to-site data transfer is disabled. This allows a single appliance to participate in multiple hybrid connectivity scenarios.
Prepare and test your skills
Prepare and test your skills