Sizing a large hub-and-spoke VPN: count before you choose BGP
Prefixes are the easy number. Sessions, update churn and recovery after a hub failure decide whether the design holds at a few thousand branches.
Three thousand branches sounds like a routing problem and behaves like a bookkeeping problem. The prefix total takes ten minutes to work out, and it is rarely the number that hurts. What hurts is the per-session work, the update burst when a shared component fails, and the time it takes before forwarding matches the new topology again.
So walk the arithmetic in the right order. Count the relationships, count the prefixes and the alternatives, then count what happens in a bad hour, and only after that compare protocols and platforms. Done in the other order, the exercise turns into an argument about route limits that nobody can settle with the information on the table.
Four budgets, not one
Each budget answers a different question, and each one can be the binding constraint on a different platform. Writing them separately stops a single big prefix number from standing in for the whole design.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
The last two are the ones that get skipped in a design review. A network that sits comfortably inside memory at steady state can still behave badly when four hundred branches reconnect within two minutes, because the work arrives faster than the control plane drains it. Write the burst size down as a number, along with how long the service may stay degraded. That turns a vague worry into a test somebody can actually run.
There is also a platform question hiding inside all four: whether encryption, forwarding and routing share a CPU or have separate paths. Two devices with identical route capacity can behave very differently under churn, and the datasheet rarely says which one you are buying.
Do the arithmetic for your own numbers
Take a made-up design: 3,000 branches, three prefixes each before aggregation, and two hubs per branch for redundancy. The hub pair has to hold roughly 9,000 branch prefixes before summarization, and the design implies 6,000 branch-to-hub sessions if every branch peers with both.
Now add the parts that are not prefixes. Each session carries state and periodic messages even when nothing changes. Each hub may hold more than one path per prefix if it is expected to fail over quickly, so the alternative count can exceed the selected count. And each spoke's view is a separate policy decision: giving every branch every other branch's routes multiplies the work in a way the hub-side count does not reveal.
Those are planning figures for a design conversation, not a measurement of any product. The useful output of the exercise is the shape of the curve, not a claim about where a specific router gives out.
What BGP buys you, and what an IGP buys you
BGP separates what a router received, what it selected and what it advertises, and each of those is policy-controlled. That is exactly what a branch network needs, because a spoke should usually see a default, the central services, and very little else. Counting only the final table hides the alternatives and the advertisements, which are the parts that grow when you add redundancy.
An IGP is not automatically wrong. When the topology, area structure and adjacency model fit the service, a link-state protocol converges quickly and needs less policy scaffolding. The trap is assuming it can express the same per-neighbor export control as BGP: an OSPF area is a flooding boundary, not a filter you can attach to one branch.
Either way, decide the visibility model first. Defaults, summaries for central services, or full branch specifics are three different products, and a summary that hides a more specific failure is a design decision that has to be written down rather than discovered during an outage.
Test the burst, not the steady state
Build the comparison around the failure you actually expect: a hub down, a regional WAN event, or a maintenance window that takes half the sites offline at once. Time the recovery from the branch's perspective, including the application, because a control plane that converges in seconds means little if the session takes minutes to re-establish.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFRecord what the platform does at the burst peak rather than at rest, and repeat it with the security features enabled. A proof of concept that only shows a quiet table is a memory test, and memory was never the interesting number.