1. 课程导入与容量规划全景
园区网络从建成那一刻起，就进入了持续变化的状态：新员工入职、部门拆分合并、无线终端翻倍、视频会议与云桌面普及、访客接入与物联网设备接入……这些变化最终都会转化为对交换机端口数量、转发带宽、MAC 地址表项、ARP 表项、路由表项、ACL 资源、DHCP 地址池、PoE 功率以及无线 AP 承载能力的持续消耗。容量规划要回答的核心问题不是"网络现在通不通"，而是"在可预期的业务增长下，网络还能撑多久、先在哪里撑不住、需要提前做什么"。
本节作为课程导入，先建立一张全景图：容量规划的目标、范围、交付物是什么，以及 H3C Comware 平台在其中扮演什么角色。后续章节会围绕这张全景图逐层展开。
一、容量规划的目标：从"能通"到"可预期"
容量规划的目标可以概括为三句话：看得见现状、算得清余量、说得明风险。
- 看得见现状：把园区网中关键资源的已用量、峰值用量、增长趋势量化出来，而不是凭"感觉还够用"判断。
- 算得清余量：明确每类资源的可用上限、当前余量、按当前增速的耗尽时间点（例如"接入层某楼层交换机的 PoE 预算剩余 18%，按每月新增 3 台 AP 计算，约 5 个月后耗尽"）。
- 说得明风险：把容量问题转化为可决策的工程语言——是扩容端口、升级上行链路、调整地址规划，还是优化协议参数。
需要强调的是，容量规划不是一次性项目，而是一个"采集—分析—预测—决策—验证"的循环。园区网每年至少应做一次完整评估，在业务大变更（新园区启用、核心设备替换、无线大规模改造）前必须做专项评估。
二、容量规划的范围：哪些资源需要纳入
园区网络容量不是单一指标，而是一组相互关联的资源集合。按层次划分，通常包括以下维度：
| 层次 | 典型容量对象 | 常见瓶颈表现 |
|---|---|---|
| 接入层 | 端口数量、PoE 总功率与单口功率、MAC 表项、端口安全表项 | 端口用尽、PoE 超预算导致 AP 无法上电、MAC 表溢出 |
| 汇聚层 | 上行带宽收敛比、VLAN 数量、ARP 表项、ACL 资源 | 上行拥塞、ARP 表满导致新终端无法上线 |
| 核心层 | 交换容量、路由表项、FIB 表项、VRRP/IRF 资源 | 路由震荡、转发表项不足、主控 CPU 偏高 |
| 出口/边界 | NAT 会话数、带宽利用率、并发连接数、安全策略条目 | NAT 端口耗尽、出口带宽跑满、策略无法下发 |
| 无线 | AP 数量、单 AP 并发终端数、AC 授权数、射频信道容量 | 高密场景体验下降、AC 授权不足 |
| 地址与服务 | IP 地址池、DHCP 租约、DNS/DHCP 服务器承载 | 地址池耗尽、租约冲突 |
范围界定的原则是：凡是"有上限、会被消耗、消耗后影响业务"的资源，都应纳入容量清单。范围过窄会漏掉真实瓶颈，范围过宽则会淹没重点。建议以"业务体验受影响"为筛选标准，优先纳入直接决定终端能否上线、能否稳定通信的资源。
三、交付物：容量规划最终产出什么
容量规划的成果不是一份"网络现状说明"，而是能支撑决策的工程文档。典型交付物包括：
- 容量基线表：逐设备、逐资源记录型号、规格上限、当前用量、峰值用量、余量百分比。
- 增长趋势与预测：基于历史数据给出增长率，推算关键资源的耗尽时间点。
- 瓶颈清单与优先级：按"影响范围 × 紧迫程度"排序，区分立即处理、本季度处理、纳入年度预算。
- 扩容方案与验证方法：明确扩容对象、目标值、实施方式，以及扩容后用什么指标验证是否达标。
四、H3C Comware 在容量与扩容工程中的角色
H3C Comware 是园区网设备的统一软件平台，它既是容量的"承载者"，也是容量数据的"提供者"和扩容操作的"执行者"。理解这一点，才能把容量规划落到具体设备上。
- 承载者：Comware 通过硬件规格（表项容量、PoE 预算、交换容量）和软件特性（IRF、VRRP、M-LAG、ACL、QoS）决定设备实际能承载多少业务。
- 提供者：Comware 提供
display系列命令，用于读取端口状态、MAC/ARP 表项、PoE 功率、CPU/内存、接口流量等容量相关数据，是容量基线采集的主要来源。 - 执行者：扩容动作最终通过 Comware 配置实现，例如新增 VLAN、调整聚合链路、修改 PoE 优先级、扩展 IRF 成员、调整 DHCP 地址池等。
因此，容量规划不能脱离 Comware 的具体命令与规格。例如，判断一台接入交换机是否还能加 AP，需要同时看 display poe interface 的剩余功率和 display mac-address 的表项占用；判断汇聚上行是否吃紧，需要看 display interface 的峰值速率与收敛比设计值。这些命令与判读方法将在后续章节逐一展开。
五、一个简化的容量评估示例
为了让"全景"落到可操作层面，给出一个简化示例（数据为教学假设，非实测）。某楼层接入交换机 S5130 系列，48 个 10/100/1000BASE-T 端口，PoE 总预算 370W。当前已用端口 36 个，其中 12 个端口接 AP，单 AP 功耗约 12.5W，PoE 已用约 150W。
# 采集 PoE 使用情况（示例）
display poe interface
# 输出关注：各端口 Power(mW)、Total Power Consumption、Remaining Power
# 采集 MAC 表项占用（示例）
display mac-address | count
# 关注：当前表项数与设备规格上限的比值
# 采集上行端口峰值速率（示例）
display interface GigabitEthernet1/0/49
# 关注：Last 300 seconds input/output rate 与端口带宽的比值按当前数据推算：PoE 剩余约 220W，若每新增一台 AP 按 12.5W 计，理论上还可加约 17 台；但端口只剩 12 个空闲，因此端口先于 PoE 成为瓶颈。若业务预测未来 6 个月新增 20 台 AP，则结论是：需要新增接入交换机或改用更高密度型号，而不是只关注 PoE 功率。这个例子说明，容量判断必须多资源联合看，单一指标容易得出错误结论。