What is a Hub-and-Spoke Topology?

A hub-and-spoke topology is a branch-network design in which one or more central hub sites relay traffic between spoke (branch) sites and toward shared resources or the internet. Administrators choose how directly spokes may reach each other by selecting a spoke-to-hub-only, spoke-to-spoke-via-hub, or spoke-to-spoke-direct configuration.

Key takeaways

• Spoke (branch) sites connect to a central hub, which relays their traffic.
• Three spoke-group types control how much spokes talk to each other.
• Cheaper and simpler to deploy than full-mesh or partial-mesh topologies.
• Versa Director and Titan automate hub-and-spoke setup through workflows.
• Spoke-hub-hub-spoke (SHHS) links regional hub islands for large networks.

On this page: Why it matters · How it works · Types · Hub-and-Spoke Topology & Versa · FAQ

Why is a hub-and-spoke topology important?

Full-mesh connectivity, where every site connects directly to every other, is efficient but expensive to maintain. A hub-and-spoke topology solves that by concentrating routing at one or more hub sites: each spoke builds a relationship with the hub instead of with every peer, and the hub relays traffic onward toward other branches, a data center, or the internet.

That concentration is why hub-and-spoke is the default shape for most enterprise deployments. A new branch needs only one relationship, with the hub, so it is simpler and cheaper to run than a mesh, and it gives network teams one predictable place to apply policy and internet breakout. The tradeoff is that the hub becomes a chokepoint: its capacity and availability bound the whole network, which is why hub redundancy matters.

What is a hub-and-spoke topology?

In a hub-and-spoke deployment, at least one node is a hub and one or more nodes are spokes, and each spoke builds tunnels to its hub rather than to other spokes directly. The Solution Architecture documentation describes how this changes key management: instead of every spoke maintaining IPsec keys with every other spoke, the Controller distributes route and security-association information through the hub, so spokes need only roughly N+1 keys rather than N².

What spokes may do with each other is controlled by spoke groups – named objects, described in Configure Basic Features and the Titan Portal guide, that bind spoke templates to a hub and a route-advertisement policy. A device’s topological role – Full Mesh, Hub, Hub Controller, or Spoke – is set on its template; spokes additionally name their spoke group.

Types of hub-and-spoke topologies

A spoke group’s type sets how much a spoke can talk to its peers: three base patterns, plus one composite design for large networks. Spoke to hub only routes everything through the hub and blocks spoke-to-spoke traffic – the choice when spokes only need outward access to central services. Spoke to spoke via hub lets spokes reach each other, but every packet still transits the hub, which imports routes from one spoke and re-exports them to the others. Spoke to spoke direct removes the hub from the data path for spokes in the same group, connecting them in a full mesh so they exchange LAN routes directly while still reaching other groups through the hub. For networks spread across regions, spoke-hub-hub-spoke (SHHS) interconnects islands of spokes through their regional hubs.

Hub-and-Spoke Topology & Versa

Versa implements hub-and-spoke at the device-template level. In Director, an SD-WAN device template’s topological role is set to Full Mesh, Hub, Hub Controller, or Spoke; spoke templates additionally name a spoke group, and the Director workflow that builds a hub-and-spoke topology generates the route-advertisement configuration automatically instead of requiring hand-built policy per site. The Versa Controller distributes routes and IPsec security associations between hubs and spokes, so spokes never need a full mesh of IKE keys with every peer.

Versa Titan’s cloud dashboard exposes the same model: a site’s topology is Hub, Hub Controller, or Spoke, and spoke groups are created from the Inventory dashboard with a name, a type, a region, and the anchoring hub. Both Director and Titan default new devices to full mesh, so hub-and-spoke is an explicit choice, not the default.

Frequently asked questions

What is the difference between hub-and-spoke and full-mesh topologies?

In a full-mesh topology every site connects directly to every other site, giving the lowest latency but the most tunnels and keys to manage. Hub-and-spoke instead routes spoke traffic through one or more hubs, trading some path efficiency for a simpler, cheaper network.

Can spokes communicate directly with each other in a hub-and-spoke topology?

It depends on the spoke group type. Spoke-to-hub-only blocks spoke-to-spoke traffic entirely; spoke-to-spoke-via-hub allows it but routes every packet through the hub; spoke-to-spoke-direct connects spokes in the same group directly, bypassing the hub while still reaching other groups through it.

What is a hub controller?

A hub controller is a hub that also takes on the Controller’s control-plane role on the same node. It is used when branches sit on a private network, such as MPLS, with no direct path to a cloud-hosted Controller, so it supplies that reachability locally.

What is a spoke-hub-hub-spoke (SHHS) topology?

SHHS interconnects islands of spoke devices through their regional hubs, grouping hubs and spokes by region. It suits large, geographically dispersed networks where one hub cannot economically serve every spoke, letting spokes in different regions reach each other through their hubs.

Is hub-and-spoke the default topology for a new SD-WAN device?

No. Both Versa Director and Versa Titan default a new SD-WAN device template to full mesh. Hub-and-spoke is configured explicitly by setting a device’s topological role to Hub, Hub Controller, or Spoke and, for spokes, assigning a spoke group by name.

Related terms

If you’re reading about hub-and-spoke topologies, these are worth looking at next.