DSCP 标记还是运营商 QoS 承诺？两者都不是合同

某些东西被标记，某个队列被配置，然后有人问这套设计到底保证了什么质量。诚实的答案是：你描述的是在边界处对接的两半合同。在你能说出运营商接受的类别及其施加的处理之前，本地配置只是一种意图，而非承诺。两半都重要，任何一半都无法由另一半推断出来。

local match → queue and marking → provider classifier
  → provider treatment → destination

正确的标记会在哪里悄然失效

先按工作负载逐项写下：本地匹配条件、隧道内发生的任何标记、运营商接受的值，以及该值所选择的服务类别。四列信息，而故障通常就藏在第二列和第三列之间。

内层到外层的标记行为是经典问题。加密或隧道路径中的报文带有内层头部（你的分类器能看到）和外层头部（运营商设备能看到），把一个复制到另一个是配置决策，而不是自动属性。只标记内层头部，运营商就会按外层头部分类，通常归为默认类——这就是为什么一个标记正确的流，可能在你这边没有任何一行配置错误的情况下，仍然进入错误的类别。

本地命名的类别也可能形同虚设，因为它的匹配条件在真实报文上从未触发。端口会变，应用会使用多条流，而对一个厂商两个版本前就不再使用的知名端口做匹配，只会得到一个计数器为零的队列，以及一份在运行配置里看起来完美无缺的策略。

要明确决定在哪些位置信任标记。把共享同一隧道的所有流量一并提升，也会把大流量传输和语音通话一起提升；而一个不做校验就接受你标记的运营商，等于给了你伤害自己的方法。如果合同允许网关在交接处重新标记，请把它写进书面，因为两个团队的假设通常正是在这一点上分道扬镳。

调度器实际在分配什么

本地策略有自己的语义，最容易引起误解的是“remaining”这个词。在 IOS XE 调度指南所描述的平台上，bandwidth remaining percent 设定的是超额权重，而不是一个序列中每一类依次取走前一类剩余份额的步骤。未分配的百分比会分散到符合条件的未配置队列上，而不是留给文件中的最后一类。

这个区别很重要，因为顺序式的思维模型给出的预测永远对不上计数器。工程师重排类别想改变结果，看不到任何差别，于是断定平台坏了——而配置从来就不是他们以为的那个意思。

父级整形器是另一个常见的意外。把受控队列整形到可用服务速率之下往往是有意为之，因为它 把拥塞点移到你自己管理的设备上，而不是移到你无法管理的上游队列。因为整形会增加时延就拆掉整形器，可能只是把丢包挪了个位置，而不是消除丢包；开销核算或运营商的限速器也可能让实际速率低于接口所暗示的水平。

计数器告诉你哪一半失败了

在受影响的方向上比较四个数字：提供了多少、类别匹配了多少、入队或丢弃了多少、服务实际交付了多少。把工作负载描述和策略版本与观测记录放在一起，因为没有这些信息的计数器截图是无法复现的。

这几个分支是不同的问题，属于不同的责任方。匹配不到任何流量的本地类别，是你这边的分类缺陷。类别能匹配、能入队、也在丢弃，而运营商报告交付干净——问题出在你自己的调度器或整形器上。本地看起来正确，但丢包出现在交接点之后——问题指向运营商的映射以及合同中测得的边界。这三者没有哪一个能靠修改另外两个来解决，所以这些数字必须放在一起采集。

RFC 2475 把分类与调节视为在行政域内部完成的工作，这正是为什么标记无法端到端地预留队列。IOS XE 调度指南 是上文所述超额权重行为的参考，在把计算出的速率从一个型号搬到另一个型号之前，值得先读一读它的平台对比。

把合同写在一个地方

把本地匹配、信任边界、运营商类别和实测服务水平写进同一份双方签署的文档。这样，百分比的改动才有上下文，质量投诉才有责任人。

改动一个本地百分比，修不好另一个队列的保证；而任何标记方案，都撑不过运营商不认的映射。比较这两半，说清边界，然后才谈数字。