板块7 · QoS 与优先级工程
板块7 · QoS 与优先级工程
目标与定位：QoS（Quality of Service，服务质量）是 ZCIE 大纲明确考点，也是把“网络能通”升级为“网络好用”的关键技术。本板块覆盖分类、标记、监管、队列调度、拥塞避免、限速和端到端设计，目标是让学习者在 ZCIP 能配置验证、在 ZCIE 能按业务诉求解释并优化方案。
第一性原理：QoS 不能创造带宽，只能在带宽有限时决定“谁先用、谁先丢”。因此，QoS 的本质是资源排序与损失分配，不是凭空提高链路容量；所有设计都要先找到拥塞点，再决定分类、映射、调度和限速策略。
适用范围：以中兴数通设备的 DiffServ 实现为主要讨论对象，命令以体系A
zte(cfg)#为主线；体系B 给出配置形态提示，但不假设固定语法。不同版本、不同板卡能力存在差异时，一律以设备?帮助、当前配置和运行输出为准。
7_1 QoS 基础模型
本节要解决什么问题：先纠正一个期待：QoS 不能创造带宽。它解决的是带宽有限时「谁先用、谁先丢」。
7_1_1 QoS 解决的四大问题
带宽、时延、抖动和丢包构成业务体验的四个基本约束。 它们并不是彼此孤立的指标：带宽不足会诱发拥塞，拥塞会延长排队时延并引入抖动，缓冲区耗尽后则表现为丢包；丢包又会触发 TCP 重传，进一步挤占本已紧张的带宽。QoS 的价值不在于消除这些物理约束，而在于让有限资源向关键业务倾斜。
业务体验四维模型
| 指标 | 典型业务影响 | QoS 可采取的行动 |
|---|---|---|
| 带宽 Bandwidth | 并发业务互相抢带宽、整体吞吐低 | 限速、带宽预留、队列调度、扩容 |
| 时延 Latency | 语音通话不自然、交互操作发滞 | 高优先级队列、减少排队深度 |
| 抖动 Jitter | 语音断续、视频花屏马赛克 | 固定/优先队列、流量整形 |
| 丢包 Loss | 重传、卡顿、连接中断 | 拥塞避免、优先级丢弃、保护倒换 |
两类边界必须先分清：
| 边界类型 | 包含内容 | 工程含义 |
|---|---|---|
| 不可突破的物理边界 | 链路速率、设备交换容量、缓存深度 | QoS 无法凭空创造，只能分配；超出就只能扩容 |
| 可控制的软件边界 | 报文排队顺序、丢弃顺序、是否限速或重标记 | 这才是 QoS 真正发挥作用的地方 |
先看利用率，再谈调度。 如果某条 10GE 链路长期利用率只有 20%，调 SP、WFQ 或优先级映射通常毫无效果；此时业务仍卡顿，应优先排查终端、应用、路径不对称、丢包或设备性能。
QoS 必须建立在可观测的拥塞点上，而不是“全局开关”。 如果某条 10GE 链路长期利用率只有 20%，单纯调整 SP、WFQ 或优先级映射通常无法改善体验；此时如果业务仍卡顿，应优先排查终端、应用、路径不对称、丢包或设备性能。反之，在汇聚上联、出口、跨域互联等瓶颈处，合理调度会直接影响业务排队。
【ZCIP】现场配置前先记录每个关键接口的入向、出向峰值利用率、突发持续时间和丢包计数。若没有拥塞证据，优先把 QoS 设计写成“待验证基线”，不要把所有接口都无差别套用复杂策略。
7_1_2 QoS 四大服务模型
现网主流是 DiffServ，Best-Effort 是缺省背景，IntServ 和 TE 解决更严格的局部或路径级问题。 对园区网、IPTV 承载网和多数运营商城域网而言，逐跳按标记进行汇聚式处理，比逐流端到端预留更具扩展性；但 DiffServ 提供的是相对保障，不能脱离带宽余量和拥塞控制单独成立。
| 模型 | 机制 | 优点 | 缺点 | 现网地位 |
|---|---|---|---|---|
| Best-Effort | 尽力而为，无分类保障 | 简单、无需状态 | 无差别转发 | 默认承载 |
| IntServ（集成服务） | 每流资源预留，常用 RSVP | 可提供较强保证 | 状态多、扩展性差 | 特定场景，现网少用 |
| DiffServ（区分服务） | 分类、标记、PHB、调度 | 可扩展、易部署 | 保障是相对的 | 绝对主流 |
| 流量工程 TE | MPLS TE / SR-TE 等路径优化 | 路径级拥塞控制 | 规划与控制复杂 | 骨干、运营商网络 |
Best-Effort：所有报文“平等”排队，拥塞时谁先到谁先走，不承诺体验。
IntServ ：为单个流建立路径状态并预留资源；像给专车预留道路，但道路管理成本高。
DiffServ ：把业务归为少量类别，按 PHB（Per-Hop Behavior）逐跳处理；像分车道通行。
TE ：从路径选择层面避开拥塞，可与 DiffServ 组合，但不替代逐跳调度。
DiffServ 的核心是“边缘分类、核心转发”。 终端、接入交换机或边界设备先把业务归入有限类别，并写入 802.1p、DSCP 等标记；中间设备根据本地策略映射到队列和调度器。这样做避免了在网络核心维护海量逐流状态，也意味着整网标记、映射和信任边界必须一致，否则同一报文在不同设备上的优先级会“漂移”。
【ZCIE】答辩时不要只说“DiffServ 比 IntServ 好”。更准确的说法是：IntServ 在细粒度逐流保证上有优势，但扩展性差；DiffServ 通过聚合分类和逐跳行为换取部署规模，代价是需要全网规划一致性，且不能严格承诺单流指标。
7_1_3 DiffServ 处理流程
DiffServ 五步流程是一个有顺序的处理管道：分类 → 标记 → 限速/监管 → 队列调度 → 拥塞避免。 五步并不要求每一步都改写报文，但至少要有分类和调度，否则“差异化”无从谈起。标记决定后续设备能否识别，监管决定是否允许超额，调度和拥塞避免共同决定拥塞时的发送与丢弃。
报文进入接口
│
▼
┌──────────────────────────┐
│ 1. 分类 Classification │ 按端口、源/目的 MAC、VLAN、802.1p、
└──────────┬───────────────┘ DSCP、ACL、流表等识别业务
▼
┌──────────────────────────┐
│ 2. 标记 Marking │ 写入/改写 802.1p、DSCP、内部优先级；
└──────────┬───────────────┘ 也可保持原标记
▼
┌──────────────────────────┐
│ 3. 限速/监管 Policing │ 对超额流量丢弃、降级或触发后续处理
└──────────┬───────────────┘
▼
┌──────────────────────────┐
│ 4. 队列调度 Scheduling │ 按 TC/优先级选择发送顺序与带宽比例
└──────────┬───────────────┘
▼
┌──────────────────────────┐
│ 5. 拥塞避免 Avoidance │ 队列满或阈值触发时决定丢弃策略
└──────────┬───────────────┘
▼
报文离开接口
五步之间不是彼此替代关系。 分类错误，后面全部错；标记不一致，跨设备优先级会变化；只有监管没有调度，超额流量被丢弃但不保证关键流先走；只有调度没有合理分类，也可能把大流量放进高优先级队列。真正的工程闭环必须回到业务体验：语音要低时延低丢包，视频要稳定吞吐，备份要被限制但不应饿死，网管必须保持可达。
【踩坑】不能把“配置过 queue-schedule sp”等同于“业务已经得到保障”。若报文没有命中预期分类，或映射没有进入 TC3，调度器仍会按错误优先级处理；若出口根本没拥塞，调度策略也不会表现出差异。
7_2 七级优先级判定链
本节要解决什么问题：报文进入交换机后，可能同时带 802.1p 和 DSCP 两种标记。谁说了算，由七级判定链决定——这是最容易被忽略的坑。
7_2_1 七级优先级判定链
七级优先级判定链决定单台设备给报文“最终采用哪个优先级”，它是覆盖关系而非累加关系。 设备判定的顺序从前到后依次为：CPU 发送的数据包、管理数据包、静态源 MAC 地址优先级、VLAN 优先级、802.1p 用户优先级、三层 DSCP 优先级、端口默认优先级。位于链靠前位置的高优先级命中后，靠后的低优先级不再叠加或覆盖。
优先级判定链（高 ────────────────────────────► 低）
┌──────────────────────────────────────────────┐
│ 1. CPU 发送的数据包 │ 最高
├──────────────────────────────────────────────┤
│ 2. 管理数据包（如 BPDU、协议控制报文） │
├──────────────────────────────────────────────┤
│ 3. 静态源 MAC 地址优先级 │
├──────────────────────────────────────────────┤
│ 4. VLAN 优先级 │
├──────────────────────────────────────────────┤
│ 5. 802.1p 用户优先级 │
├──────────────────────────────────────────────┤
│ 6. 三层 DSCP 优先级 │
├──────────────────────────────────────────────┤
│ 7. 端口默认优先级 │ 最低
└──────────────────────────────────────────────┘
判定规则：
a) 先按 1→7 顺序检查本设备配置/机制是否命中；
b) 命中高优先级来源后，采用该结果，不再把低优先级数值“相加”；
c) 所有显式来源均未命中时，才回落到端口默认优先级。
判定链解释的是“本机如何选择优先级”，不解释全网标记如何传播。 例如一台接入交换机可能根据静态源 MAC 给语音网关赋予高优先级；同一报文离开交换机进入 trunk 时，是否携带 802.1p，还要看 VLAN 处理、信任策略和重标记配置。设计端到端方案时，要把“内部判定结果”与“报文对外标记”分开记录，否则很容易误以为队列正确就代表标记正确。
| 判定层级 | 典型含义 | 设计关注点 |
|---|---|---|
| CPU 发包 | 设备本地生成的控制、管理报文 | 通常优先保障，防止设备失去自管理能力 |
| 管理包 | BPDU、路由协议、OAM 等 | 拥塞时仍需保障协议稳定 |
| 静态源 MAC | 管理员预配置的源 MAC 优先级 | 仅适合可控终端，避免伪造 MAC 滥用 |
| VLAN 优先级 | 与 VLAN/服务实例绑定的优先级 | 注意 VLAN 边界和改写规则 |
| 802.1p | 以太网帧 Tag 中的 CoS 值 | 二层信任边界的核心 |
| DSCP | IP 头中的差分服务代码点 | 三层端到端标记，需确认设备是否信任 |
| 端口默认优先级 | 未命中其他来源时的兜底值 | 不能替代业务级分类 |
7_2_2 默认只开 802.1p 的隐蔽坑
默认仅开启 802.1p 用户优先级，是“配置看起来完整、业务却没得到保障”的头号线索。 这意味着设备默认更容易信任二层 CoS，而不是三层 DSCP。若终端、服务器或上游网络只打 DSCP，而接入设备没有把 DSCP 映射到 TC，也没有在边界重标记，那么即使 queue-schedule 已配置，关键业务也可能落入非预期队列。
默认信任状态（中兴设备场景）
┌─────────────────────────────────────────────┐
│ 802.1p 用户优先级：默认开启（信任/参与判定） │
│ 其他优先级策略：默认未配置/关闭 │
└─────────────────────────────────────────────┘
│
▼
服务器仅打 DSCP=46
│
▼
若未配置 DSCP→TC 映射，也未重标记 802.1p
│
▼
DSCP 在优先级判定链中可能不被采用 → 落入默认/普通队列
│
▼
语音卡顿、IPTV 花屏，但 ping 与 TCP 下载看似正常
【踩坑】不要把“报文带 DSCP”自动理解成“交换机已经信任 DSCP”。DSCP 是 IP 头字段，802.1p 是 Ethernet Tag 字段，二者必须分别确认映射；即使在三层接口上，也要确认设备是否按 DSCP 映射至内部优先级和出口队列。
判定链与映射表是两个不同控制面。 判定链回答“这个报文的最终优先级从哪来”，priority-map 回答“某个优先级最终进入哪个 Traffic Class”。调试时推荐顺序：先看报文实际标记，再看接口是否信任该标记，接着看判定链中是否有更高层来源覆盖，最后看 user-priority/ip-priority 到 TC 的映射。
7_2_3 端口默认优先级的边界
端口默认优先级是“无标记、无更高层命中”时的最后兜底，不是业务分类的主力。 它适合处理老式网关、哑终端、无标签接入等场景，但不应成为整网主要分类手段。若所有端口都依赖默认优先级，网络将失去按应用区分的能力，也无法处理同一端口上多业务共存的场景。
接入端口收到报文
│
├─ 命中静态源 MAC / VLAN / 802.1p / DSCP 等？ ──► 按判定链处理
│
└─ 均未命中 ──► 端口默认优先级 ──► 进入对应 TC
体系A 配置与查看示例：
zte(cfg)#set port 1 default-priority 5
zte(cfg)#show port 1 qos
现场怎么用：端口接老式语音网关且报文不带 VLAN tag，可给该端口设置较高默认优先级；同一端口下既有语音又有时延不敏感的 PC，应优先采用 VLAN、ACL、源 MAC 或上游标记分类，而不是把所有流量统一抬高。
配错什么现象：若把普通数据端口设为高默认优先级，突发下载会抢占关键业务队列；若语音端口默认优先级太低，又未打 802.1p/DSCP，语音会在拥塞时落入低队列。
怎么验证：查看 show port <id> qos、实际报文 Tag 和接口队列统计；在拥塞压力下确认语音流是否进入预期 TC，而不能只凭配置数值判断。
7_3 QoS 命令与默认映射
本节要解决什么问题：本节给出 QoS 的配置命令与默认映射表。请特别留意中兴 802.1p=0 映射到 TC1 这个与其他厂商不同的默认值。
7_3_1 配置命令
命令是策略落地的入口，但真正的控制对象是“标记—内部优先级—TC—调度器”的完整映射。 本节所列体系A 命令用于建立基线；体系B 进入 qos 配置模式时，不同版本命令形态差异较大，现场用 qos ? 逐级确认，禁止把一套关键字直接移植到另一版本。
| # | 功能 | 体系A 命令 | 现场含义 |
|---|---|---|---|
| 1 | 队列调度模式 | set qos queue-schedule {sp|wfq} |
决定出口如何选取各 TC 报文 |
| 2 | 802.1p→TC | set qos priority-map user-priority [0-7] traffic-class [0-3] |
二层 CoS 进入哪个队列 |
| 3 | DSCP→TC | set qos priority-map ip-priority [0-63] traffic-class [0-3] |
三层 DSCP 进入哪个队列 |
| 4 | 报文最大长度 | set qos max-frame-size [1522|1632] |
QoS 相关帧长限制；默认 1632 |
zte(cfg)#set qos queue-schedule sp
zte(cfg)#set qos queue-schedule wfq
zte(cfg)#set qos priority-map user-priority 6 traffic-class 3
zte(cfg)#set qos priority-map ip-priority 46 traffic-class 3
zte(cfg)#set qos max-frame-size 1632
现场怎么用：先定义业务→802.1p/DSCP→TC 的规划表，再批量下发映射；调度模式只在确认出口拥塞模型后设置。每次变更只改一个变量，先保存基线，再分别验证分类、映射、调度和限速。
配错什么现象：把 user-priority 与 ip-priority 混为一谈，会造成二层信任正确而三层映射无效，或反之；max-frame-size 设置过小可能导致巨型帧、特定隧道封装帧被丢弃，具体是否生效与版本/板卡有关，应以实际配置和运行日志为准。
怎么验证：逐项执行 7_8 验证清单，重点对比 show qos priority-map 输出和拥塞时的队列计数，避免只检查 running-config。
7_3_2 默认映射关系
默认映射是设备“出厂理解”，不是业务语义。 TC0~TC3 中数字越大优先级越高：TC3 最高，TC0 最低。因此规划业务时必须先确定目标 TC，再反推 802.1p 与 DSCP 映射；只记“EF=46”而不看本地映射，仍可能进入错误队列。
| 映射类型 | 默认对应关系 |
|---|---|
| 802.1p→TC | 0→TC1、3→TC1；1→TC0、2→TC0；4→TC2、5→TC2；6→TC3、7→TC3 |
| DSCP→TC | 0-15→TC0；16-31→TC1；32-47→TC2；48-63→TC3 |
802.1p=0 映射到 TC1，是中兴特有默认值，绝不能套用通用“0 最低”直觉。 在跨厂商网络中，这一点尤其重要：若上游设备按照另一种 CoS 语义打标，或者运维人员没有查本地表，直接按“802.1p 数值小就一定低”配置，可能让 BE 流量进入高于预期的位置。
802.1p → TC 默认映射（中兴设备场景）
| 802.1p 值 | 默认映射到 TC | 提醒 |
|---|---|---|
| 0 | TC1 | 中兴特有默认值：不等于 TC0，切勿套用"0 就是最低"的直觉 |
| 1 | TC0 | 常见低优先级（背景业务） |
| 2 | TC0 | 常见低优先级（背景业务） |
| 3 | TC1 | 常见普通业务 |
| 4 | TC2 | 常见中高优先级（视频等） |
| 5 | TC2 | 常见中高优先级（视频等） |
| 6 | TC3 | 常见最高优先级（语音等） |
| 7 | TC3 | 网络控制报文，谨慎使用——被滥用会抢占所有业务带宽 |
DSCP → TC 默认映射
| DSCP 范围 | 默认映射到 TC | 常见值与说明 |
|---|---|---|
| 0 – 15 | TC0 | BE=0、CS1=8 等，尽力而为与低优先业务 |
| 16 – 31 | TC1 | AF31=26 等，保证转发类业务 |
| 32 – 47 | TC2 | AF41=34、EF=46 等，视频与加速转发业务 |
| 48 – 63 | TC3 | CS6=48、CS7=56 等，网络控制与协议报文 |
这两张表怎么用：先确认你的业务报文带的是哪种标记（二层 802.1p 还是三层 DSCP），再查它默认落到哪个 TC，最后用
priority-map把不合适的映射改掉。两张表都必须核对——只改一张，另一类标记的报文仍会落到默认队列。
TC 编号是队列的相对优先级，不代表固定带宽。 在 SP 模式下，TC3 通常会抢占低队列；在 WFQ/WRR 模式下，设备按权重轮询，TC 编号仍会影响实现，但“高优先级”不必然等价于“无限带宽”。具体权重、队列深度、是否支持严格组与加权组混合，依型号和版本确认。
【踩坑】默认 DSCP 映射中，EF=46 落入 TC2，而不是最高的 TC3。若设计要求语音在拥塞时严格优先，应显式调整 ip-priority 46 → traffic-class 3，并确认相邻设备、接入边界和出口调度均一致。
7_3_3 显示命令
显示命令的作用是还原运行态，而不是复述配置文件。 验证 QoS 至少要同时检查调度模式、两个映射表、端口 QoS 状态和队列统计；只执行 show running-config 无法确认软件版本是否真正安装策略，也无法看到运行时丢弃计数。
| 功能 | 体系A 命令 | 关键检查点 |
|---|---|---|
| 队列调度配置 | show qos queue-schedule |
sp/wfq、是否支持混合模式 |
| 802.1p 映射 | show qos priority-map user-priority |
0-7 是否按规划落入 TC |
| DSCP 映射 | show qos priority-map ip-priority |
关键 DSCP 是否进入目标 TC |
| 端口 QoS 状态 | show port <id> qos |
默认优先级、限速、接口 QoS 状态 |
| 端口统计 | show port <id> statistics |
丢包、队列丢包、利用率 |
zte#show qos queue-schedule
zte#show qos priority-map user-priority
zte#show qos priority-map ip-priority
zte#show port 1 qos
zte#show port 1 statistics
现场怎么用：将变更前的映射表、变更后映射表和拥塞时段队列统计各保存一份；比较关键业务的 TC 是否前后一致。若配置正确但统计长期不变，应怀疑策略未真正命中，或该接口不存在拥塞。
配错什么现象：show 结果中 802.1p=6 不在 TC3、DSCP=46 不在目标 TC，或端口默认优先级覆盖了真实业务；这些都可能在无压力测试中被忽略，到高峰时段才暴露。
7_4 队列调度机制
本节要解决什么问题：映射只是「分了队」，真正决定谁先走的是队列调度。前提要记牢：只在端口拥塞时才起作用。
7_4_1 调度只在端口拥塞时生效
队列调度是拥塞点技术，不是链路加速技术。 当出口发送能力高于待发报文总量时，报文几乎不经过明显排队，SP、WFQ、WRR 对时延和发送顺序的差异难以体现；只有当出向带宽不足、多个队列同时积压时，调度器才真正决定“下一个发送谁”。
非拥塞状态（发送速率 > 到达速率）
到达 ──────► 几乎无排队 ──────► 立即发送
SP 与 WFQ 行为差异很小
拥塞状态（到达速率 > 发送速率）
多个 TC 有积压
│
▼
调度器开始工作：SP 优先高 TC，WFQ/WRR 按权重轮询
│
▼
缓冲区满时触发拥塞避免/丢包
这条前提决定验证方法。 若想证明 SP 能保护语音，必须在链路拥塞的同时注入语音流与背景流；若只是 ping 或轻载 iperf，无法证明 TC3 真正抢占。反过来，若链路永远拥塞，也不能只靠 QoS，应同步评估限速、扩容和路径优化。
【踩坑】“配了 SP，语音仍然卡”不一定表示调度配置无效。也可能因为没有拥塞、报文未进入 TC3、入口瓶颈在 upstream、或者语音问题源于终端/编码/抖动缓冲，而非交换机排队。验证要从报文标记一路追踪到出口队列统计。
7_4_2 SP（严格优先级）
SP 的核心优势是低时延，核心风险是低队列饥饿。 高优先级队列存在待发报文时，调度器持续服务该队列；只有高队列为空，才服务下一优先级。对语音、实时视频等时延敏感业务，这能让关键报文尽快离开拥塞接口；但如果高队列流量持续超过出口能力，TC0~TC2 可能长期得不到服务。
SP 调度示意
┌────┐ ┌────┐ ┌────┐ ┌────┐
│TC3 │───►│TC2 │───►│TC1 │───►│TC0 │──► 出口
│语音│ │视频│ │业务│ │备份│
└────┘ └────┘ └────┘ └────┘
只要非空，持续优先发送
优点：实时业务排队时延低、抖动相对可控。
缺点：TC3 持续过载时，TC0-TC2 可能“饿死”。
适用边界：语音信令/媒体、关键网管、协议控制等持续速率可控的流量适合 SP；持续大带宽的备份、文件同步、P2P 绝不能无限制放入最高队列。一个经验判断是：若高优先级队列的长期平均速率接近出口带宽，SP 的饥饿风险将不可接受。
体系A 配置：
zte(cfg)#set qos queue-schedule sp
zte#show qos queue-schedule
7_4_3 WFQ / WRR（加权公平调度）
WFQ/WRR 的目标是隔离业务、按比例分配机会，而不是让所有业务完全平等。 设备按配置权重在各队列间轮询，权重高的队列获得更多发送机会。相较于 SP，它能降低低优先级队列长期饥饿的概率，但在高负载下，低权重实时业务仍会承受更大排队时延。
WFQ/WRR 调度示意（权重为逻辑示例）
TC3 (权重4) ──┐
TC2 (权重3) ──┼──► 按权重轮询 ──► 出口
TC1 (权重2) ──┤
TC0 (权重1) ──┘
相对带宽机会 ≈ 4:3:2:1（具体实现依型号/版本）
优点：多业务共享时降低饥饿风险，适合办公网、多租户。
缺点：单一高权重队列突发时仍会影响他人；实时性不如纯 SP。
权重不是承诺速率。 当高权重队列无报文时，其他队列可以使用空闲带宽；当所有队列都有积压时，调度机会接近权重比例，但实际报文长度、队列长度、硬件实现都会影响吞吐。不要把“WRR 权重 4”直接等同于“固定获得 40% 带宽”。
7_4_4 SP 与 WFQ/WRR 选型
选型要从业务时延要求、流量速率和饥饿风险三个维度同时判断。 单一实时业务可优先考虑 SP；多业务共享且需要公平性时优先考虑 WFQ/WRR；复杂场景可采用“高优先级队列少量严格保障 + 其余队列加权轮询”的混合结构，但具体语法与支持情况必须以设备版本为准。
| 场景 | 建议 | 理由 | 必须配套措施 |
|---|---|---|---|
| VoIP、实时语音 | SP 或混合模式中的严格组 | 对时延、抖动最敏感 | 限制高队列总量、正确分类 |
| IPTV、视频会议 | SP/高优先级 + 带宽保障 | 要求持续吞吐与较低抖动 | 组播/CAC、拥塞避免 |
| 企业办公多业务 | WFQ/WRR | 避免单部门饿死 | 关键业务赋予更高权重 |
| 备份、下载、同步 | 低 TC + WFQ | 可容忍延迟，需限制影响面 | 入向/出向限速 |
| 网管、协议控制 | 最高优先级保护 | 拥塞时保持可运维性 | ACL/控制面保护 |
| 数据中心大突发 | WFQ/按流调度或结合拥塞控制 | 避免单队列长期独占 | 缓冲区、ECN/WRED 视支持情况 |
zte(cfg)#set qos queue-schedule sp
zte(cfg)#set qos queue-schedule wfq
zte#show qos queue-schedule
【ZCIE】若被问到“SP 和 WFQ 哪个更好”，应回答：没有绝对优劣。SP 给实时业务最低排队时延但有饥饿风险；WFQ 提高隔离性和公平性却可能削弱严格实时性。正确做法是基于流量画像选模型，并把高优先级业务的速率控制在可保障范围内。
7_5 优先级映射配置实战
本节要解决什么问题：本节给出可直接落地的队列规划脚本，并解决「服务器只打 DSCP、交换机不认」这一高频问题。
7_5_1 IPTV 与语音队列规划
端到端 QoS 的第一步是业务优先级规划表，而不是先敲映射命令。 规划表把业务、二层标记、三层标记、目标 TC、调度方式和带宽边界放在一张图中，既能防止跨设备不一致，也便于验收时逐条比对。
| 业务 | 802.1p | DSCP | 目标 TC | 调度方式 | 设计说明 |
|---|---|---|---|---|---|
| 语音 VoIP | 6 | EF=46 | TC3 | SP | 最低时延，限制总量 |
| IPTV 直播 | 5 | AF31=26 / CS4=32 | TC2 | SP 或高权重 | 连续吞吐，避免乱入 TC3 |
| 视频会议 | 4 | AF41=34 | TC2 | SP 或高权重 | 双向实时，关注上下行 |
| 关键业务 | 3 | AF21=18 | TC1 | WFQ | ERP、生产、认证等 |
| 普通办公 | 0 | BE=0 | TC1 | WFQ | 默认数据 |
| 备份/下载 | 1 | CS1=8 | TC0 | WFQ | 可限速、可丢弃 |
该表的关键不是数值本身，而是避免冲突。 例如 IPTV 需要稳定吞吐，但一般不要求像语音那样抢占所有其他流量，因此放在 TC2；语音只在 TC3，避免视频突发挤占；备份即使突发也不会进入 TC1/TC2。若某类业务经常需要超过链路容量，应修改容量设计，而不是把其永久放进最高队列。
7_5_2 映射配置实例
配置要同时覆盖调度、802.1p 映射和 DSCP 映射，并保留回退基线。 下列脚本以体系A 为例，目标为语音 TC3、视频 TC2、普通数据 TC1、低优先业务 TC0。现场执行前必须确认当前映射、业务 VLAN、端口范围和版本支持情况。
! ---------- 1. 队列调度：语音/实时业务优先 ----------
zte(cfg)#set qos queue-schedule sp
! ---------- 2. 802.1p → TC：按业务规划覆盖默认值 ----------
zte(cfg)#set qos priority-map user-priority 6 traffic-class 3
zte(cfg)#set qos priority-map user-priority 7 traffic-class 3
zte(cfg)#set qos priority-map user-priority 5 traffic-class 2
zte(cfg)#set qos priority-map user-priority 4 traffic-class 2
zte(cfg)#set qos priority-map user-priority 3 traffic-class 1
zte(cfg)#set qos priority-map user-priority 0 traffic-class 1
zte(cfg)#set qos priority-map user-priority 2 traffic-class 0
zte(cfg)#set qos priority-map user-priority 1 traffic-class 0
! ---------- 3. DSCP → TC：让三层标记也进入目标队列 ----------
zte(cfg)#set qos priority-map ip-priority 46 traffic-class 3
zte(cfg)#set qos priority-map ip-priority 34 traffic-class 2
zte(cfg)#set qos priority-map ip-priority 26 traffic-class 2
zte(cfg)#set qos priority-map ip-priority 18 traffic-class 1
zte(cfg)#set qos priority-map ip-priority 0 traffic-class 1
zte(cfg)#set qos priority-map ip-priority 8 traffic-class 0
! ---------- 4. 验证 ----------
zte#show qos queue-schedule
zte#show qos priority-map user-priority
zte#show qos priority-map ip-priority
现场怎么用：先在一个接入口和一个拥塞上联口做试点，使用镜像或计数器确认语音流进入 TC3、视频流进入 TC2；验证后再分批应用至同类型端口。若现网已有默认映射，采用增量覆盖，不要在不理解原映射影响范围时一次性全改。
配错什么现象：将视频会议 802.1p=4 映射至 TC3，备份误标 802.1p=6，或者 EF=46 没有进入 TC3，都会破坏优先级语义；最直观的故障是拥塞时“不该卡的卡、该卡的反而抢资源”。
怎么验证：在出口链路打满背景流量，同时发送语音和视频流；查看各 TC 计数、时延、丢包和抖动。若语音 TC3 计数不增长，说明分类或标记未命中；若 TC3 增长但语音仍卡，瓶颈可能在入向、终端或路径其他位置。
7_5_3 让 DSCP 生效的两种解法
DSCP 不生效的根源通常不是“DSCP 不存在”，而是信任边界与映射缺失。 当服务器或终端只设置 IP 层 DSCP 而二层帧没有对应 802.1p 时，默认二层优先级逻辑可能直接采用其他判定来源。解决思路只有两个：要么让本机识别 DSCP 并映射到正确 TC；要么在边界把 DSCP 转换为一致的 802.1p。
解法一：调整 DSCP → TC 映射
服务器 DSCP=46 ──► 本机 ip-priority 46 → TC3 ──► SP 保障
适用：三层网络、终端/服务器标记可信、整网使用 DSCP 为主
解法二：接入层重标记
服务器 DSCP=46 ──► 接入设备按分类映射为 802.1p=6 ──► TC3
适用：二层域、需统一 CoS、终端标记不可完全信任
解法一：直接映射 DSCP 至目标 TC。
! 语音 EF(46) 默认在 TC2；设计要求严格优先时调整至 TC3
zte(cfg)#set qos priority-map ip-priority 46 traffic-class 3
! AF41(34) 视频会议保持/调整至 TC2
zte(cfg)#set qos priority-map ip-priority 34 traffic-class 2
! CS7(56) 网络控制默认已在 TC3；仍建议显式确认
zte(cfg)#show qos priority-map ip-priority
解法二：在接入层按业务重新标记 802.1p。 这种方式对下游只识别 CoS 的设备更友好，但必须保证重标记规则与整网业务表一致，且不能在信任边界来回改写造成震荡。
! 为无标记报文兜底
zte(cfg)#set port 1-24 default-priority 0
! 语音网关接入端口，按现场分类策略提升默认优先级
zte(cfg)#set port 21 default-priority 6
! 更严谨做法：结合 ACL/源 MAC/VLAN/DSCP 分类后再重标记
zte#show port 21 qos
两种解法不是互斥关系。 最佳实践是：终端可信时保留端到端 DSCP；边界设备同时维护 DSCP→TC 与 802.1p→TC，并确保二者语义一致；不可信终端则在接入层重标记，且禁止访客、IoT 等流量进入高优先级队列。
7_5_4 DSCP / 802.1p 取值速查
取值表必须和本地映射表一起使用。 下表是常见业务约定，不代表所有网络都必须照抄；尤其 DSCP 进入哪个 TC，由 7_3 映射决定。规划阶段固定本网的“业务—标记—TC”映射，禁止不同设备对同一 DSCP 使用冲突语义。
| 业务 | DSCP 名称 | DSCP 值 | 802.1p | 建议 TC | 使用提醒 |
|---|---|---|---|---|---|
| 网络控制/路由协议 | CS7 / CS6 | 56 / 48 | 7 | TC3 | 优先保障但应限制速率 |
| 语音 VoIP | EF | 46 | 5~6 | TC3 | 严格低时延 |
| 视频会议 | AF41 / AF42 | 34 / 36 | 4 | TC2 | 关注双向实时性 |
| IPTV 直播 | AF31 / CS4 | 26 / 32 | 4~5 | TC2 | 连续吞吐、组播场景 |
| 关键业务 | AF21 / AF22 | 18 / 20 | 3 | TC1 | ERP、生产、业务系统 |
| 普通数据 | BE / CS0 | 0 | 0 | TC1 | 默认承载 |
| 大流量备份 | CS1 / AF11 | 8 / 10 | 1~2 | TC0 | 限速、可丢弃 |
【踩坑】AF31=26 落在默认 DSCP→TC1，而常见 IPTV 规划可能希望其进入 TC2；CS1=8 落在默认 TC0。这些都说明“DSCP 名字”与“目标队列”之间需要显式映射，不能只依赖 RFC 名称。
7_6 限速与带宽控制
本节要解决什么问题：调度之外还需要限速。本节对比限速、流控反压与整形三种手段的适用场景。
7_6_1 端口级限速
限速解决的是“不可控流量占用多少”，而队列调度解决的是“剩下多少时谁先走”。 两者互补：先把备份、下载、P2P、异常突发限制住，才能给语音、视频和关键业务留下稳定的排队空间。若只限速但所有业务仍混在同一队列，限速后低优先业务仍可能抢先；若只调度不限速，突发流量也可能先填满高优先级队列。
体系A 端口限速示例：
! 入方向限速 10M，超限执行 tcpdrop
zte(cfg)#set port 5 bandwidth ingress on rate 10240 tcpdrop
! 出方向限速 50M
zte(cfg)#set port 5 bandwidth egress on rate 51200
! 关闭限速
zte(cfg)#set port 5 bandwidth ingress off
zte(cfg)#set port 5 bandwidth egress off
! 查看
zte#show port 5 qos
zte#show port 5 statistics
现场怎么用：rate 使用 kbps 语义时，10240 表示 10,240 kbps，即 10 Mbps；具体单位与取值区间依设备版本确认。面向服务器接入口，先限制单主机总出向带宽；面向用户接入口，可对入向突发下载限速，避免其通过上行拥塞影响其他用户。
配错什么现象：单位理解错误会使限速相差数量级；只配 egress 而实际瓶颈在 ingress，业务仍可能在远端出口拥塞；tcpdrop 作用于 TCP 时会触发拥塞控制降速，但对 UDP/实时流不一定达到预期平滑效果。
7_6_2 Policing、Shaping 与流控反压
Policing、Shaping 和流控反压分别对应“丢/缓/停”，不能互换称呼。 Policing 在超过策略时直接丢弃或降级，适合把不可控流量挡在边界；Shaping 以缓存平滑突发，适合对时延不极端但希望减少丢弃的出口；PAUSE 反压让对端暂停发送，适合点到点链路，但会引入队头阻塞风险。
| 机制 | 行为 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|---|
| Policing 限速/监管 | 超速丢弃或降级 | 简单、即时、可保护下游 | 丢包、TCP 重传 | 接入限速、异常流量 |
| Shaping 整形 | 缓存后按约定平滑发送 | 降低突发丢弃 | 增加时延、需要缓存 | 广域出口、突发平滑 |
| 流控反压 PAUSE | 通知对端暂停发送 | 可减少上游丢包 | 队头阻塞、影响所有流 | 直连点对点、特定数据中心 |
| 队列调度 | 拥塞时决定发送顺序 | 保障关键业务 | 不增加总带宽 | 所有拥塞点 |
Policing：报文到达 ──► 是否在速率契约内？
├─ 是 ──► 继续转发
└─ 否 ──► 丢弃 / 降级
Shaping：报文到达 ──► 缓存 ──► 按平滑速率发送
（突发可被吸收，但排队时延上升）
Flow Control：本端缓存紧张 ──► 发送 PAUSE ──► 对端暂停发送
（只建议点到点直连，谨慎用于多业务汇聚）
7_6_3 选型建议
选型顺序应是：先明确丢包敏感性，再选择控制位置，最后选择机制。 对时延敏感的语音、视频优先通过分类和调度保障，不宜简单粗暴限速；对可重传、可暂停的大流量，优先限制其平均速率；跨广域链路优先考虑整形以平滑突发。
实时语音/视频 → 优先分类 + SP/高优先级；避免把核心媒体流直接 tcpdrop
备份/下载/P2P → 入向限速 + tcpdrop，让 TCP 自行降速
单台服务器出向 → 出向限速，避免抢占上联
跨广域链路突发 → 整形优先，减少远端丢弃（设备支持时）
直连交换机/服务器链路 → 评估 PAUSE；多业务汇聚慎用
【踩坑】“限速后业务变慢”不一定表示限速值过小。若被限流量原本是 TCP，丢弃会使其降速；若应用对小丢包敏感，反而应优先调度、限速背景流或采用整形，而不是把关键业务直接丢包。
7_7 端到端 QoS 设计
本节要解决什么问题：单台设备的 QoS 没有意义。本节把 QoS 拆到终端、接入、汇聚、核心、出口五个环节讲端到端设计。
7_7_1 端到端三平面
端到端 QoS 必须按“业务分类—信任边界—逐跳调度—瓶颈控制”组织，而不能只在核心交换机配一个 SP。 终端负责在源头打标记，接入层定义信任边界，汇聚和核心在每一跳维持一致映射，出口或瓶颈链路执行调度、限速和拥塞避免。任何一跳重置标记或不做调度，都会削弱整网保障。
终端/服务器 接入层 汇聚层 核心/出口
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ 打标记 │──────►│ 信任/ │────────►│ 信任/ │────────►│ 队列调度│
│ DSCP/ │ │ 重标记 │ │ 队列 │ │ 限速 │
│ 802.1p │ │ 限速 │ │ 调度 │ │ 拥塞避免│
└────────┘ └────────┘ └────────┘ └────────┘
① ② ③ ④
① 分类与标记：越靠近源头越准确，但终端标记不一定可信。
② 信任边界：决定保留标记、重写标记或赋予默认优先级。
③ 逐跳调度：所有拥塞点都应具备正确映射和调度能力。
④ 出口控制：瓶颈链路执行限速、整形、拥塞避免。
| 平面 | 核心职责 | 关键配置/动作 | 常见失误 |
|---|---|---|---|
| 业务平面 | 定义业务等级、SLA | 业务表、带宽预算 | 没有业务清单，全靠经验 |
| 控制平面 | 分类、标记、信任边界 | ACL、VLAN、CoS/DSCP、重标记 | 只配二层或只配三层 |
| 转发平面 | 映射、调度、限速、丢弃 | TC、SP/WFQ、policing/shaping | 只有核心配、接入不改写 |
7_7_2 接入、汇聚、核心、出口各做什么
不同网络层次的职责不同，但优先级语义必须连续。 接入层最靠近终端，承担分类、信任和重标记；汇聚层聚合流量，是队列调度的重要位置；核心层以高速转发为主，但瓶颈链路仍须保证映射与调度一致；出口是运营商/分支机构边界，应同时做限速、整形和流量工程联动。
接入层：分类、信任边界、端口默认优先级、轻量限速
汇聚层：按 TC 调度、拥塞避免、跨 VLAN/子网聚合
核心层：维持标记与映射一致，聚焦高速转发和瓶颈点
出口 ：限速/整形、关键业务保障、跨域标记策略
| 层次 | 必须做 | 建议做 | 不建议做 |
|---|---|---|---|
| 接入 | 分类、信任/重标记、端口默认优先级 | 每端口限速 | 复杂多层嵌套策略 |
| 汇聚 | TC 映射、SP/WFQ、队列统计 | 拥塞避免、流量监管 | 对终端标记无条件信任 |
| 核心 | 保持标记/映射一致 | 在瓶颈处做调度 | 逐流深度分类造成性能压力 |
| 出口 | 限速/整形、关键业务优先 | 跨域标记转换 | 让不可控流量进入最高队列 |
7_7_3 信任边界设计
信任边界是安全与体验的交汇点。 可信语音终端、视频会议终端可以按预定义规则保留标记；PC、访客、IoT 等不可信终端则应统一归入默认优先级，再根据身份、VLAN、ACL 或应用策略重标记。若所有接入端口都无条件信任终端 DSCP/802.1p，恶意或错误配置的终端可把自身流量抬到最高等级，形成优先级抢占。
策略 A：信任 Trust
终端正确打标 → 接入设备保持标记 → 按标记调度
适用：受控 IP 电话、语音网关、视频终端、可信服务器
风险：终端伪造高优先级；需通过准入、VLAN、源地址控制约束
策略 B：不信任 + 重标记 Untrust/Remark
接入设备重新识别并打标 → 统一全网语义
适用：办公 PC、访客、IoT、不可控服务器
做法：default-priority 兜底 + ACL/源 MAC/VLAN/DSCP 分类
| 端口类型 | 信任策略 | 实现要点 | 默认处理 |
|---|---|---|---|
| IP 电话/语音网关 | 有条件信任 | 校验语音 VLAN、终端身份 | 802.1p=6、DSCP EF |
| 视频会议终端 | 有条件信任 | 保留实时业务标记 | 802.1p=4/5 |
| 普通办公 PC | 不信任 | 按 VLAN/策略重标记 | default-priority 0 |
| 服务器 | 按 ACL 分类 | 基于端口、网段、角色 | 关键业务单独规划 |
| 访客/IoT | 不信任+限速 | 禁止进入高优先级队列 | TC0/TC1 |
7_7_4 端到端 QoS 落地七步法
七步法把“业务语言”逐步转换为“设备配置”。 每一步都要有负责人、验证方法和回退方案；跳过业务画像或拥塞测量，后面的映射与调度很容易成为形式化配置。
Step 1 业务盘点：语音、视频、业务系统、普通数据、备份、网管、协议控制
Step 2 指标定义：时延/抖动/丢包/带宽 SLA，明确哪些业务不可饿死
Step 3 标记规划：业务 → 802.1p/DSCP → TC → 调度方式
Step 4 信任边界：终端是否可信，接入层是否重标记，跨域如何处理
Step 5 逐跳映射：接入/汇聚/核心/出口使用统一 priority-map 基线
Step 6 拥塞控制：调度、限速、整形、拥塞避免，聚焦瓶颈链路
Step 7 验证闭环：抓包、队列计数、压力测试、回退与文档沉淀
- 业务盘点：列出所有业务和源/目的范围，不能只有“语音、数据”两个大类。
- 指标定义：为每类业务定义最大时延、抖动、丢包和最低带宽；无法定义的业务不宜硬占最高队列。
- 标记规划：形成 7_5_1 规划表，确认全网一致。
- 信任边界：明确哪些端口 trust、哪些 remark，以及重标记依据。
- 逐跳映射：在所有相关设备的入向/出向处理中检查 802.1p 与 DSCP 映射。
- 拥塞控制：在上联、出口、跨域瓶颈部署限速、整形、调度和丢弃策略。
- 验证闭环：使用轻载与满载两组测试，保存基线、实际结果与回退脚本。
【ZCIE】答辩中最有价值的不是“记住 SP”，而是能说明：业务等级如何定义、信任边界设在哪、哪个链路是瓶颈、为什么选 SP/WFQ、如何证明有效、失败如何回退。
7_7_5 拥塞前的保命队列
网络自身可管理性必须先于业务体验被保护。 若路由协议、STP、OAM、网管 SSH/SNMP 在拥塞时失联，故障定位和变更回退将变得困难，甚至引发二次事故。优先级判定链把 CPU 包、管理包放在高位，正是为此；工程上仍需保证这些报文被映射到高 TC，并有合理的速率边界。
拥塞时必须优先保障（否则网络可能失去管理）：
① 路由协议报文（OSPF/BGP/IS-IS） → TC3，防止路由震荡
② STP BPDU / 控制协议 → 管理包优先级
③ 网管 SSH / SNMP / NTP → TC3，保证远程维护
④ 语音、实时视频 → TC3 / TC2
| 保护对象 | 推荐位置 | 控制动作 | 注意 |
|---|---|---|---|
| 控制协议 | TC3 | SP/最高权重 | 限制异常控制流量 |
| 网管 | TC3 | 分类后优先 | 限制 SSH/SNMP 速率 |
| 语音 | TC3 | SP | 控制总带宽 |
| 视频 | TC2 | SP/高权重 | 防突发挤占 |
| 普通业务 | TC1 | WFQ | 保留必要带宽 |
| 备份/低优先 | TC0 | WFQ/限速 | 允许丢弃 |
7_8 笔记方法与验证清单
本节要解决什么问题：QoS 是最难「看出效果」的技术，因为空载时一切正常。本节给出可复制的规划表、基线与验证方法。
7_8_1 故障排查决策树
QoS 故障排查要从“业务现象—拥塞证据—报文标记—优先级判定—TC 映射—队列统计”逐步收缩。 常见错误是直接修改队列调度，而没有确认报文是否进入预期 TC，或没有确认接口是否拥塞。前者属于盲目配置，后者会导致“配置正确但无效果”的误判。
现象：语音断续 / 视频花屏 / 关键业务慢 / 限速无效
│
├─① show qos queue-schedule 调度模式符合预期吗？
│
├─② show qos priority-map user-priority 802.1p→TC 是否正确？
│
├─③ show qos priority-map ip-priority DSCP→TC 是否正确？
│
├─④ 抓包确认终端是否打了 802.1p/DSCP
│ ├─ 未打标记 → default-priority / 接入重标记
│ └─ 已打标记 → 检查信任边界是否被改写
│
├─⑤ show port <id> qos 默认优先级、限速是否生效？
│
├─⑥ show port <id> statistics 是否丢包、哪个队列丢？
│
└─⑦ 是否真正拥塞？ 比对入/出带宽与队列深度
├─ 无拥塞 → 调度不应有效果，先查应用/路径
└─ 有拥塞 → 按 TC 统计反推分类/映射
7_8_2 常见认知误区与真相
| 现象 | 常见误解 | 真相 |
|---|---|---|
| 配了 QoS 但没效果 | 命令没生效 | 很可能没有拥塞；调度只在拥塞点作用 |
| DSCP 配了不生效 | 设备有 bug | 默认更可能信任 802.1p；检查 DSCP→TC 与信任边界 |
| 限速值和实际不符 | 单位是 Mbps | rate 单位依版本可能为 kbps；现场先 ? 确认 |
| 语音仍卡 | 队列不够高 | 也可能入口拥塞、标记错误、瓶颈在上游 |
| 低优先级饿死 | 只是普通丢包 | SP 持续高队列占用时的固有限制 |
| 改了映射仍无效 | 应该立即生效 | 存量流、缓存、其他设备映射、实际拥塞点都可能干扰 |
7_8_3 业务优先级规划表模板
规划表是配置与验收的共同基准。 每个业务至少记录 802.1p、DSCP、目标 TC、调度方式、限速阈值和信任边界；若某项留空，现场极容易按个人经验临时决策，导致跨设备不一致。
| 业务 | 源/目的 | 802.1p | DSCP | 目标TC | 调度 | 带宽上限 | 信任策略 | 端口/VLAN |
|:---|:---|:---:|:---:|:---:|:---|:---|:---|:---|
| VoIP | 语音VLAN/网关 | 6 | 46 | TC3 | SP | 按并发计算 | 有条件信任 | Gi0/1-8 |
| IPTV | 组播VLAN | 5 | 26 | TC2 | SP | 频道带宽之和 | 信任 | Gi0/9-12 |
| 视频会议 | 终端网段 | 4 | 34 | TC2 | SP | 峰值预留 | 有条件信任 | Gi0/13-16 |
| 关键业务 | 业务VLAN | 3 | 18 | TC1 | WFQ | 按SLA | ACL分类 | Gi0/17-20 |
| 办公 | 用户VLAN | 0 | 0 | TC1 | WFQ | 不限/限速 | 不信任 | Gi0/21-40 |
| 备份 | 服务器VLAN | 1 | 8 | TC0 | WFQ | 20Mbps | 不信任+限速 | Gi0/41-44 |
7_8_4 QoS 配置基线记录模板
【设备名称】【角色：接入/汇聚/核心/出口】【软件版本】
【变更日期】【变更人】【变更单号】
一、业务规划摘要
- 最高保障：
- 高保障：
- 普通：
- 可丢弃：
二、调度配置
- queue-schedule：
- 高优先级带宽边界：
- 混合模式（如有）：
三、映射配置
- 802.1p→TC：
- DSCP→TC：
- 端口默认优先级：
四、限速/整形
- 端口/方向/rate/动作：
五、验证结果
- 轻载结果：
- 满载结果：
- 抓包文件：
- 队列统计：
六、回退脚本
- 回退步骤逐条：
7_8_5 拥塞时段抓包记录模板
【抓包时间】【持续时长】【设备/接口】【镜像方向：入/出】
一、流量背景
- 接口带宽：
- 当前利用率：
- 是否存在拥塞：是/否
二、报文样本
| 时间戳 | 源IP | 目的IP | VLAN | 802.1p | DSCP | 长度 | 丢包/重传 |
|:---|:---|:---|:---|:---|:---|:---|:---|
三、关键业务观察
- VoIP：报文间隔、抖动、丢包、DSCP/CoS 是否一致
- IPTV：组播源、视频VLAN、乱序/丢帧
- 关键业务：TCP重传、RTT、是否进入预期TC
四、队列/接口统计
- TC3/TC2/TC1/TC0 计数：
- 丢弃计数：
- 限速丢弃：
五、结论与动作
- 根因判断：
- 需调整分类/映射/调度/限速：
7_8_6 验证清单
验证必须覆盖配置、报文、运行统计和压力测试四个层次。 单项命令正常不能替代业务验收；特别要记录“拥塞时 TC3 是否保护、TC0 是否受限、网管是否可达”三项。
| 验证命令 | 预期结果/关键字段 | 不符时的排查方向 |
|---|---|---|
show qos queue-schedule |
sp/wfq 与方案一致 | 配置未提交、版本不支持、模式被覆盖 |
show qos priority-map user-priority |
0-7 映射符合规划 | 默认值误解、增量配置遗漏 |
show qos priority-map ip-priority |
EF/AF/CS 落在目标 TC | DSCP 未映射、信任边界错误 |
show port <id> qos |
默认优先级、限速符合基线 | 端口范围错误、限速方向错误 |
show port <id> statistics |
无异常 discard，TC 计数随业务增长 | 队列溢出、分类错误、瓶颈移位 |
| 抓包查看 802.1p/DSCP | 与终端/上游规划一致 | 终端未打标、VLAN 边界改写 |
| iperf/traffic generator 限速测试 | 速率稳定在策略附近 | rate 单位、双工、统计口径 |
| 拥塞压力测试 + 语音流 | TC3 语音优先，丢包/时延达标 | 分类、映射、调度、上游瓶颈 |
| 打满 TC0 时观察 TC3 | 高优先级业务不受显著影响 | SP/WFQ 选择、饥饿、带宽不足 |
| 拥塞时 SSH/SNMP 测试 | 网管保持可达 | 网管未进高 TC、CPU/控制面保护不足 |
show running-config qos（如支持） |
策略已保存 | 未 write/save、配置会话未应用 |
| 镜像/抓包 + 队列计数联动 | 特定流 TC 计数与抓包一致 | ACL、源 MAC、VLAN、DSCP 判定覆盖 |
7_9 考点速记与自检清单
本节要解决什么问题：最后是考点速记与自检清单。
7_9_1 考点速记
- QoS 四大问题：带宽、时延、抖动、丢包；核心前提：QoS 不能创造带宽，只决定谁先用、谁先丢。
- 四大服务模型：Best-Effort、IntServ、DiffServ、TE；现网主流为 DiffServ。
- DiffServ 五步：分类 → 标记 → 限速/监管 → 队列调度 → 拥塞避免。
- 七级判定链：CPU 发包 > 管理包 > 静态源 MAC > VLAN 优先级 > 802.1p > DSCP > 端口默认优先级；靠前覆盖靠后，不是累加。
- 默认状态：仅 802.1p 用户优先级开启；服务器只打 DSCP 时可能不被采用。
- 802.1p→TC 默认：0/3→TC1；1/2→TC0；4/5→TC2；6/7→TC3。注意 802.1p=0 映射到 TC1 是中兴特有默认值。
- DSCP→TC 默认：0-15→TC0；16-31→TC1；32-47→TC2；48-63→TC3；TC 数字越大优先级越高。
- EF=46 默认进入 TC2；若要求语音严格优先，应显式映射 EF→TC3 并全网验证。
- SP 严格优先、低时延但可能饿死低队列；WFQ/WRR 按权重轮询、更公平但实时性相对弱。
- 队列调度只在端口拥塞时生效；无拥塞时改 SP/WFQ 通常观察不到差异。
max-frame-size默认 1632；具体取值与版本/板卡相关，配置巨型帧前以?确认。- Policing 超速丢弃/降级；Shaping 缓存平滑；流控反压发 PAUSE；三者不能混为一谈。
- 端到端设计包含信任边界、逐跳映射、拥塞点调度、限速/整形、网管与控制平面保护。
- 优先保障对象：路由协议、BPDU/OAM、网管、语音/实时视频；但不能允许高优先级流量无限占用带宽。
- 验证顺序：业务规划 → 标记抓包 → 判定链/映射 → 队列统计 → 拥塞压力测试 → 回退。
7_9_2 本板块自检清单
【案例故事】① DSCP 被默认信任策略忽略
某园区网新增语音质量投诉，现场把两台 IP 电话注册到同一台接入交换机。电话机由 IT 部门统一配置，SIP 服务器明确要求语音媒体使用 DSCP EF=46。我在接入口抓包，确实能看到 IP 头 DSCP=46，但语音高峰时仍有明显卡顿。
我先检查出方向：
show qos queue-schedule已经是 sp；再检查映射，发现工程组之前只按 802.1p 规划过。show qos priority-map ip-priority显示 46 仍在默认 TC2，而且接入口收到的是 Untagged PC 流量与 Tagged 语音混合，部分路径上 802.1p 并非 EF 对应的 CoS。我没有立即全局改写，而是先在测试口执行：
zte(cfg)#set qos priority-map ip-priority 46 traffic-class 3 zte(cfg)#set qos priority-map ip-priority 34 traffic-class 2 zte#show qos priority-map ip-priority随后在汇聚上联制造可控拥塞，同时抓取电话流与办公下载流。确认 TC3 计数随语音流增长后，语音丢包从高峰时约 3% 降到可忽略范围。复盘结论是：默认更关注 802.1p，服务器/终端只打 DSCP 时，必须把 DSCP→TC 显式纳入规划，不能只看报文有没有标记。该局点后续统一采用“DSCP 为主、接入重标记 CoS 为辅”的基线。
【案例故事】② 备份流量被错误放进最高队列
某分支改造后，夜间的异地备份窗口内办公业务几乎不可用。最初运维怀疑上联带宽不足，但监控显示 1GE 上联峰值只有约 60%。我登录汇聚交换机检查 QoS，发现此前为了“优先保证备份完成”，把备份服务器接入端口的默认优先级设为 7，且没有限制备份 VLAN 的标记。
由于调度模式是 SP，TC3 只要还有报文就持续发送；而备份流量是长时间大带宽 TCP，TC0-TC2 在拥塞瞬间得不到充分服务。表象不是“上联跑满”，而是应用请求在小突发时排队，SSH 管理也出现卡顿。确认这一点后，我把备份业务调整到低优先队列并加入限速：
zte(cfg)#set qos priority-map user-priority 1 traffic-class 0 zte(cfg)#set qos priority-map ip-priority 8 traffic-class 0 zte(cfg)#set port 21 bandwidth egress on rate 200000 zte(cfg)#set qos queue-schedule wfq zte#show qos queue-schedule zte#show port 21 qos变更后再次在备份窗口注入办公流量，办公与网管的时延恢复。这里的教训是：SP 只能保护“持续速率受控、对时延敏感”的流量；大带宽备份即使业务重要，也不能长期独占 TC3。若确实需要更快备份，应优先扩容路径或安排低峰期，而不是牺牲网络可控性。
【ZCIE】请把两个案例故事沉淀为本板块的错题本：第一个纠正“有 DSCP 就必然有 QoS”，第二个纠正“重要业务就该放最高队列”。真正的 QoS 能力，是把业务重要性转换为可测量的分类、映射、速率边界和调度规则。
浙公网安备 33010602011771号