摘要
- 原帖询问的是一个约 300 台路由器的扁平 IS-IS L2 域，以及汇聚设备维持约 100 个下行邻接是否可行。
- Saku Ytti 提到曾在更老的控制平面上运行数千节点的 IS-IS；Mark Tinka 则说其网络在 2009 年已达到约 300 个节点。
- Tom Beecher 认为这一规模通常可行，但需要看地理跨度、链路状态数据库大小和 SPF 延迟设置；Dan Snyder 又加入硬件、故障域大小和收敛目标三项条件。
- Matthew Petach 的新回复把问题改写为：网络需要为自动化缺陷、人工输入错误、设备故障和光纤中断预先设定影响半径与隔离边界。
- IETF 文档说明，IS-IS 分层可以限制 LSP 泛洪和 SPF 计算范围，但抽象拓扑也可能牺牲路径最优性。
- 因此，300 节点方案下一步应提交故障预算和降级流量测试，而不是继续寻找更大的节点数量纪录。
原帖希望得到生产经验，而不是厂商建议。提问者设想一个约 300 台路由器的扁平 IS-IS Level 2 网络，其中部分汇聚路由器可能维护大约 100 个下行邻接，并询问这是否已接近实际边界。
回复很快把“300”从边界变成普通规模。Saku Ytti 说，他曾在二十年前更慢的控制平面上运行数千节点的 IS-IS 网络。Mark Tinka 列举了 2009 年使用 Cisco CRS-1、ME3600X 以及 Juniper M320、T320、MX480 的约 300 节点部署。Tom Beecher 也认为，单个扁平 L2 区域达到这一规模通常不会成为问题。
这些都是个人运营经验，不是厂商基准测试。提问者没有公开拓扑、硬件组合、链路数量、LSDB 规模、端到端时延或收敛目标，所以讨论无法给出通用上限。不过，它已经足以排除一个误区：是否继续扁平化，不能只由节点总数决定。
“能跑”之后才进入架构判断
Beecher 的肯定带有两个限定。网络的地理跨度会影响 SPF 延迟选择，LSDB 总量也会改变控制平面负荷。更关键的是，他指出如果数据库规模已成为核心忧虑，那么真正该复核的也许不是如何继续调优，而是网络是否仍应保持一个扁平区域。
Dan Snyder 把条件压缩成硬件、可接受的故障域和所需收敛时间。三者解决的是不同问题。更快的处理器可以更快完成计算，却不会自动缩小错误配置的传播范围。协议完成收敛，也不代表剩余链路有足够容量承接迁移流量。
随后被索引的 Matthew Petach 回复构成了本轮的新事件。他建议先列出高概率故障：自动化工具缺陷、自动化输入中的人为错误、L1/L2/L3 设备故障以及光纤中断；再为每类故障决定“爆炸半径”以及需要设置“防爆门”的位置。
这里的“防爆门”是设计隐喻，不等于无条件增加 IS-IS 区域。它要求运营者回答两个问题：一次局部错误最多应让多少设备和业务重新计算；当最短路径把流量导向一个运营者不愿继续使用的方向时，系统在哪里保留更高层的控制点。
修复周期会改变同一条链路的风险权重
机房内一只故障光模块和一条长距离光缆中断，都可能触发路由变化，但业务含义完全不同。前者可能在数分钟或数小时内更换；后者的受限状态可能持续到容量规划、优先级和客户承诺都必须介入。
Petach 用跨洋链路说明这一差别。额外的海缆路径昂贵，看似独立的线路可能存在共享命运，一次区域性破坏可能同时减少多条容量。此时，IS-IS 可以正确找到仍然可达的路径，却把过多流量压到少数幸存链路上。那是收敛之后的容量分配问题，而不是协议有没有收敛的问题。
讨论没有报告真实事故，也没有披露任何具体海缆的测量数据。因此，文章不能把举例写成某条线路的事实。可验证的运营结论是：每个故障场景都要把需求矩阵施加到剩余拓扑上，观察哪些链路饱和、哪些业务需要保护，以及人工或自动流量工程从哪里介入。
分层缩小状态范围，也会损失信息
RFC 5302 描述了由多个 Level 1 区域和一个 Level 2 互联拓扑组成的 IS-IS 域。在区域内限制 LSP 传播，可以控制链路状态数据库规模，并缩小最短路径计算所处理的拓扑范围。
同一份 RFC 也明确说明代价。汇总与抽象会丢失细节，可能导致路径不再最优；把更多精细前缀分发到整个域，则会增加内存、传输和计算负担。分层不是免费的“稳定性开关”，而是可扩展性、信息粒度与路径选择之间的取舍。
RFC 9377 把处理和泛洪开销视为单一 IS-IS 泛洪域的最终限制，并将多个 L1 泛洪域加一个 L2 骨干列为常规扩展方式。RFC 8405 则要求同一区域或层级内的 SPF 退避参数保持一致，并提醒适当参数会随网络生命周期而变化。
这些标准既没有给出 300 节点红线，也没有证明扁平设计可以无限延伸。它们要求测量：节点与链路数量、LSDB 增长、LSP 变化率、泛洪时间、SPF 行为，以及每种故障后的剩余容量。
设计评审至少需要四组证据
第一组是控制平面余量。测试要使用生产中最慢的一代设备，记录拓扑变化期间的 CPU、内存、邻接建立时间、LSP 传播时间以及完整和增量 SPF 的表现，不能只在最新路由器上跑一次。
第二组是故障隔离。评审应覆盖自动化配置错误、路由策略误投、单设备丢失、单站点丢失以及具有共享命运的多条长途链路同时中断。每个场景都要写清重算范围、受影响业务、责任团队和必须保持不受影响的部分。
第三组是降级容量。路由表一致并不是通过标准。如果幸存链路过载，方案必须说明在哪里进行流量工程、服务优先级或准入控制。没有控制点，就等于让拥塞替运营者做选择。
第四组是未来可运营性。Petach 要求看三年、五年和十年。增长不仅包括更多节点，还包括新地理区域、不同硬件代际、更大的维护域，以及事故期间真正能够理解并安全操作整张拓扑的工程师数量。
下一份材料应是故障预算
如果网络地域紧凑、真实物理路径充足且冗余容量充裕，继续保持扁平结构可能完全合理。若网络跨越多个区域、关键长途容量集中、修复缓慢或服务承诺严格，隔离边界就可能早于控制平面极限出现。
NANOG 讨论把原本混在一起的两个批准动作分开了。第一个批准说明协议和硬件能够保存并计算 300 节点的状态。第二个批准说明机构接受这种拓扑的故障半径，并能在降级状态下控制流量。
所以，300 节点方案最需要的下一项数据不是“别人跑过 3000 台”。它应是一份故障预算：要承受哪些事件，每次事件最多影响多大范围和多久，剩余容量是多少，以及最短路径不足以满足业务目标时，运营者从哪里接管。