A hub and spoke topology connects every site to one central site and to nothing else. Ten sites need ten links rather than the forty five a full mesh would need. The costs are that spoke to spoke traffic goes the long way, and that the hub fails for the whole network.
- Links needed: n, against n(n-1)/2 for a full mesh
- Spoke to spoke traffic hairpins through the hub
- The hub is a single point of failure for every site
- Two circuits at the hub do not fix that. A second hub does
- SD-WAN is this topology for policy and a partial mesh for traffic
On this page
The arithmeticWhy the arithmetic decides it
The reason this topology dominates wide area network design is a formula rather than an opinion.
A full mesh topology, where every site has a direct link to every other site on the network, needs n(n-1)/2 links. A hub and spoke network needs n. Those two numbers diverge fast.
| Sites | Hub and spoke links | Full mesh links |
|---|---|---|
| 3 | 3 | 3 |
| 5 | 5 | 10 |
| 10 | 10 | 45 |
| 20 | 20 | 190 |
| 50 | 50 | 1,225 |
At three sites the two topologies are the same and you may as well mesh them. At ten the mesh costs four and a half times as much in circuits, tunnels, firewall rules and devices to monitor. At fifty it is not a decision anybody makes.
Two things beyond cost push the same way.
Policy lives in one place. Filtering, inspection, logging and internet access all happen at the hub, so one set of shared services covers every connected site. That is one configuration to maintain and one place to look. In a mesh topology, each site on the network either needs its own security policy or has to be trusted.
Adding a site is one link. A new spoke connects to the hub and joins the network. In a full mesh, a new site means a new link to every existing one, and every existing site on the network changes too.
The two costsThe two costs, which are both real
Every packet between spokes goes through the hub. Two offices in the same city, connected to a data center three hundred kilometers away, send data to each other via that data center.
The distance is doubled, and the latency with it. For file transfers this is a shrug. For a phone call between the two offices it is audible, and for a remote desktop session it is unpleasant.
This is called hairpinning, and it is the specific thing that makes people look at other WAN topologies.
The hub is a single point of failure of a particular kind. In a mesh topology, losing one site loses that site. In a hub and spoke network, losing the hub loses everything: every spoke loses connectivity to the others and, if internet access is centralized, to the internet too.
That second cost is worth being precise about, because the usual mitigation is misunderstood. Two internet connections at the hub protect against a circuit failing. They do nothing about the hub site itself losing power, burning down or having its firewall fail. Protecting against that requires a second hub somewhere else, which is a different and larger decision.
Middle groundsThe middle grounds
Between one hub and a full mesh sit three topologies, and one of them is what most growing business networks actually end up with.
Two hubs. Every spoke is connected to both. The link count doubles to 2n, which is still nothing like a mesh topology, and the single point of failure is gone. This is the standard answer once the network matters enough that a day of downtime is unacceptable.
A partial mesh. The hub and spoke topology as the base, plus direct links between the specific pairs of sites that talk to each other constantly. It is a targeted fix for hairpinning: you are not meshing the whole network, you are adding the two or three links that carry real data.
Dynamic tunnels between spokes. Technologies built for this, DMVPN being the long standing example, keep the hub and spoke control plane and build a direct tunnel between two spokes on demand when communication between them begins. The routing still goes through the hub, and the data does not.
SD-WAN, which is where most WAN design ended up. It keeps a central control point for policy and chooses the network path per application, so a voice call between two spokes can go direct while everything else goes to the hub.
It is a hub and spoke topology for management and a partial mesh for traffic, which is the arrangement people were building by hand anyway.
ChoosingChoosing, in one page
The decision has three inputs and they are all measurable.
How much traffic goes between spokes rather than to the hub? If the answer is almost none, which is common when the applications and other resources live in a data center or a cloud region, the topology costs nothing and hairpinning is a theoretical concern.
How latency sensitive is that traffic? Voice communication between spokes is the case that forces the issue. File transfers rarely do.
What is a day without the hub worth? If the answer is a serious number, the second hub is the change to make, and it matters more than anything about hairpinning.
Most small businesses answer: almost no branch to branch traffic, not latency sensitive, and a day of downtime would be painful but survivable. That combination says one hub, one well chosen site, with two internet connections and a plan for the day it burns down.
PitfallsWhere people go wrong
Meshing three sites because a mesh topology sounds better. At three sites the link counts are identical, so it is a real choice. At ten it is not, and the instinct that meshing is more resilient stops being affordable long before it stops being appealing.
Treating two internet connections at the hub as removing the single point of failure. They remove one failure mode. The site, the power, the firewall and the router are all still single.
Ignoring hairpinning until somebody complains about a phone call. It is predictable from the network diagram, and the fix is easier to plan than to retrofit.
Putting the hub where the office is rather than where the traffic goes. If the applications are in a cloud region, the hub belongs somewhere with a good path to it, not in whichever office has the most staff.
Assuming SD-WAN removes the design question. It automates the path selection and the underlying WAN topology decisions are the same ones, made once in a policy rather than repeatedly in a routing table.
Forgetting the hub carries the internet traffic of every spoke too. Centralized internet access means the hub circuit sizing is the sum of every site on the network, and that is a number worth calculating before the first complaint.
In the cloudHub and spoke in the cloud
The same model runs inside a cloud account, and that is where most businesses meet it now. A hub virtual network holds the shared services every workload needs: the firewall, the VPN gateway, DNS, jump hosts. Each application sits in its own spoke network, peered to the hub and to nothing else.
Multiple spokes share those central resources rather than each network running its own firewall and its own gateway. The arithmetic is identical to the WAN case and the security argument is stronger, because one place enforces policy for every workload and a spoke can be deleted without touching the rest.
Microsoft's virtual network peering overview says Azure Virtual Network Manager can connect up to 1,000 spoke virtual networks to one hub.
Hairpinning survives the move. Peering connects two networks, so two spokes peered to the same hub do not reach each other through it on their own. Microsoft calls the fix service chaining: user defined routes in each spoke send traffic to a virtual appliance in the hub.
The hub is also the single point of connectivity to everything outside. On premises networks reach the cloud through the hub, over a VPN or a dedicated circuit, and multiple spokes share that one path.
Two more properties of the cloud model are worth knowing. Gateway transit lets a spoke use the VPN or ExpressRoute gateway in the hub rather than run its own. AWS describes its Transit Gateway as a network transit hub that interconnects VPCs and on premises networks.
What does not change is the failure question. The hub network carries the internet traffic of every spoke and every inspection rule, so the availability of that shared infrastructure is the availability of the whole environment. That is a cloud security architecture decision as much as a networking one.
ComparisonThree topologies, and the two rows that pull against each other
| Criterion | Hub and spoke | Partial mesh | Full mesh |
|---|---|---|---|
| Links for 10 sites | 10 | Around 15 | 45 |
| Branch to branch latency | Doubled via the hub | Direct where it matters | Direct |
| Single point of failure | Yes, the hub | Reduced | None |
| Configuration to maintain | One place | Two places | Every site |
| Cost of adding a site | One link | One or two links | Nine links |
| Where policy is enforced | The hub | Mostly the hub | Everywhere |
| Right for most small businesses | Yes | When voice hurts | Almost never |
The first and third rows are the whole trade, and they pull in opposite directions. Everything in the middle column exists because that trade is uncomfortable at exactly the size most businesses are.
FAQFrequently asked questions
What is a hub and spoke topology?
A WAN topology where every site connects to one central site and to nothing else. Traffic between two spokes travels to the hub and back out again.
What are the advantages of a hub and spoke topology?
The link count is n rather than n(n-1)/2, so ten sites need ten links instead of forty five. Policy and security live in one place rather than ten, and adding a spoke is a single link.
What is hairpinning?
Traffic between two branches traveling to the hub and back rather than going direct. It doubles the distance, and it is the main cost of the topology.
Is the hub a single point of failure?
Yes, and for the whole network rather than one site. Two internet connections at the hub do not fix it, because the site, the power and the firewall are still single.
How do I remove the single point of failure?
A second hub at a different site, with every branch connected to both. The link count doubles to 2n, which is still far below a mesh.
When should I use a full mesh topology?
Rarely, and mainly at three or four sites where the link counts are similar anyway. Beyond that the cost and the configuration grow faster than the benefit.
What is a partial mesh topology?
Hub and spoke plus direct links between the specific pairs of sites that communicate constantly. It fixes hairpinning where it hurts without meshing the whole network.
Does SD-WAN replace hub and spoke?
It automates the choice rather than replacing the topology. Policy stays central and traffic takes a direct path per application, which is a partial mesh chosen automatically.
Where should the hub be?
Wherever the traffic is going, which is increasingly a cloud region rather than the largest office. Putting it in the biggest office is a habit rather than a design.
How do I size the hub connection?
For the sum of every branch, if internet access is centralized there. That number surprises people, and it is calculable before anybody complains.
Does hub and spoke apply to VPN tunnels too?
Yes, and it is where most people meet it. Each branch builds an IPsec tunnel to headquarters, and branch to branch traffic crosses two tunnels.
Why does a call between two branches sound bad?
Because it went to the hub and back, doubling the latency, and voice is the traffic least tolerant of that. It is the usual reason a partial mesh gets built.
Is this the same as a star topology?
Essentially, at a different scale. A star topology usually describes nodes around a switch, and hub and spoke describes WAN sites around a central site, but the shape and the trade are the same.
How does hub and spoke compare with other network topology choices?
Among network topology options, hub and spoke is the cheapest to build and the simplest to secure, because every site connects only to the center. A full mesh removes the hub as a bottleneck and single point of failure at a much higher cost. Most wide area networks end up as a partial mesh between the two.
Keep readingRelated concepts
Read next · Remote access What Is an IPsec VPN? Most people meet this shape as tunnels: every branch builds one to headquarters, and branch to branch crosses two. Open this next11 min- Routing · 12 min OSPF Explained A routing protocol over the spokes is what makes a second hub useful, because the failover has to be automatic.
- Diagnostics · 11 min Packet Loss vs Latency, and Why They Feel the Same to Users Hairpinning is a latency cost rather than a bandwidth one, and those are different investigations.
- Design · 11 min Ring Topology, and the Networks Where It Never Went Away The shape that won where this one lost.
- Design · 9 min Hybrid Topology, and Why You Already Have One What the wide area layer costs.
- Design · 9 min Mesh Topology, and the Three Places It Actually Exists What the alternative costs.
- Infrastructure · 12 min What Dark Fiber Is, and Why It Is Not Bandwidth The question to ask instead.
- Infrastructure · 8 min Cisco SD-WAN, and Why the Controller Never Touches Your Traffic Cisco SD-WAN, where a hub and spoke network is a policy on the Controller rather than a cabling plan.