园区核心设计：机箱依赖、容量与弹性

园区核心是众多接入区块共享的服务依赖。其设计应说明路由发生在何处、哪些故障仍为局部故障，以及平台在维护期间的行为。端口数量只是该决策的一部分。

本方案涵盖园区更新或扩展中的汇聚与核心规划。仅当完整机箱配置已确定后，才适用于模块化系统；线卡报价单不是核心网络设计。

选择架构边界

将楼宇或接入区块映射到其汇聚点。确定二层是否在它们之间延伸、用户网关部署在何处，以及哪些服务需要跨园区可达性。优先选择一种故障行为无需追踪每个接入端口穿越整个园区即可解释的设计。

固定平台对和模块化机箱可能都满足需求。比较所需端口、独立故障域、扩展方式和运维技能。当支持的扩展路径适合项目时，模块化才有用；它本身并不是选择更大共享机箱的理由。

构建完整的系统层级

对于模块化设计，列出机箱、主控引擎、线卡、适用的交换网组件、电源、风扇、软件和许可证。验证组合，而非孤立检查每个组件。Cisco 历史 Catalyst 6500/6800 架构资料说明了为何主控引擎和线卡依赖关系是系统定义的一部分。R26

保持该旧平台范围明确。它不能替代其他当前 Catalyst 系列的文档，也不构成对任意混合代际配置的支持。

在相关边界计算容量

按接入区块汇总所需上联，然后检查槽位带宽、转发行为和所选互连设计。不要将单向接口容量与厂商的双向交换容量数字混为一谈。

作为说明性故障状态计算，六个接入区块具有 8 Gb/s 的并发上行需求，在预留前需要 48 Gb/s。具有两条活动 40G 路径的设计正常情况下标称总容量为 80 Gb/s，但丢失一条后仅为 40 Gb/s。在该故障下，若不减少负载或更改设计，它无法维持假设的满需求。

该计算有意基于假设需求，而非端点链路速率之和。在替换假设时，记录真实需求数据的来源和测量间隔。

设计维护以及故障恢复

事件	待解决的问题
上联丢失	哪些流量转移，剩余容量是否足够？
主控引擎或设备丢失	哪些控制和转发功能仍可用？
软件维护	哪些服务中断，如何执行回滚？
电源域丢失	哪些硬件仍通电，而不仅仅是配备了两个电源？

冗余硬件并不证明服务无中断。使用受支持的平台行为和可测试的应用需求。

一次迁移一个服务边界

在移动网关或上联之前，在新平台上建立管理、路由和监控。转换配置意图，而非跨操作系统复制语法。保持旧路径可用，直到寻址、路由、策略和应用测试通过。

交接应包括带故障域的拓扑、包含实际配置的机箱物料清单、正常/降级容量工作表以及变更序列。园区设计指南可以框定架构，但项目自身的验收测试确定其需求是否已满足。R45

配套工程示意图

以下配图用于说明本篇设计思路，图中英文术语可结合文末释义阅读；不代表实测结果、认证配置或随货清单。