做网络这一行只要碰过稍微复杂一点的环境就绕不开QoS。上篇理清了QoS的整体框架和几个关键概念这篇咱们把“报文分类和标记”这一步单独拎出来结合我实际调试过的场景把配置思路、命令细节和坑位一次说透。QoS里的分类和标记看着简单但很多人栽跟头不是栽在原理上而是栽在“不知道该在哪个接口、哪个方向、匹配什么字段”这些看似琐碎的地方。先说清楚一个容易被绕晕的前提分类和标记是两件事但通常一起做。分类是“认人”标记是“贴标签”。你要先决定哪类流量进哪个队列、享受什么待遇然后把这个“待遇等级”写进报文里让后面的设备不用重新认人直接看标签就行。这篇博文的内容适合刚接触QoS的网络工程师也适合那些配置过但总感觉“策略没生效”的兄弟——大概率就是分类没做好或者标签被打错了地方。1. 为什么一定要做分类和标记1.1 没有标记的QoS是没有灵魂的很多人刚接触QoS时会有个误区以为在接口上配个队列调度就够了。比如在出接口配了PQ优先队列结果发现语音还是卡关键业务还是慢。为什么因为设备根本不知道哪个报文是语音、哪个是视频、哪个是普通下载。没有分类队列调度就是个瞎子乱打。我在一次园区网优化中碰到过这种情况客户说视频会议卡我上去看配置发现核心交换机出接口确实配了PQ但队列里塞的全是P2P下载流量视频会议流量被分到了默认队列跟大文件传输抢带宽。这就是典型的“只做了调度没做分类”。所以QoS的第一步永远是先把流量认出来再决定怎么对待它。1.2 端到端的标签传递分类和标记的真正价值体现在端到端的策略联动上。你可以这样理解接入层交换机负责认人贴标签汇聚层根据标签做带宽保证核心层根据标签做拥塞避免出口路由器根据标签做流量整形。每一层不用重新做深度报文检测只看标签就知道怎么处理。这个思路在企业网里特别实用。比如接入交换机下联口接了一台IP话机你可以把话机出来的报文统一标记为EF加速转发把PC流量标记为AF保证转发或BE尽力而为。到了核心层看到EF就知道这是语音直接放进最高优先级队列。如果中间有设备把标签重写了整个链路就会出问题——这个后面讲信任边界的时候再细说。2. 标记字段与DSCP值的换算关系2.1 二层标记和三层标记做标记之前得先搞清楚往哪标。二层有802.1p优先级藏在VLAN Tag的3个比特里范围是0到7。三层有IP优先级和DSCPIP头里TOS字段那8个比特前3位是IP优先级后5位实际上是高6位有效是DSCP。这里我提一句很多初学者容易把802.1p和DSCP搞混。802.1p只能用在带VLAN Tag的报文上如果接口是Access口报文没打VLAN Tag那802.1p实际上是没有承载条件的。而DSCP存在于IP头里只要IP报文就有跨三层也能带着走。所以我的习惯是只要报文能带DSCP优先标DSCP标签传递范围更广语义也更丰富。有些场景两者都要配。比如交换机之间是Trunk口你可以让设备根据DSCP自动映射到802.1p这样二层设备不用解析三层也能处理优先级。但要注意映射表是可以自己调的默认的映射未必合理——后面我会细说。2.2 DSCP PHB和EF/AF/CS的来龙去脉DSCP有6个比特理论上64个值但实际用的就是几个固定语义的PHB逐跳行为。简单记EF加速转发对应二进制101110十进制46。语音流量的默认选择延迟抖动最小。AF类保证转发分4个等级AF1x到AF4x每个等级有3个丢弃优先级。AF41的二进制是100010十进制是34。一般视频、关键业务数据用AF。CS类兼容传统IP优先级CS3对应旧的IP优先级3实际就是把这3位搬过来用低3位补0。BE尽力而为DSCP为0默认值。很多人记不住DSCP值我教你们一个土办法先把CS类的值记死CS18CS216CS324CS432CS540CS648CS756然后EF就是CS5加6也就是46。AF类记前两组数字AF41是34CS4加2AF31是26CS3加2依此类推。DSCP值写错是配置里最常见的问题。我见过有人把EF写成了45结果整个语音队列认不出流量策略直接失效。这种问题不仔细查配置根本发现不了所以大家在敲命令的时候一定不要凭感觉写值要么用名字比如remark dscp ef要么对着表查清楚。2.3 IP优先级与DSCP的映射演进老的设备上只有IP优先级3个比特最多8个等级。后来觉得粒度太粗才扩展成DSCP。现在不少产品配置里还保留着“IP优先级”这个字段但内部基本都会映射到DSCP的前3位。这里有一个配置上的细节华为设备上如果你用remark ip-precedence命令它只改IP优先级那3位DSCP后3位会清零如果只想改DSCP就要用remark dscp。在思科设备上也有类似区别。所以标记的时候要想清楚你是打算只改前半段还是整个DSCP字段不要配了ip-precedence以为就改了DSCP结果后面基于DSCP匹配的策略全部失效。3. 用MQC实现报文分类与标记3.1 MQC三步法分类器、行为、策略MQCModular QoS Command-Line是现在主流的QoS配置方式基本逻辑就是三步流分类traffic classifier定义“什么样的报文”流行为traffic behavior定义“对这些报文做什么”流策略traffic policy把分类和行为绑定然后应用到接口这个模型很直观像写程序一样if条件then动作。它的好处是分类和行为解耦同一个分类可以复用不同行为同一个行为也可以被多个分类引用。配置规模一大复用性优势就很明显了。3.2 分类器的匹配字段选择流分类支持按很多字段匹配ACL、DSCP、802.1p、MAC、VLAN、协议等。配置时先判断你的网络环境里哪个字段最靠谱、最稳定。如果这台设备是网络的边缘收到的报文DSCP可能是乱的比如PC发出来的报文DSCP基本是0有些特殊应用会自己改这时候你不能直接按DSCP分类而应该按IP五元组、VLAN、甚至MAC来分类。比如识别语音就匹配IP话机的MAC或特定的源IP网段识别视频会议就匹配会议服务器的地址和端口。如果是核心设备下面的接入层已经做过标记了那就可以放心按DSCP分类。这种分层思路既能减轻性能压力又能保证端到端的策略一致性。华为设备上有个if-match的细节值得注意默认情况下if-match多个条件在同一分类器里是“与”的关系也就是要同时满足。如果你想让某个分类器匹配“A或者B”要么建两个分类器要么用if-match里支持or语义的变种不同厂商不一样。我通常的做法是在一个分类器里只写一个核心匹配条件逻辑简单排查也容易。3.3 一个完整的分类标记配置示例拿一个典型场景来说公司网络里有语音、视频会议和普通上网三种流量。接入交换机连接PC和IP话机要求在接入层完成标记语音标EF视频会议流量标AF41其余保持BE。话机一般有PC透传口可以在交换机接口上区分话机流量的特征。按MAC匹配话机是最稳的方式因为IP可能变MAC基本不变。配置演示如下华为VRP风格# 定义流分类匹配话机的MAC traffic classifier voice if-match mac 00e0-fc12-3456 # 定义流行为重标记DSCP为EF traffic behavior voice_mark remark dscp ef # 定义流分类匹配视频会议网段 traffic classifier video if-match acl 3001 # 定义流行为重标记DSCP为AF41 traffic behavior video_mark remark dscp af41 # 定义流策略并关联 traffic policy qos_in classifier voice behavior voice_mark classifier video behavior video_markACL部分acl number 3001 rule 5 permit ip source 192.168.20.0 0.0.0.255接口应用interface GigabitEthernet0/0/1 traffic-policy qos_in inbound注意traffic-policy应用接口时要分清方向。一般“标记”动作做在入方向“调度”做在出方向。上例中交换机收到PC和话机发来的报文第一时间就打上标记这样报文带着标记进入网络核心后续设备直接按标记处理。3.4 接口、方向和应用的坑这是我配置QoS以来踩得最深的一个坑策略应用的方向搞反了。很多人配了流策略测试一看没生效第一反应是分类器写得不对查了半天发现是方向弄错了。标记类动作remark通常应该做在inbound因为你要在流量刚进门的时候就动手队列调度、拥塞管理通常做在outbound因为出接口才是拥塞发生的地方。如果你把标记策略放在outbound那报文都已经在设备内部处理完了标记意义就大打折扣了除非你是在边缘出口给所有出去的报文统一打标。还有一个隐蔽的坑接口下应用策略时有的设备要求接口是物理接口或子接口不支持下发到VLANIF这样的三层接口有的则正好相反。配置前一定先查文档确认一下设备支持情况否则配置能敲进去但就是不生效。4. 信任边界与重标记策略4.1 边界在哪信任就停在哪“信任边界”这个概念是QoS里很容易被忽略的。简单说就是从哪个设备开始你相信报文里自带的优先级字段是可信的。PC发出来的报文DSCP是0但如果PC上的应用自己改了DSCP呢有些软件会故意给自己打高优先级这可能就是网络里某些流量莫名被“优待”的根源。我的建议是把信任边界画在网络边缘也就是接入交换机或终端接入路由器上。边界以内靠近用户的设备不信任任何自带的优先级标记统一按照你的分类规则重新标记边界以外离开边缘进入核心信任已经做好的标记。这样可以避免用户私自改优先级来抢占带宽。4.2 接入层重标记的标准动作还是用上面的例子。接入交换机面对PC和话机PC发来的报文DSCP可能是0也可能是某软件改过的值。这时候你就要在入方向先把流量全重置为一个标准基线再按业务类型往上标。如果你用的是华为设备接口上默认信任端口的优先级但你可以用命令调整信任模式interface GigabitEthernet0/0/1 trust dscp // 信任报文的DSCP trust 8021p // 信任报文的802.1p常用于Trunk口 trust upstream // 信任上游设备的标记在实际项目中我更倾向于“全部重标”的简单策略所有流量进来先按业务类型分类重新打上确定的DSCP值。这比小心翼翼地维护信任关系要稳妥得多排查问题也容易——每个设备看到的DSCP都是标准值不存在漂移。4.3 中间设备的标记覆盖问题有一种恶心的情况流量过了几跳之后DSCP莫名其妙变了。常见原因有三个。第一某些中间设备默认会重写优先级。比如部分交换机接口默认不信任DSCP会把报文的DSCP重置为0或者替换成端口优先级。解决办法是在每跳设备上都检查并显式配置信任或重标记。第二隧道封装。GRE、VXLAN、IPSec这些隧道会在外层加一个新IP头设备默认看外层IP头的DSCP内层的DSCP不一定透传或映射过来。这就是为什么很多人在隧道场景里QoS死活不生效因为你在内层打的标签到了隧道出口已经被外层标签“覆盖”了。第三无线网络里AC和AP之间的标记也可能不一致。无线报文在空口和隧道口的优先级映射逻辑跟有线不完全一样配置无线QoS时尤其要小心我做过几次无线语音优化DSCP到了AP就被清零的情况太常见了。5. 常见问题与排查技巧实录5.1 策略配了但就是不生效这是QoS排错里最常见的问题我整理了一个排查顺序只要按这个顺序过一遍大部分问题能水落石出。查接口应用display traffic-policy applied-record确认策略是否正确下发到了目标接口和方向。查流分类命中情况display traffic classifier statistics看分类器有没有命中计数。如果命中计数为0说明分类条件太严或匹配字段不对。查报文实际DSCP值在接口上抓包或者用设备的debug/QOS统计看看报文进设备时和出设备时的DSCP值到底是什么。我遇到过一个典型案例核心交换机上明明配了“匹配DSCP EF放入PQ”的策略但语音流量还是不在PQ里。查了半天发现接入交换机Trunk口默认没透传802.1p优先级而核心的流分类偏偏匹配的是802.1p。两边鸡同鸭讲配置都合法就是合不到一块。所以排查时一定要确认“匹配字段”和“实际报文携带的字段”是不是同一个。5.2 ACL写错导致分类失效用ACL做流分类匹配时有个特别容易出错的地方ACL规则里的动作与QoS分类的关联。很多设备上流分类绑定ACL时只关心ACL里的匹配条件不在乎ACL是permit还是deny。但有些设备上deny的ACL规则会导致该分类器匹配不到流量或者刚好相反。我的习惯是给流分类用的ACL全部写permit只把它当匹配模板用不赋予它过滤语义。这让逻辑清晰很多少踩很多坑。另外注意ACL里rule编号的前后顺序。设备匹配ACL规则是从编号小到大的顺序匹配一旦命中就停止。所以如果前面有一条rule 5 permit ip这种全量匹配规则后面的rule 10根本不会被执行。写ACL时一定要把精确匹配放前面宽匹配放后面或者干脆每条规则分开写避免互相干扰。5.3 端口信任和输入策略的优先级华为设备上有个细节接口上同时配置了trust dscp和traffic-policy ... inbound时如果流行为里做了remark dscp那报文最终以remark结果为准如果流行为里没有remark dscp报文保持原DSCP值或按信任模式保留。这是很多人会误解的地方——以为配置了trust dscp就会强制保留DSCP不变。其实trust dscp只是说“入口信任并保留报文的DSCP值”但如果你在同一接口的inbound策略里显式改掉了DSCP那改写的优先级更高。理解这个逻辑后你在做边缘重标记的时候就不用担心“trust会不会把标记覆盖掉”。5.4 一个排查用的模板命令脚本做QoS排错我习惯把这些命令做成一个模板每次直接复制粘贴# 查看流策略应用情况 display traffic-policy applied-record # 查看全局所有流分类的统计 display traffic classifier statistics # 查看指定接口的QoS配置 display qos configuration interface GigabitEthernet0/0/1 # 查看报文的DSCP值抓包或debug debugging ip packet acl 3001 terminal debugging记住排QoS问题永远先从“报文实际值”入手再看配置。你别在那猜半天抓个包看看DSCP是多少一切谜底都揭开了。6. 分类标记之外还要想什么6.1 分类标记只是QoS长征的第一步文章开头说了分类和标记解决的是“认出谁是谁”的问题。但认出之后真正让语音不卡、视频不花屏的还得靠后面的队列调度、拥塞管理、流量整形这些动作。你标记得再好如果出接口没有对应的队列配置那EF和BE的待遇其实没区别。所以我的建议是做QoS方案时先从整体规划再从边缘往核心逐层落实。先定义清楚每个业务类别的DSCP值再画一条端到端的路径确认每台设备的入方向和出方向分别做什么动作。分类标记定下来之后再动手配队列和调度这样层次分明后期排错也轻松。6.2 简单场景就做简单事最后提个醒不是所有网络都需要复杂QoS。一个小型办公网络带宽充足业务流量不大你花一周时间搞一套精细的QoS方案收益很低。QoS是用来解决“资源不足时的分配问题”的如果带宽够用最简单的分类标记加上默认队列调度就够了。我自己做项目时的一般原则是先确认瓶颈在哪出口带宽、核心链路、无线环境再决定做多深的QoS。很多场景下仅仅是把语音和关键业务标记出来放到高优先级队列网络体验就能有质变。与其一开始就追求复杂的多层策略不如先把分类标记和基础调度做扎实再按需扩展。这个内容后续还能扩展的方向是不同厂商设备之间DSCP和802.1p的映射一致性检查以及队列调度参数PQ/WRR/LLQ的配合设置。如果你们那边有实际场景也欢迎一起交流踩坑心得。