GCP Architecture Series #82 — Network Connectivity Center: Hubs and Spokes

Business Challenge

#81 left two problems: peering gives no transitive routing, and its address-overlap constraint reaches one hop further than its connectivity does. This is the product built for the first one. Network Connectivity Center (NCC) is an orchestration framework that simplifies network connectivity among spoke resources that are connected to a central management resource called a hub, and the headline capability is exactly what peering withholds: when a hub uses both VPC spokes and hybrid spokes, any to any connectivity is supported across all of these spokes.

The stated purpose is explicitly a reaction to the pairwise model — VPC spokes reduce the operational complexity of managing the individual pair-wise VPC Network Peering connections through the use of VPC spokes and a centralized connectivity management model — and there is no performance penalty for the indirection: both products are documented at lowest latency, highest throughput (VM-VM equivalent).

What I did not expect is how firmly the two products refuse to be combined.

Architecture

One global hub, four kinds of spoke, and a route exchange you control in only one direction.

The hub, and the one thing that constrains its reach

The topology resource is deliberately unbounded by geography: an NCC hub is a global resource to which you attach spokes, and a single hub can contain spokes from multiple regions. It crosses tenancy boundaries too, matching peering rather than Shared VPC — the VPC networks can be located across different projects in the same Google Cloud organization or different organizations.

There is one feature that collapses that freedom, and it is worth knowing before designing around the hub's global nature: however, if any of the spokes of a hub use the site-to-site data transfer feature, the resources associated with those spokes must all be in the same VPC network. So the moment you want Google's backbone to carry traffic between two external sites, the hybrid spokes involved must share a single VPC network. A hub can be global, or it can do site-to-site data transfer across arbitrary networks, but not both.

Spokes come in four kinds — VPC, producer VPC, NCC Gateway and hybrid — and the hybrid kind has a homogeneity rule that catches people building redundancy. A single hybrid spoke can be associated with more than one resource of the same type, which is how you attach several HA VPN tunnels to one spoke, but mixing is prohibited: that same hybrid spoke cannot also reference Router appliance VMs or Cloud Interconnect VLAN attachments. A VPN-and-Interconnect design therefore needs two spokes, not one. Hybrid spokes are also project-bound: a hybrid spoke must be in the same project as the NCC hub, where VPC spokes need not be.

You choose what you send, not what you receive

This is the asymmetry I would want on a design review checklist. On the way out, NCC gives you more control than peering does: VPC spokes only support export filters, and those filters are expressive — the comparison table notes it supports both include export ranges and exclude export ranges, against peering's "specific filters aren't supported".

On the way in there is no control at all: VPC spokes import all routes from their spoke group of the NCC hub. The mechanics are stated plainly — VPC spokes export subnet routes to the hub and import subnet routes and dynamic routes from the hub — so joining a hub is an unconditional acceptance of whatever every other spoke has chosen to publish, including dynamic routes that hybrid spokes learned from on-premises BGP.

Star topology puts non-transitivity back on purpose

There are two presets — mesh topology star topology — and the difference is not cosmetic. Mesh gives the any-to-any behaviour the product is sold on. Star does not, and the documentation says so while explaining why peering is permitted there: this is because NCC doesn't connect spokes in the edge group to each other.

That is a useful thing to have available. Several of this block's posts have wanted a hub-and-spoke shape where spokes reach a shared services network but not one another — the classic shape for isolating tenants or environments — and star provides it as a preset rather than as a filter exercise. It also means "we use NCC" says nothing about whether two spokes can talk; the topology choice does.

What a VPC spoke still cannot do

Three limits are worth knowing before replacing a peering design wholesale. Static routes exchange across VPC spokes isn't supported, though a documented workaround exists using next-hop internal passthrough load balancers in another spoke. IPv6-based internal passthrough Network Load Balancers aren't reachable among VPC spokes. And a spoke is singly homed: a VPC spoke can be connected to one hub at a time.

Two exclusions repeat the pattern of the last several posts. Spoke resources can't be part of a legacy network — the fifth consecutive post where legacy networks are simply out — and classic VPN tunnels aren't supported, so an estate still running Classic VPN needs HA VPN before it can attach that connectivity to a hub. On the BGP side, BGP communities aren't supported, which rules out the usual tagging-based route policy that a network team arriving from on-premises would reach for first.

Why This Architecture Holds Up

Three things here will produce an incident rather than an error message, and all three are documented.

The quota that drops routes

Most quotas refuse a create call. This one discards working configuration. On dynamic routes per hub, this quota counts usage by destination (prefix) only , without regard to the priority or next hop of a dynamic route, and then: when the usage of this quota exceeds its limit, NCC drops routes by destination.

Two consequences follow. Because counting is by destination only, redundancy is free against this quota — four paths to one prefix count once — which is unusual and worth knowing. And because the enforcement is dropping rather than rejecting, the failure arrives as unreachable prefixes after somebody else's spoke advertised more routes, with nothing in your own change history to explain it. That makes this quota a thing to monitor rather than a thing to look up once, which is precisely what the documentation asks for.

The cool-down nobody waits for

Moving a VPC network from one hub to another has a timing requirement: for a new spoke for the same VPC network attached to a different hub, you must wait for the cool-down period of at least 10 minutes. The consequence of impatience is not an error but a silent misconfiguration — the documentation says the new configuration might not take effect. And the scope is narrow: this cool-down period isn't needed if the VPC network is added as a spoke to the same hub.

So a hub migration script that deletes and recreates in sequence will work when re-attaching to the same hub and fail intermittently when moving between hubs, which is the worst possible distribution of outcomes for something nobody will think to test.

Admission is the real control, and it is asymmetric

Given that spokes cannot filter imports, who may join matters more than what they advertise — and the gate depends on project boundaries. When a spoke administrator creates a VPC spoke in the same project as the hub, NCC adds the VPC spoke immediately. Across projects there is a review step: when a spoke administrator creates a VPC spoke in a project different from the NCC hub project, NCC creates a spoke proposal which a hub administrator must approve before the VPC spoke becomes active.

That is a sensible default and it has a sharp edge: anyone with spoke-admin rights inside the hub's own project can attach a network with no review at all. The hub project is therefore the one project whose spoke-admin grants deserve the same scrutiny #80 argued for the lien.

The Shared VPC story joins up cleanly with #79 and #80. Shared VPC networks can be added as VPC spokes to a NCC hub, and the delegation advice follows the same shape as Shared VPC's own: we recommend assigning the networkconnectivity.googleapis.com/spokeAdmin role to administrators of service projects.

One more control behaves exactly like #79's organization policy constraints, which by now is a recognisable pattern: when a new VPC Service Controls perimeter is added, you can't add new spokes that violate the perimeter. But however, existing spokes that you added before adding the VPC Service Controls perimeter continue to function. Prospective only, again — the perimeter gates growth and audits nothing.

The BGP rules, for anyone attaching hybrid connectivity

Three sentences constrain how external routers may be numbered, and getting them wrong produces partial route propagation rather than a clean failure. Within a spoke, consistency is required: all non-Google peering routers that are associated with a single spoke must use the same ASN when advertising prefixes to the Cloud Router. Across spokes, distinctness is required: different spokes must have different ASNs.

The reason for the first rule is the part worth carrying: 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. So an inconsistent pair does not error — one of them is silently chosen and the other's path disappears, which is the same shape as #81's "internal algorithm selects one peer" and #78's non-deterministic mirroring policy. Three products in this block now resolve an ambiguity you created by quietly picking one answer.

Key Architecture Decisions

The one to look at today

If you run a hub, list every VPC spoke and then list every peering those spokes still hold. Each of those peerings is a network that one spoke can reach and the rest of the hub cannot, which is almost never what the topology diagram shows. Then check who holds spoke-admin in the hub's own project, because those principals can attach a network — and therefore publish routes to every other spoke — with no approval step at all.

Closing Thought

The thing I will carry from this one is that NCC does not fix peering; it replaces it, and the documentation is unusually careful to prevent you from running both for the same pair of networks. That is a stronger design position than it first appears. Two paths for one prefix is exactly the ambiguity #81 showed resolving by an internal algorithm ahead of priority, and the cleanest way to avoid that class of bug is to make the second path impossible to configure. The single permitted exception — peering between two edge spokes in a star — exists only where the hub has already declined to offer a path, which is the same rule stated from the other side.

The other thing is that #62 has now been billed twice in two days. Auto mode made peering impossible through guaranteed address collision, and it makes spoke membership impossible outright, with a conversion you cannot reverse. Twenty-two posts in, the pattern worth naming is not that defaults are bad — auto mode is a perfectly good way to start — but that the cost of a default is paid in a different document, months later, by someone who was not party to the decision and will read it as a limitation of the product they are currently holding.

Official Google Cloud Reference

• Network Connectivity Center overview
• VPC spokes overview
• Spoke filters overview
• Preset connectivity topologies
• NCC access control
• Work with hubs and spokes
• NCC quotas and limits
• VPC Network Peering overview
• Shared VPC overview
• Cloud Router overview
• VPC networks overview