Hub-and-spoke vs full mesh
Hub-and-spoke and full mesh are two ways to wire a network of sites. In hub-and-spoke, every site (a spoke) connects to one central location (the hub), and any traffic between two spokes is relayed through the hub. In a full mesh, every site holds a direct connection to every other site, so traffic between any two takes a direct path with no central relay.
In hub-and-spoke, every site connects to one central hub and traffic between sites passes through it; in a full mesh, every site connects directly to every other.
The core difference
- 01
Hub-and-spoke is a star: simple to set up and reason about, but all inter-site traffic hairpins through the hub, adding a hop and concentrating load and risk there.
- 02
A full mesh is many-to-many: every pair of sites has a direct path, so traffic takes the shortest route and no single node is on the path of all traffic.
- 03
The hub is both a bottleneck and a single point of failure: if it saturates or goes down, communication between spokes is degraded or lost.
- 04
A full mesh removes that central dependency and improves latency and resilience. The cost is many more links to set up, which automation handles.
When hub-and-spoke makes sense
Hub-and-spoke is easy to operate and can be the right choice when most traffic really does go to a central place, for example branches that mostly reach a single data center or a central inspection point. It keeps the number of links low and centralizes control. Its weaknesses show when spokes need to talk to each other often: each such flow takes two hops through the hub, the hub's capacity caps the whole network, and an outage there cuts the spokes off from one another.
Why full mesh suits distributed networks
As organizations spread across many offices, data centers and clouds, more traffic flows from site to site rather than to one center. A full mesh fits that reality: direct paths keep latency low, no single hub limits throughput, and the failure of one site doesn't cut off the others. The old downside was configuring a tunnel between every pair of sites by hand, a job that grows with the square of the site count. A managed mesh automates it: the gateways discover each other and build the mesh themselves.
How this relates to Vexaro Mesh (in development)
Vexaro Mesh, now in development, is designed as a full-mesh overlay: gateways building a direct, encrypted tunnel between every pair of sites, so traffic takes the shortest path and the controller manages policy without being a concentrator in the data path. That is meant to remove the hub bottleneck and single point of failure of a classic hub-and-spoke WAN, while automatic peering removes the manual work that used to make full meshes hard to run.
See the planned features