做网络这行的八成都有过这种经历内网一卡领导第一反应是“把谁的带宽限一限”可真到排查环节打开Wireshark一看根本不是带宽不够而是语音、视频、ERP这些关键业务的报文跟大文件下载挤在同一条队列里拥塞时被一起丢掉了。QoS解决的就是这个问题而QoS落地能走通的第一步就是今天重点拆解的这两个动作报文的分类和标记。简单说分类是“认出你是谁”标记是“给你贴上一张所有设备都认的优先级标签”。这篇文章是系列的第2篇会从概念讲起把分类的匹配维度、标记的不同实现方式、完整配置案例和排查经验都过一遍。适合刚接触QoS的网络运维、准备数通认证考试的朋友以及在华为、Cisco、Linux主机上折腾过但总感觉“报文不听话”的老哥们。读完你就能自己动手把一条链路里乱七八糟的流量按业务重要性归好类、打好标。1. 先把概念盘清楚报文的“分类”和“标记”到底做什么1.1 三个容易混淆的概念标识、标记、重标记QoS这个领域名词看着多其实核心就几个动作。但我发现很多人一上来就敲命令敲完发现没效果回头一看问题出在概念上。先分清三件事报文的标识Identification、标记Marking、重标记Remarking。报文本身自带了不少“身份信息”比如IPv4头里的TOS字段、IPv6的Traffic Class、VLAN Tag里的802.1p字段、MPLS头里的EXP字段。这些字段不是为了QoS专门设计的但实践中它们就是天然的标记载体。所谓分类是把报文按规则归到某个业务类别所谓标记则是把类别信息写进报文的某个字段。这样做的目的很直接一台设备在入口处完成复杂匹配后面所有设备只需要读字段值就能快速判断优先级不用每台设备都拆开报文做深度检测。这个“一次识别、全程生效”的思路是整个QoS体系高效运转的前提。这里还要补一个细节标记和重标记不是一回事。标记通常发生在信任边界也就是报文刚进入网络的第一个设备上重标记是中间设备对已经打过标的报文修改优先级。生产环境里重标记要非常克制因为每改一次就意味着前面设备的分类结果被推翻一次链路里的优先级语义就可能乱掉。1.2 一个外卖订单的类比把报文想象成外卖订单。订单上有地址、有商品信息这相当于报文的五元组。外卖平台怎么让骑手知道哪些单要先送光靠订单详情里的说明不够平台会直接给订单打上“加急”“生鲜”“超时赔付”这类标签。骑手一看标签不用再翻商品列表就知道先送哪单。报文也一样。没有标记的报文经过每台设备都要被重新拆开、匹配、判断性能开销大而且每台设备的判断规则未必一致极可能出现“这台设备认为是高优先级下一台设备又当成普通流量”的尴尬。一旦入口统一打标中间设备就只需要做一个字段读取的动作效率高得多。这个类比还能帮我们理解信任边界的概念。外卖标签不能随便让商家自己贴否则人人都标“加急”标签就失去意义了。网络的信任边界也一样如果所有设备都能随意改标优先级语义就会被稀释。所以最佳实践是把打标权限收拢到边缘设备核心设备一律trust收到的标记。1.3 分类标记在整个QoS流程中的位置一个完整的QoS处理链条通常长这样分类Classification→ 标记Marking→ 队列调度Scheduling→ 拥塞管理Congestion Management→ 拥塞避免Congestion Avoidance→ 流量整形Shaping→ 限速Policing分类和标记排在最前面是整个流程的入口动作。后面所有队列、丢包策略、带宽限制依赖的都是这一步产出的结果。这个位置关系至关重要。我排查过很多“明明写了队列策略但流量不受控”的工单回查发现要么是分类规则没匹配上报文压根没进对应队列要么是标记字段在中间某台设备上被悄悄改写了后面设备认不出来。分类不对后面全白搭。所以别小看这一步它是最基础、影响面最大的环节。2. 报文分类的常用匹配维度从五元组到应用识别2.1 最基础的方法基于ACL的五元组匹配先讲最简单的也是绝大多数场景下最先考虑的做法用ACL匹配报文的五元组也就是源IP、目的IP、源端口、目的端口、协议号。这个方法在中小型网络里特别实用华为、Cisco、H3C、深信服这些设备基本都支持配置思路也一致。举个例子想把办公网内部的VoIP流量识别出来可以这样匹配协议是UDP目的端口是5060或RTP动态端口范围源网段是语音终端所在的VLAN。只要ACL规则写得准可靠度非常高。但ACL有一个特别容易踩的坑匹配顺序。ACL默认从上到下逐条匹配一旦报文命中某条规则就停止后续匹配。所以规则摆放的顺序非常讲究一定要把精确匹配的放在前面宽泛匹配的放后面如果ACL里有一条permit ip any any这样的兜底规则那它后面的规则基本就废了。另外ACL本质上是逐条匹配规则条目越多设备CPU消耗越大。大流量场景下ACL分类适合在边缘接入层使用不适合在骨干核心设备上做大量深包匹配。核心设备通常只按标记字段转发具体分类交给边缘设备处理。2.2 高效的方法基于报文头优先级字段分类如果说ACL分类是“看脸认人”那基于优先级字段分类就是“看标签认人”。报文头里现成的优先级字段有这些字段所在位置比特数取值范围典型用途IP优先级IPv4 TOS字段前3位30-7早期QoS按业务优先级划分DSCPIPv4 TOS字段前6位60-63当前主流QoS标记支持AF/EF/CS802.1pVLAN Tag中的PRI30-7二层交换机内传递优先级MPLS EXPMPLS头部30-7MPLS VPN网络内传递优先级IPv6 TCIPv6 Traffic Class60-63IPv6网络的DSCP标记这类匹配方式的优点是效率高设备只需要读取头部字段o(1)的复杂度不用做多层判断。缺点也很明显依赖上游设备已经把标记打好。如果入口没有标记后面设备拿到的都是默认值分类无从谈起。所以实际部署时两类方法往往是配合使用的边缘设备用ACL精细分类并打标中间设备只按标记字段分类入队、调度。这个组合拳打好了整网QoS行为才是确定性的。这里要特别提醒一句DSCP和IP优先级的关系。IP优先级只用了TOS前3位只有8个取值后来需求复杂了协议演进成DSCP用前6位64个取值。两者不是一个东西但很多老文档混着写。配置时先确认设备支持哪个字段。对端老设备如果只认IP优先级DSCP的高三位可以映射过去但低三位信息就丢了。我建议项目开始前先做一张“DSCP到内部队列的映射表”哪怕只是Excel表格也好过配置时拍脑袋。2.3 复杂场景按用户、接口、应用识别分类碰到加密流量、动态端口、应用层协议复杂的情况ACL和字段匹配就不够用了。生产环境里我常用这些维度补充按用户/用户组分类比如访客Wi-Fi用户自动进低优先级队列员工走正常队列按接口/VLAN分类从WAN口进来的流量和LAN口进入的流量做不同处理按时间段分类工作时间限制视频流量非工作时间放开按应用识别分类通过DPI识别出视频会议、P2P下载、云盘同步等具体应用这类分类依赖设备的深度包检测DPI能力对性能要求比较高适合部署在出口防火墙或专门的AC设备上。配置时有一个现实取舍分类粒度越细、DPI规则越多转发时延就越大。我的做法是默认用粗粒度分类保证转发性能只对少数关键应用开精细化识别规则。3. 动手改标签报文标记的几种落地方式3.1 标记动作的本质改写报文头字段标记的本质一句话就能说清改写报文头里的优先级字段。不同厂商的命令大同小异Cisco叫set dscp、set ip precedence华为叫remark dscp、remark 8021pLinux里用iptables -j DSCP或者tc filter。实际标记的动作通常分两类。第一类是标记或重标记DSCP让后续设备按统一的DSCP语义处理。第二类是标记802.1p或MPLS EXP用于在二三层网络里跨设备传递优先级。关键不在于命令怎么敲而在于哪里打标。这个“哪里”在专业上叫信任边界Trust Boundary。全网每台设备如果都按自己的想法改标记优先级就失控了。我见过一个客户接入交换机标记AF41核心交换机又remark成AF31出口防火墙再改成CS6结果业务部门投诉说“为导向的QoS完全没效果”一查全是不同设备互相打架。最佳实践是在接入层入口一次性完成完整分类和标记中间设备全部trust收到的标记不再重标。这样整网的QoS行为是确定性的问题定位也容易得多。3.2 华为设备上的典型配置流分类、流行为、流策略华为设备的标记逻辑很清晰分成三件套流分类traffic classifier、流行为traffic behavior、流策略traffic policy最后把策略应用到接口。我们来看一个典型场景把DSCP为EF的语音流量识别出来准备给它加一个802.1p优先级。traffic classifier voice if-match dscp ef traffic behavior voice-marker remark 8021p 5 traffic policy voice-policy classifier voice behavior voice-marker precedence 1 interface GigabitEthernet0/0/1 traffic-policy voice-policy inbound这段配置做了三件事第一定义一个名为voice的流分类匹配进入接口前DSCP为EF的报文第二定义一个名为voice-marker的流行为把匹配到的报文802.1p优先级重标记为5第三把两者绑定成策略voice-policy应用在接口入方向。配置本身不复杂但有几个必须注意的点if-match的匹配方向是“进入接口前的原始报文头”。如果前一台设备已经改写了DSCP到这台设备上匹配的就是已改过的值规则可能落空。所以部署标记策略前一定要画出报文路径搞清楚每台设备看到的是哪个版本的报文头。入方向和出方向要分清。在入方向打标常用于信任边界在出方向重标记常用于跨信任域时调整优先级。用错了方向策略就不生效。precedence 1的意思是这条策略在多个策略中的优先顺序。同一接口可能绑定多条策略数字越小优先级越高不要忽视这个参数。3.3 Linux主机上的等价实现iptables和tc如果是服务器出口、云主机边缘或者虚拟化环境未必能碰到华为、Cisco设备但Linux主机一样能做分类标记。这也是Troubleshooting时非常实用的手段。最简单的实现是在iptables的mangle表里操作mangle表天生就是干“改报文头”这个活的。举一个例子把来自192.168.1.0/24网段的报文DSCP标记为EFiptables -t mangle -A PREROUTING -s 192.168.1.0/24 -j DSCP --set-dscp-class ef这条命令会在路由决策前改写报文DSCP。它比设备上的ACL灵活因为iptables可以用string模块匹配应用特征、用hashlimit限速、用owner模块按用户或进程匹配几乎能做到任意维度的分类。验证方法也简单抓包直接看TOS字节tcpdump -vvv -i eth0 ip[1] 0xfc ! 0这里有个踩坑提醒iptables的DSCP扩展只对IPv4生效IPv6要用ip6tables。还有顺序问题报文经过NAT后源地址会被改写如果你在POSTROUTING链里匹配的是原始源地址打标就会落空。建议把所有打标动作放在PREROUTING链NAT动作放在POSTROUTING链天然错开。4. 完整实操一张映射表加几行配置完成出口优先级规划4.1 场景设计一家公司的出口流量优先级怎么定假设有这么一家公司出口带宽有限日常有视频会议、SIP语音、ERP业务还有大量员工上网流量。需求很明确语音绝对不能卡ERP绝对不能丢普通上网“能通就行”。网络拓扑是接入交换机 → 核心交换机 → 出口防火墙 → 运营商链路。做方案前我习惯先画映射表。这张表把业务类别、报文特征、标记值、最终行为绑定在一起是整个方案的底座。业务类别识别方式DSCP标记备注语音RTP目的端口范围 16384-32767EF不允许丢包视频会议应用识别如Zoom/SkypeAF41低时延低抖动关键业务ERP目的IP/端口AF31保可用性默认流量其他所有BE尽力而为这张表建议和运营商对端确认一下因为在跨运营商环境中如果两端标记语义不一致到了对端也可能被重写。自己内部网络可以任意定义优先级语义但一旦跨出你的边界就要遵守对方的约定。4.2 配置步骤从接入交换机到出口防火墙第一步在接入交换机入口完成分类与标记。以华为交换机为例我们把语音流量识别出来并标记802.1p优先级同时保持DSCP不变traffic classifier voice if-match dscp ef traffic behavior voice-mark remark 8021p 5 traffic policy edge-in classifier voice behavior voice-mark precedence 1 interface GigabitEthernet0/0/1 traffic-policy edge-in inbound这里为什么只remark 8021p而不改DSCP因为DSCP此时已经是EF语音终端或软交换已经打标保留原值同时给二层标记加上802.1p 5方便接入交换机内部优先转发。如果语音终端不支持打标那就要在匹配条件里加上IP地址或端口并在流行为里补充remark dscp ef把标记一步到位补全。第二步核心交换机上配置“信任标记”和队列调度。这里不要做重标记除非你确定业务语义需要变更interface GigabitEthernet0/0/24 trust dscp再配置接口的队列让EF进入PQ队列AF41和AF31进入WFQ高权重队列BE进入默认队列。第三步出口防火墙按DSCP做限速和调度。防火墙上通常有基于DSCP或优先级的策略比如对EF队列采用低延迟队列并加入拥塞避免保护。这一步主要看防火墙型号华为USG上叫“优先级调度/队列调度”Cisco ASA上有类似QoS策略。配置思路一致不再展开。4.3 验证与效果确认别只看配置成功配置下发后必须验证而且验证要分三层。只看配置commit成功是最低要求不代表策略真的在工作。第一层设备侧看统计。华为设备上查看接口入方向的策略命中数display traffic policy statistics interface GigabitEthernet0/0/1 inbound如果命中数为0说明分类规则有问题要么匹配条件写错要么报文路径不对需要立刻回查。第二层抓包确认标记值。在接入交换机的终端侧抓包确认DSCP字段值等于预期。这里有个细节如果报文经过三层设备可能被重新封装TOS字段会被覆盖抓包时一定要在正确的观测点抓。第三层端到端业务验证。用iperf打流测试带宽限制是否生效用ping对比加策略前后的时延和抖动语音业务做一个真实的呼叫测试。整个流程从0到1的建议是先在测试机上验证确认识别、标记、调度都正常再逐步扩大到全网。别一上来就全量下发万一策略方向错了后果是整个部门网络瘫痪。5. 常见问题与排查实录六个真实场景复盘5.1 问题速查表症状可能原因排查方向报文没按预期进入队列分类规则未匹配ACL顺序问题if-match条件错误查看策略命中统计抓包确认报文特征跨设备后优先级丢失某台设备配置了trust none或不支持对应字段沿报文路径逐跳抓包对比TOS/802.1p值DSCP和IP优先级映射错位老设备只认IP优先级未配置映射关系规划映射表检查跨厂商设备间的映射关系MPLS域内优先级失效未配置EXP字段或EXP被隧道封装覆盖检查PE/CE设备对EXP的处理方式NAT后打标不生效PREROUTING和POSTROUTING匹配顺序错误调整iptables链位置或匹配条件无线终端优先级无效Wi-Fi使用WMM不认802.1p/DSCP在AC/AP上配置WMM优先级映射5.2 踩过的四个坑第一个坑是出方向重标记导致全线失效。有次我在核心交换机出接口重标记了DSCP结果下游防火墙配置了trust none把所有入向报文的优先级都重置了。后来改在接口入方向打标并和防火墙团队确认信任关系问题才解决。教训是标记的方向和信任关系必须和相邻设备团队对齐否则自己这侧再对也是白搭。第二个坑是语音网关和现代DSCP语义的兼容性问题。某厂商老式语音网关发出的报文只设置IP优先级5也就是TOS值为0xA0不会设置完整的DSCP EF二进制101110字节值0xB8。我按if-match dscp ef配置命中数一直是0语音流量完全没进PQ队列。后来改成按IP优先级匹配或按端口匹配才解决。第三个坑是无线环境的优先级完全不一样。无线网络里报文的优先级传递靠的是WMMWi-Fi Multimedia而不是2层802.1p或3层DSCP。在交换机上给无线用户的报文打上802.1p优先级到了AP和无线控制器这一层就不认了。无线场景必须单独在无线控制器上配置WMM队列和DSCP映射和有线侧的思路完全两套。第四个坑倒不是配置问题而是抓包工具显示方式。Wireshark在解析时会“人性化”地显示DSCP比如显示DSCP EF很多新手就以为TOS字段值必须是0xB8结果看到0xB8反而怀疑抓错了包Wireshark会把整个TOS字节显示成0xb8看起来像0xB8写文档的时候容易搞混。实际上EF的DSCP值就是46对应字节值0xB8显示成“DSCP: EF”反而对。抓包时别被数值吓到先看解析后的DSCP字段。这篇先写到这。从我自己的体会来说QoS做得好的网络从来不是靠某一条命令多精妙而是靠前面那张映射表、每个接口的信任关系、以及到底在哪里打标这几点想得足够清楚。整网QoS是个协同工程分类标记只是第一步但也是最重要的一步——分不好类、打不好标后面队列调度做得再精细流量也不会按你的意愿走。最后分享一个已经帮我躲过好几次事故的小技巧做完任何QoS改动先在一台测试机上抓包对比确认DSCP或802.1p已经变成预期值再批量下发到全网。这个动作只要几十秒但能避免绝大多数线上事故。下一篇如果再写我打算聊聊队列调度里PQ、WFQ、WRR之间的取舍以及拥塞发生时这几类队列在华为和Cisco设备上的行为差异。