1. 企业QoS需求分析
在企业网络中，QoS不是“把带宽分一分”这么简单。它的本质是：当链路出现拥塞、突发或故障收敛时，网络设备依据业务的重要程度和时延敏感度，对不同类型的流量做出差异化处理。要做对QoS，第一步不是敲配置，而是把业务需求翻译成可量化的SLA，再把SLA映射为园区接入、汇聚、核心以及广域网出口各位置的策略目标。
一、四类典型流量的SLA差异
企业园区与广域网出口上，通常把流量归为四类：语音、视频、关键业务与尽力而为。它们的SLA差异体现在时延、抖动、丢包、带宽保障和突发容忍度上。
| 流量类型 | 典型应用 | 单向时延目标 | 抖动目标 | 丢包目标 | 带宽特征 |
|---|---|---|---|---|---|
| 语音 | IP电话、呼叫中心、VoIP中继 | ≤150 ms | ≤30 ms | ≤1% | 小包、恒定速率、约80–100 kbps/路 |
| 视频 | 视频会议、监控回传、直播 | ≤200 ms（交互式） | ≤50 ms | ≤0.1%–1% | 可变码率、突发明显 |
| 关键业务 | ERP、数据库、OA、生产系统 | ≤500 ms | 不敏感 | ≤0.1%（重传敏感） | 突发、事务型 |
| 尽力而为 | 网页、邮件、软件更新、备份 | 无硬性要求 | 不敏感 | 可容忍 | 可被压缩、可被限速 |
这些数值是行业通用参考，不是绝对标准。实际项目中应以业务部门确认的SLA为准。例如呼叫中心可能要求语音单向时延≤100 ms，而普通办公电话可放宽到150 ms。关键业务中，数据库同步对丢包极敏感，而文件下载对时延不敏感但占用带宽大，二者不能简单归为一类。
二、园区与广域网出口的QoS目标差异
园区内部与广域网出口的QoS目标并不相同。园区接入层到核心层通常是高带宽、低拥塞环境，QoS重点在于分类与标记，把语音、视频、关键业务在边缘就识别出来，并打上统一的DSCP值，供后续设备信任和调度。园区汇聚与核心链路一般以10G/40G为主，拥塞概率低，因此更多采用信任边界+队列调度，而不是大规模限速。
广域网出口则完全不同。出口链路带宽通常远小于园区内部，且承载分支互联、互联网访问、云应用等多种流量，拥塞是常态。因此广域网出口的QoS目标更强调：拥塞管理（队列调度）、拥塞避免（WRED）、流量整形（Shaping）与限速（Policing）。语音和视频需要低时延队列（LLQ），关键业务需要带宽保障，尽力而为流量在拥塞时被丢弃或降级。
三、从SLA到DSCP：需求翻译过程
把业务SLA翻译成设备可执行的策略，需要经过“业务分类→DSCP标记→每跳行为（PHB）→队列与阈值”四步。以语音为例：业务SLA要求时延≤150 ms、抖动≤30 ms、丢包≤1%；对应DSCP EF（46），PHB为加速转发，设备上映射到优先队列（Priority Queue），并设置语音带宽上限（如总带宽的33%），防止语音队列被滥用。
视频会议通常标记为AF41（34），PHB为保证转发，映射到带宽保障队列，并配合WRED在拥塞时优先丢弃低优先级视频包。关键业务标记为AF31（26）或AF21（18），获得最小带宽保障。尽力而为流量标记为DSCP 0（BE），使用默认队列，拥塞时被优先丢弃。
业务SLA → 分类（ACL/NBAR/端口信任） → DSCP标记 → PHB → 队列/阈值/整形
语音：EF(46) → 优先队列，带宽≤33%，LLQ
视频：AF41(34) → 带宽保障队列，WRED
关键业务：AF31(26) → 带宽保障队列，最小带宽
尽力而为：BE(0) → 默认队列，拥塞丢弃四、Catalyst QoS策略目标梳理
在Catalyst园区中，QoS策略目标可以按位置划分：
- 接入层：信任IP电话和摄像头的DSCP标记，对PC和无线用户进行流量分类与标记，建立信任边界。
- 汇聚层：执行队列调度，为语音、视频、关键业务提供带宽保障，配置WRED避免全局同步。
- 核心层：保持DSCP透明传输，通常不做复杂调度，仅在高拥塞时启用简单队列。
- 广域网出口：执行整形（Shaping）以匹配运营商速率，配置LLQ保障语音，WRED保障关键业务，对尽力而为流量限速。
这些目标最终要落到具体接口和方向。例如，园区接入交换机上联口出方向配置队列调度；广域网路由器出口配置整形与LLQ；运营商链路入口方向配置监管（Policing）防止超速流量影响其他业务。
五、需求分析中的常见误区
第一个误区是把所有业务都标记为高优先级。如果语音、视频、关键业务都进入优先队列，优先队列本身就会拥塞，QoS等于失效。正确做法是：优先队列只放语音，视频和关键业务使用带宽保障队列，并设置上限。
第二个误区是只在广域网出口做QoS，园区内部不标记。这样出口设备无法识别流量类型，只能按端口或ACL粗略分类，效果差且维护复杂。正确做法是在接入层就完成分类和标记，出口设备信任DSCP并执行调度。
第三个误区是忽略反向流量。语音和视频是双向的，如果只在上行方向配置QoS，下行方向仍可能拥塞。因此需要在接口两个方向都检查策略，尤其是广域网出口的入方向监管和出方向整形。
六、需求分析交付物示例
完成需求分析后，应形成一份可执行的QoS需求表，作为后续配置的依据。示例字段如下：
| 业务 | DSCP | PHB | 带宽保障 | 队列类型 | 拥塞处理 |
|---|---|---|---|---|---|
| 语音 | EF(46) | 加速转发 | ≤33% | LLQ优先队列 | 优先调度，超限丢弃 |
| 视频会议 | AF41(34) | 保证转发 | ≥20% | 带宽保障队列 | WRED |
| 关键业务 | AF31(26) | 保证转发 | ≥25% | 带宽保障队列 | WRED |
| 尽力而为 | BE(0) | 默认转发 | 剩余带宽 | 默认队列 | 尾丢弃/WRED |
这张表不是最终配置，而是需求与策略之间的桥梁。它明确了每类业务的标记值、队列行为和拥塞处理方式，后续在Catalyst交换机上配置class-map、policy-map和service-policy时，直接按表落地即可。实际项目中，还应补充接口方向、信任边界位置、整形速率等参数，形成完整的QoS设计文档。
总结来说，企业QoS需求分析的核心是：先识别业务SLA差异，再确定园区与广域网出口的策略目标，最后把目标翻译成DSCP、PHB和队列参数。只有这一步做扎实，后续的Catalyst QoS配置才有依据，业务保障才不会变成“凭感觉调优先级”。