大型星型 VPN 的容量规划：先数清楚，再选 BGP

三千个分支机构听起来像路由问题，实际却表现为一本账的问题。前缀总量十分钟就能算出来，而它很少是真正让人难受的数字。真正难受的是每个会话的维护工作、共享组件失效时的更新风暴，以及转发要花多久才能重新匹配新拓扑。

所以要按正确的顺序过一遍这笔账。先数关系，再数前缀和备选路径，然后数糟糕的一小时里会发生什么，最后才比较协议和平台。顺序反过来，这件事就会变成一场关于路由上限的争论，而凭桌上的信息谁也无法定论。

四本账，不是一本

每本账回答不同的问题，每一本都可能在不同平台上成为瓶颈。分开写，可以避免一个大前缀数替代整个设计。

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

后两本往往是设计评审时被跳过的。稳态下内存还很宽裕的网络，在四百个分支机构两分钟内同时重连时，仍可能表现很差，因为工作抵达的速度快于控制面处理的速度。把风暴规模写成一个数字，连同服务可以降级多久一起写下来。这就把模糊的担忧变成了别人真能跑起来的测试。

四本账里还藏着一个平台问题：加密、转发和路由是共享同一个 CPU，还是各有独立路径。两台路由容量相同的设备在风暴下的表现可能天差地别，而数据手册很少说明你买的是哪一种。

假设一个设计：3,000 个分支机构，聚合前每处三个前缀，每个分支机构配两个枢纽做冗余。枢纽对在汇总前要容纳大约 9,000 条分支前缀；如果每个分支机构同时与两个枢纽对等，设计就意味着 6,000 条分支到枢纽的会话。

现在加上不是前缀的部分。即使什么都不变，每个会话也要维护状态并收发周期报文。如果期望快速切换，每个枢纽可能对每条前缀保留不止一条路径，因此备选数量会超过选中数量。而每个分支的可见范围是独立的策略决定：让每个分支机构都看到其他所有分支的路由，会让工作量成倍增加，而枢纽侧的计数根本反映不出来。

这些是用于设计讨论的规划数字，不是对任何产品的测量。这件事有用的产出是曲线的形状，而不是断言某台具体路由器会在哪里崩溃。

BGP 把路由器收到的、选中的和宣告的分开，每一项都受策略控制。这正是分支网络需要的，因为分支通常只应看到默认路由、中心服务，别的越少越好。只数最终表，就会隐藏备选和宣告，而增加冗余时增长的恰恰是这些部分。

IGP 并非天然错误。当拓扑、区域结构和邻接模型与服务相匹配时，链路状态协议收敛快，需要的策略脚手架也少。陷阱在于认为它能表达和 BGP 相同的逐邻居导出控制：OSPF 区域是泛洪边界，不是可以挂到某个分支上的过滤器。

无论如何，先决定可见性模型。默认路由、面向中心服务的汇总，或完整的分支明细，是三种不同的产品；而一个掩盖了更具体故障的汇总，是必须写下来的设计决定，不能等故障发生时才去发现。

围绕你真正预期的故障来搭建对比：一个枢纽宕机、一次区域 WAN 事件，或一个让半数站点同时离线的维护窗口。要从分支的视角计时恢复，包括应用在内，因为控制面几秒收敛，如果会话要几分钟才能重建，意义也不大。

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

记录平台在风暴峰值时的表现，而不是空闲时，并在开启安全功能后重复一遍。只展示一张安静表的概念验证只是内存测试，而内存从来都不是那个有趣的数字。