What is a Spoke?

A spoke is a branch-site VOS device in a Versa SD-WAN hub-and-spoke topology, connecting to at least one hub over the internet, MPLS, or both. It combines performance metrics collected locally with metrics exported from its hub to select the best path to an application.

Key takeaways

• A spoke is a branch VOS device that connects to at least one hub.
• Four hub-and-spoke topology types govern how spokes communicate.
• Spokes blend local and hub-exported metrics to pick the best path.
• Spoke groups let branches in the same group reach each other directly.
• Multicast spokes join cluster lists shared with their hub for PIM.

On this page: Why it matters · How it works · Types · Spokes & Versa · FAQ

Why are spokes important?

Hub-and-spoke is the most common SD-WAN topology because it maps naturally onto how branch networks are built: many small sites, a few central locations, and traffic that mostly needs to reach the center rather than each other. Spokes are the branch half of that model, and they are what most SD-WAN deployments are mostly made of – retail stores, bank branches, clinics, and remote offices, each running a VOS device with LAN ports for local endpoints.

The spoke role matters operationally as much as topologically. Because spokes typically only need to monitor paths toward their hub rather than toward every other branch, hub-and-spoke designs generate far less SLA-monitoring traffic than a full mesh – a meaningful saving on low-bandwidth circuits. Spoke count is also what makes hub-and-spoke cheap and agile to grow: adding or removing a branch is a template push to one device, not a mesh-wide reconfiguration.

What is a spoke?

A spoke is a Versa Operating System (VOS) edge device deployed at a branch site. Like every VOS device, it has the same underlying feature set as a hub – the distinction is topological, not capability-based – but a spoke is configured, via a Workflow template, to connect outward to one or more hubs rather than to host other branches. Spokes and hubs both connect to the SD-WAN Controller, part of the Versa headend, over a transport network.

For application path selection, a spoke does more than measure its own links: passive inline monitoring collects response-time and loss metrics for SaaS sessions transiting the device, active monitoring probes SaaS locations directly, and metrics exported from other sites – including hubs – are folded into the same decision. The SD-WAN policy then steers traffic over whichever path the combined data says performs best, whether that is a local breakout or a path through the hub.

Types of hub-and-spoke topologies

Versa SD-WAN supports four hub-and-spoke variants, selected in the spoke group template. In spoke-to-hub-only, spokes exchange traffic solely with the hub and are unaware of each other – suitable for star-shaped use cases like centralized point-of-sale traffic. Spoke-to-spoke through a hub lets spokes reach each other, but every packet transits the hub first, useful past roughly 100 sites or where central inspection is required. Spoke-to-spoke direct places spokes in full-mesh spoke groups so members reach each other directly, falling back to the hub only for spokes in different groups or when a shared transport is unavailable.

Spoke-hub-hub-spoke (SHHS), also called regional mesh, groups hubs and spokes into regions; any topology can apply within a region, and inter-region traffic transits the regional hubs, which tag routes with region-specific BGP community strings. SHHS scales large, geographically dispersed deployments better than a single flat hub-and-spoke topology.

Spokes & Versa

Spokes, hubs, and hub controller nodes are provisioned from three separate Workflow templates in Versa Director, letting an operator push a consistent baseline configuration to many branches at once. BGP community strings (for example, 8000:x per topology, 8010:x per spoke group) drive route filtering between spokes so that only the intended prefixes – hub routes only, or routes from same-group spokes – appear in a spoke’s route table.

Multicast follows the same shape: a spoke joins a multicast cluster, a group of up to 64 branches and hubs that form PIM relationships only among themselves, configured with a shared cluster-list number and routing instance. A spoke acting as a last-hop router typically points its static rendezvous point (RP) configuration at the hub. Operators monitor a spoke’s SD-WAN status, PIM state, and multicast group membership from the Services tab on Director’s Monitor screens or from the device CLI, as covered in Hub-and-Spoke Topology Overview, the Consolidated SD-WAN Design Guide, and Configure IP Multicast.

Frequently asked questions

What is the difference between a hub and a spoke?

Both run the same VOS software and feature set; the difference is topological role. A hub is typically sited in a data center or PoP and relays traffic for the branches connected to it. A spoke is a branch device that connects outward to at least one hub rather than hosting other sites.

Can spokes communicate directly with each other?

It depends on the topology. In spoke-to-hub-only, they cannot. In spoke-to-spoke through a hub, they communicate but traffic transits the hub. In spoke-to-spoke direct, spokes in the same spoke group reach each other directly over a full mesh, falling back to the hub otherwise.

How does a spoke choose the best path to an application?

A spoke combines locally collected metrics – passive monitoring of live sessions and active probes to SaaS locations – with metrics exported from other sites, including its hub. SD-WAN policy uses this combined view to steer each application’s traffic over the best-performing path available.

How many spokes can connect to one hub?

The topology overview and design guide don’t state a hard per-hub spoke ceiling; sizing instead follows practical limits such as multicast cluster membership, which caps at 64 branches and hubs per cluster, and general guidance to move past full mesh toward hub-and-spoke once a tenant exceeds roughly 100 sites.

Do spokes participate in IP multicast?

Yes. A spoke acting as a last-hop router joins a multicast cluster with its hub, sharing a cluster-list number and routing instance so PIM relationships form only within that group. The spoke typically points its rendezvous-point configuration at the hub rather than acting as an RP itself.

More on hub-and-spoke topology

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about spokes, these are worth looking at next.