QoS这事儿很多人第一步就栽了——不是不会配排队和调度而是根本没把报文分类和标记当回事。流量从接入层进来的时候如果不先分门别类打上标记后面队列优先级做得再精细设备也只知道它们都是普通流量拥塞一来照样全部丢给你看。上一篇把QoS的整体框架过了一遍这篇专门往下钻讲“简单分类和标记”这个最关键的落地动作。这篇文章适合三类人刚接触QoS、想把基础配置弄明白的新手配了QoS但实际没效果、正在排查的运维以及需要对现有网络做流量梳理、但不想把模型搞太复杂的人。我不打算堆一堆厂商命令完事而是把背后的思路讲清楚——为什么这么配、字段怎么选、验证怎么做、坑在哪。文中的配置示例以常见的类IOS风格命令行给出同时会对照另一种主流风格方便你迁移到自己手头的设备上。1. 先想清楚分类和标记是两个动作别混着配1.1 分类是“认人”标记是“发号牌”很多教程把分类和标记写在一起好像它们是一件事。实际使用中这是两个独立的动作必须分开理解。分类做的事情是设备收到报文后根据规则判断“你是谁”。这个判断结果可以在设备本地直接用比如当前接口拥塞时判断为语音的报文先进队列。标记做的事情则是把判断结果“写”到报文头上让路径上的下一台设备不用再做复杂的判断看一眼标记就知道该怎么对待这个报文。我用一个生活化的类比分类像小区门口的保安认脸标记相当于进小区时给你发一张临时通行证其他门岗看到这张证就知道放进哪栋楼不用重新盘问一遍。你要是分不清这两个动作配置时就会出问题。我见过不少配置把DSCP重写规则直接挂在接口下看起来也生效了但一旦要跨设备传递就全乱了——因为有的设备只做了本地分类没有写标记下一跳设备根本不知道这个流量很重要。所以动手之前先画一条链路标清楚哪台设备负责认人、哪台设备负责发号牌、哪台设备只认号牌不废话。1.2 为什么“简单”分类是正经需求不是偷懒现在一搜QoS满屏都是复杂流分类、多级队列、HQoS、层次化QoS新手很容易被吓退。但根据我做过的项目大部分企业网络场景根本不需要那么庞杂的体系只需要做到把三五类关键流量认出来打上标让拥塞发生时设备知道先转发谁、丢包时先丢谁。简单分类的定义不是“少写几条命令”而是规则维度统一、数量克制、行为可预期。我见过一张接入网上配了十几条分类规则从源IP、目的端口、协议号到报文长度全用上了结果网络一忙起来设备处理分类的CPU直接飙升新流量建立连接都变慢。后来我帮他把规则砍到五条以内效果反而更好排障也容易——一条规则命中没命中打一条命令就能看统计不需要在一堆规则里猜。简单分类的另一个好处是可解释性。网络出了问题你跟领导汇报“因为语音流量走了AF41队列而视频流量被分到了BE”比说“有一堆复杂策略互相作用导致异常”可信得多。QoS是网络里少数需要“讲道理”的配置规则越简单道理越站得住。2. 报文里能“打记号”的位置字段盘点与映射关系2.1 从三层到二层处处可以写字要对报文做标记先得知道报文头上哪些字段可以写、写了能传到多远。很多人只知道DSCP其实可用的位置不少我整理了一张表字段所在位置位宽取值范围典型用途能跨设备传递到哪IP优先级IP PrecedenceIP头ToS字段前3bit3bit0~7老设备使用的优先级标记三层网络全程DSCPIP头ToS字段DS字段后6bit6bit0~63当前最主流的QoS标记三层网络全程802.1pPCP以太网VLAN Tag中3bit0~7二层VLAN内的优先级标记二层域内MPLS EXPMPLS标签头3bit0~7运营商/MPLS网络内标记MPLS域内本地队列号仅存在设备内部取决于设备自定义调度优先级映射不出设备这表里你只要抓住DSCP和802.1p就已经解决90%的场景。DSCP是三层的标记跨路由器转发时还能保留802.1p是二层的标记在交换机VLAN内有效。如果报文要穿过三层网络依赖的是DSCP如果在接入层到汇聚层的二层环境里做策略802.1p更直接。2.2 同一个字节里的继承关系最容易忽略这里有个特别容易踩坑的细节IP优先级和DSCP在IP头里是同一个字节。ToS字段一共8bit老标准里前3bit是IP优先级后5bit是其他标志新的DS字段定义里前6bit是DSCP后2bit是ECN。也就是说修改DSCP值会同步影响老设备读到的IP优先级。比如你把DSCP改成EF46二进制是101110前3bit是101正好是十进制的5老设备会认为这是IP优先级5。这个继承关系通常不是问题但如果你遇到老设备只看IP优先级要知道该怎么对应着配。二层和三层的标记也可以有映射关系。不少设备支持配置DSCP到802.1p的映射表比如DSCP EF映射到802.1p 5DSCP AF41映射到802.1p 4。这样三层打好的标记进到二层域内时能被交换机正确识别。实际配置时先确认映射表是不是默认合理别指望着设备自动帮你换算。2.3 抓包时怎么看这些字段做QoS配置抓包验证是逃不掉的。用Wireshark打开抓到的报文找IP头里的“Differentiated Services Field”就能看到DSCP值有VLAN Tag的报文在802.1Q头里能看到Priority就是802.1p值。这里我不妨多说一句做车载总线报文解析的同行对这套应该不陌生。CAN报文看PGN、PDU格式LIN诊断报文看ID和数据段CANape读MF4文件时盯着字节位看信号值——网络报文分析也是一样的道理关键是知道哪个字节位是哪个字段。你在Wireshark里把DSCP列显示出来一条过滤命令就能筛选出所有打了特定标记的报文。这一点后面验证章节会展开讲。3. 三类规则就够用的“简单分类”配置法3.1 按五元组分类基本功但最容易出错五元组指的是源IP、目的IP、协议号、源端口、目的端口。这是最经典、最通用、性能最好的分类方式。只要你知道关键流量的IP或端口特征就能用访问控制列表把它匹配出来。配置思路上先定义一个ACL再在class-map里引用# 定义ACL匹配内网到ERP服务器的流量 ip access-list extended APP-ERP permit tcp 192.168.10.0 0.0.0.255 host 192.168.100.20 eq 443 ! # 定义class-map引用ACL class-map match-all CM-CRITICAL-APP match access-group name APP-ERP这里有个细节很多人忽略match-all和match-any的区别。match-all要求所有条件都满足才算命中match-any只要有一条满足就算命中。如果你只在一个class-map里写了一条匹配规则两者等价一旦写多条语义就完全不同了。我的习惯是能少写就少写一个class-map里放一条明确定义的ACL比堆一堆match条件好维护得多。五元组分类适合网络拓扑清晰、关键业务IP和端口固定的场景。缺点也很明显——如果应用用了动态端口或者流量源IP非常分散规则就会变得臃肿这时得考虑App识别。3.2 按应用特征识别省心但要留意性能开销动态端口协议是ACL的克星。视频会议、P2P下载、部分云办公软件端口经常变你没法预先把所有端口写进ACL。这时候需要设备做应用层识别也就是通俗说的DPI或者NBAR。配置上通常是启用应用识别模板然后在class-map里直接引用应用名# 启用应用识别并定义分类规则 class-map match-any CM-VIDEO match protocol video-conference match protocol webex应用识别的优势是识别粒度细能认出具体是哪个应用不太受端口变化影响。但代价是设备需要把报文拆到应用层做检测CPU和内存开销明显高于ACL匹配。在低端交换机或者老旧的汇聚设备上大规模启用它可能会适得其反。我的建议是只在信任边界设备上启用应用识别下游设备只根据DSCP做调度不要再做深度检测。原因很简单深度检测只需要做一次标记打好之后下游设备看标记就够了没必要每一跳都重新拆包认一遍。3.3 按位置/接口/VLAN分类物理隔离最稳定有些场景其实不需要复杂的报文匹配——流量在哪个接口进来、属于哪个VLAN本身就能说明身份。比如视频会议终端单独接在一个VLAN里那从这个VLAN进来的流量直接打上视频的标记就行根本不用看IP端口。这也是我最推荐的“简单分类”方式之一能用物理身份解决的就别用报文特征去猜。# 将VLAN 100内的所有流量分类为视频 class-map match-all CM-VIDEO-VLAN match vlan 100 ! policy-map PM-MARK class CM-VIDEO-VLAN set dscp af41 ! interface GigabitEthernet0/24 service-policy input PM-MARK这样做的好处是规则极少几乎不消耗额外CPU排查也容易——看到这个接口进来的流量标记不对第一反应就是查接口配置。缺点是需要网络规划和物理接入配合如果全网乱接乱通这种方法就失效了。所以做这种分类前先确认接入层到汇聚层的VLAN划分是干净的。4. 标记动作三板斧从分类结果到报文重写4.1 三件套结构class-map、policy-map、service-policy分类和标记组合起来常规配置逃不开三个层级class-map定义分类规则policy-map定义动作包括标记、限速、入队等service-policy把策略挂到接口、VLAN或全局。我经常跟人打比方class-map是“人事档案”policy-map是“岗位说明书”service-policy是“把人派到岗位上”。没有service-policy前面定义得再完整也不会生效。一个标准的标记配置长这样# 第一步分类 class-map match-all CM-VOICE match dscp ef ! class-map match-all CM-VIDEO match dscp af41 ! # 第二步策略为每一类流量定义动作 policy-map PM-MARK class CM-VOICE set dscp ef class CM-VIDEO set dscp af41 class class-default set dscp default ! # 第三步在接口应用 interface GigabitEthernet0/1 service-policy input PM-MARK注意这里service-policy input和service-policy output的区别。标记动作通常在入方向做因为报文一进来就得决定它的“身份”后续的队列和丢弃策略才能按标记执行。调度类动作通常在出方向做队列是出口才有的概念。方向搞反是最常见的配置错误后面排障章节我会展开说。4.2 DSCP值怎么选从EF到AF的分工逻辑很多人在标记这一步纠结最多的是我该打多少DSCP一共64个值但实际你只需要记住几个档位DSCP值名称适用场景说明46EFVoIP语音、实时控制低时延低丢失中间一跳都不要排队48CS6路由协议、网络控制通常用于协议报文用户流量别占用34AF41视频会议、实时视频可降级但不太想丢26AF31重要业务比普通流量优先18AF21一般业务中等优先级8CS1Scavenger垃圾流量有带宽就给拥塞先丢0BE默认尽力而为大多数流量的归属挑选原则很简单语音用EF视频用AF41关键业务用AF31/21其余全部放BE。没必要搞十几个DSCP值三四个档位足够覆盖90%的办公网场景。AF值内部还有门道。AF41和AF43的区别在于丢弃优先级——AF4x里x越大拥塞时越容易被丢。比如视频帧里关键帧打AF41非关键帧可以打AF43这样拥塞时设备会优先丢非关键帧画质受影响比乱丢要小。这个控制在不需要深入做的网络里可以不区分知道有这层逻辑就行。4.3 信任边界放在哪比配命令更重要标记动作做在哪台设备这台设备就是信任边界。一个常见的设计是接入层交换机面向终端接口进方向做分类和标记汇聚层和核心层完全信任DSCP值不再做重写只按DSCP调度。为什么不每台设备都重写一遍因为重写意味着每一跳都要做分类不仅浪费性能还可能导致策略叠加错乱。A设备把某个流量标成EFB设备又觉得EF不对改成AF41C设备再改一次最后谁都不知道这个流量实际是什么待遇。链路越长这种“改来改去”的后果越不可控。所以我的建议是明确一条信任链只有最靠近终端的设备做标记之后所有设备全部信任。如果某段链路上游是运营商或第三方网络那在接入运营商的路由器上重新标记一次是合理的——因为运营商可能会重写DSCP你的标记在出网那一刻就失效了。另外注意有些设备默认会对本地产生的报文做特殊处理比如Ping、路由协议报文可能直接就进了高优先级队列。你可以在设备上确认这些协议报文被自动标记成了CS6或CS7别把这当作故障这是保护协议稳定性的合理设计。4.4 两种主流配置风格看懂一个就能迁移不同厂商的命令风格差异常常是新手卡住的地方。我列一下两类常见风格的对照。一类是类IOS风格的class-map/policy-map上文已经写过。另一类是把这三个层级叫做“流分类/流行为/流策略”# 流分类相当于 class-map traffic classifier CM-VOICE operator and if-match dscp ef # # 流行为相当于 class 下的动作 traffic behavior BM-MARK remark dscp ef # # 流策略相当于 policy-map traffic policy TP-MARK classifier CM-VOICE behavior BM-MARK # # 应用到接口 interface GigabitEthernet0/1 traffic-policy TP-MARK inbound看明白了吗名字不同骨架一样。你在任何一台设备上配置QoS先找这三个概念分类规则、动作策略、接口应用位置。找到它们命令只是语法问题逻辑完全一致。5. 配完别信配置抓包打流怎么验证出问题怎么排5.1 第一件事抓包确认标记真的写上去了配置完成不等于生效。我最常做的第一件验证是在标记设备的出口抓包看抓到的报文的DSCP值是否变成预期值。注意抓包位置必须在标记动作发生位置的后面——比如你在接口入方向做了标记那就在这台设备对应的出接口抓包或者在下一跳设备入口抓包才能看到标记后的报文。操作方法不复杂找一台能镜像流量的交换机口或者直接用Wireshark在测试主机上抓包过滤某个特定流量然后看IP头的DSCP字段有没有变。# Wireshark过滤DSCP46的报文 ip.dsfield.dscp 46如果抓到的报文DSCP还是0问题就清楚了要么分类规则没匹配上要么标记动作没生效。这时候要看设备的策略命中统计# 查看策略统计 show policy-map interface GigabitEthernet0/1重点看每个class的packet计数。如果计数一直是0说明根本没有流量命中这个分类规则问题在分类不在标记。这一步是定位问题最快的方式。5.2 用打流制造拥塞确认调度真的按标记工作只验证标记还不够——标记只是手段最终目的是让拥塞发生时关键流量先走。所以第二步是制造拥塞观察调度效果。我的做法是准备一台打流工具生成三路流量一路模拟语音UDP小包、一路模拟视频UDP大包、一路模拟下载TCP大流量。把总带宽注水到超过接口带宽人为制造拥塞然后观察语音流的时延和抖动有没有保持在合理范围视频流有没有比下载流获得更多带宽或更低的丢包率下载流是否被优先丢弃或压制这里说一个容易误判的点QoS调度不是按“绝对带宽”工作而是看相对优先级和队列权重。如果拥塞不严重所有流量都不丢包你根本看不出QoS的作用。只有把拥塞做出来才能观察到差异。所以打流时要把流量压得比接口带宽明显高出一截否则验证没有意义。还有一个提醒别在核心生产链路直接压测。找测试接口、隔离的VLAN或者维护窗口来做打流工具本身也会产生突发流量处理不好容易把正常业务带崩。5.3 “配了没效果”的排查链路按顺序查这四个点我接手过不少“QoS配了但没用”的工单排查链路基本是固定的按顺序查效率最高排查点可能原因检查方式方向对不对标记策略挂在了错误的接口方向确认策略是input还是output标记通常在入方向调度在出方向信任边界在哪上游设备把DSCP重写成了0在链路两头分别抓包对比DSCP值分类规则是否命中ACL或class-map匹配条件和实际流量不符查看策略命中计数确认不是0设备能力硬件芯片不支持某些匹配项查设备规格说明书或咨询厂家这里分享一个真实Case。有个客户说语音不优先电话一多音质就断断续续。我到现场先看了配置语音VLAN、DSCP标记、队列调度看着都正常。然后在接入交换机进出口分别抓包发现了一个现象语音话机发出的报文DSCP确实是EF但经过接入交换机之后DSCP变成了0。问题根源在接入交换机面向话机接口的信任配置没开。设备默认对所有进接口的报文执行“信任并重写”策略把DSCP重写成了默认值。也就是说话机把标记打好了但第一跳设备就把它洗掉了。后面汇聚层核心层配置得再漂亮看到的都是普通流量。这个Case说明一个道理QoS链路就像接力赛每一棒都不能掉。分类、标记、信任、调度环环相扣任何一环断掉前面做得再好也没用。排查时从链路源头一段段抓包是最笨但最有效的方法。6. 让简单方案长期不翻车的几个习惯6.1 标记档位控制在三到四个我做过不少网络的QoS设计反复验证下来一张网里DSCP标记档位超过五个后面基本就乱套了。档位一多大家记不住每个值代表什么待遇后续加需求时就东加一个西加一个最后没几个人说得清这套QoS到底怎么运作的。我的建议是全网统一一个标记规范比如EF给语音和控制AF41给视频AF31给关键业务剩下全部BE。这四个档位写进文档所有设备按这个标准执行。新增业务要加档次时先问一句它真的不能归到已有档位里吗6.2 信任边界写进文档避免后人乱改QoS配置最大的风险不是配置本身而是后续变更。今天这个同事说视频卡在某台设备上把DSCP重写了一遍明天那个同事说下载慢又把某段链路的信任关了。几次变更下来策略链就乱了。所以做完配置后我习惯把“信任边界在哪台设备的哪个接口”写清楚画一张简单的示意标注哪些设备只信任不重写、哪些接口做标记、哪些方向是入方向。这张示意比一堆命令行有价值得多——因为配置可以重敲但设计意图丢失了很难还原。6.3 变更前后都留一份抓包基线这是我个人习惯也推荐所有人养成任何QoS变更前先对关键流量抓一份包存档标清楚DSCP、时延、丢包率变更完成后抓第二份对比差异。这个习惯帮我省过无数次返工。有一次调整汇聚设备的调度权重后用户抱怨视频更卡了。对比变更前后的抓包发现问题不在调度参数而是变更时不小心把接口的service-policy方向从input改成了output导致标记动作根本没执行。如果没有基线包这个问题可能要排查一整天。这和你们做报文解析的同事改完协议栈一定要回读报文确认是一个道理——数据不会骗人配置可能骗你。