做网络项目这么多年处理过的QOS需求里十个有八个是同一句话“视频会议卡、语音听不清把流量优先保障一下。”可真要动手配置第一步压根不是调队列、设带宽而是先把报文分清楚——哪些是语音、哪些是视频、哪些是普通下载。这篇是QOS实操系列的第二篇专门聊透“报文简单分类和标记”这个环节基于报文里自带的标签字段用最快的速度把流量分类再打上统一的标记为后面做队列调度铺路。适合正在配交换机QOS、想在真实设备上落地分类策略的兄弟们参考。1. QOS分类与标记的整体设计思路1.1 为什么要给报文“分门别类”先想清楚一个底层问题网络设备在转发报文时底层逻辑其实很“一根筋”——有队列就往队列里塞队列满了就丢包调度器按顺序出队。如果不做任何分类所有流量共享同一个转发行为那语音、视频和下载任务在设备看来是平等的拥塞时大家一起丢包、一起排队。问题就来了语音丢几个包就听不清视频卡一下画面就糊而下载文件哪怕延迟几秒用户也没啥感觉。QOS的核心思想就是打破这种“平等”让不同报文享受差异化服务。要实现差异化第一步就是识别出“谁是谁”这一步叫分类。分类的结果决定了报文之后进哪个队列、享受多少带宽、丢包概率是高是低。如果分类错了后面所有QOS策略都等于白配甚至可能把重要流量分错队造成反效果。所以分类是整个QOS体系的“地基”。1.2 分类和标记在QOS整个体系里的位置完整的QOS处理链路一般是这样的报文进入设备先做分类和标记再进入拥塞管理排队和调度同时可能配合拥塞避免WRED、流量监管和整形。分类和标记通常在入方向完成也就是设备刚收到报文的那个接口上就做判断而排队、调度、丢弃策略一般在出方向生效。这里有个容易忽略的点分类是“识别”标记是“改写”两者经常连着用但动作不同。分类识别出流量类别后设备可以把这层身份用某种方式“写”在报文里这就是标记。为什么要再写一遍因为报文可能在网络里多跳转发每一跳设备都要知道这包是什么优先级。如果只在第一跳设备内部存一个状态到了下一跳设备就“失忆”了。所以最佳实践是一开始就把身份写进报文的ToS字段或VLAN优先级字段让后续所有设备都能识别。1.3 简单分类 vs 复杂分类先想清楚再动手分类可以做得非常复杂按五元组精准匹配、按应用层协议识别、甚至结合用户身份做控制。但实际项目中我绝大多数情况下只推荐先做“简单分类”——直接读报文里已有的优先级字段802.1p、DSCP、IP优先级进行匹配和标记最多再配上几条ACL按网段区分。简单分类最大的优势是快且稳。交换机硬件里通常有专门的优先级映射表一条命令就能把DSCP识别出来不消耗复杂的ACL资源转发延迟也低。而复杂分类比如深度包检测、按应用特征识别需要额外的硬件表项和计算资源中低端设备跑起来经常性能吃紧。我对团队的要求是能用字段解决的就不上DPI能用网段分清的就不配一大堆ACL。这不是偷懒是让方案在真实网络里能扛住流量。2. 报文中那些“自带标签”的字段详解2.1 二层802.1p优先级字段先看二层。在VLAN封装里802.1Q标签的Tag Control InformationTCI中有3个bit专门用来做优先级这就是802.1p取值0到7。802.1p是QOS最早也最常见的标记方式之一在接入交换机、局域网内用得非常多。比如常见的语音话机接在接入交换机上话机发出的报文会在VLAN标签里带上802.1p5或6交换机一看这个值就知道这是语音流量。802.1p取值对应的默认语义大致是7给网络控制报文6给时延敏感度极高的语音5给交互式视频4给受控负载3是“尽力转发”的加强版0是普通尽力而为1、2保留或给后台业务。当然厂商默认映射不完全一样但大方向一致。配置设备时我会特别注意如果把端口设为“信任802.1p”交换机就会按这个值做后续调度如果不信任所有报文都会被重新打为默认的0或接口指定值。2.2 三层IP优先级与DSCP到了三层QOS标记字段在IP报文头里。老一代叫ToSType of Service字段一共8bit其中高3位是IP优先级IP Precedence取值0到7后来RFC 2474定义了DSCP占用ToS字段的高6位取值0到63剩下2bit保留给ECN显式拥塞通知。所以你在抓包软件里看到的“Differentiated Services Field”其实是同一个字节只是被重新切分了解读。这里有个常见误区DSCP和IP优先级并不等价。IP优先级只有8个等级DSCP有64个编码其中不仅包含等级还包括“丢弃优先级”。比如AF41转发保障类等级4低丢弃和AF42同一等级、中丢弃…… DSCP更精细现代网络设备基本都以DSCP作为分类和标记的基准。配置时我一般直接推荐统一改用DSCP避免后续还要做字段映射的麻烦。2.3 一张表看懂各字段映射实际操作里经常要“换算”字段我把常用的优先级和DSCP值整理成一张对照表方便直接参考用途802.1pIP优先级DSCP名称DSCP数值抓包显示尽力而为00BE/CS000x00语音65EF460xB8交互式视频54AF41340x88广播视频54AF31/AF32/AF3326/28/300x68/0x70/0x78信令如SIP33CS3240x60网络控制76CS6480xC0关键业务数据3~43~4AF21/AF3118/260x48/0x68大量下载/后台11CS180x20实际项目中我会按这张表来制定标记标准并把它写进网络设计文档。好处是全网统一口径语音就是DSCP EF、交互视频就是AF41不管中间经过多少台设备所有人都按这个规则配置QOS策略就不会出现前后矛盾。2.4 隧道封装后标签去哪了简单分类里最容易被坑的就是隧道场景。GRE、VXLAN、IPSec这类技术会在原始报文外面再加一个外层IP头而大多数网络设备做QOS分类时只看最外层的报文头。如果外层IP头里的DSCP被复制了内层值那中间路径还能识别如果外层DSCP被清成0或重置内层打好的标记在隧道中间根本看不见。我在一个跨园区传输项目里就踩过业务系统在报文二层已经打了802.1p高优先级但流量走到GRE隧道后中间路由器完全认不出来视频照样卡。后来解决方法是先确认隧道封装模式对DSCP的处理策略必要时在隧道出接口上配置标记动作把关键业务重新标成对应DSCP。所以做分类标记方案时一定要先画清楚报文在各段路径上的封装形态否则中间的标记可能只是“自嗨”。3. 标记动作的核心原理3.1 标记的本质是改写字段标记动作听起来很高端其实关键就是“改字段”。比如设备收到一个DSCP0的普通数据包想让它享受高优先级可以在入方向重写报文的DSCP为EF这样后续节点看到这个包就知道要优先处理。同理也可以重写802.1p、MPLS EXP等字段。不过要分清“信任”和“重标记”信任模式是说“我认你带来的优先级”报文保留原样内部调度直接用这个值重标记则是“不管原来是什么到我这按我的规则统一改写”。完整的QOS方案里往往是两者结合靠近终端侧的设备会重新标记保证进入骨干网的报文都带着统一标准的标签骨干设备则做信任快速读取字段并根据优先级调度。这种分工能让全网标记规则一致又不会给核心设备增加过多处理压力。3.2 EF / AF / CS / BE 到底怎么选标记时必须回答“给我的业务标成什么值”。这里我强烈建议采用RFC 4594的推荐标准既规范又方便后期维护实时语音用EFDSCP46。EF的语义是低延迟、低抖动、低丢包专门给语音这类最敏感的业务。交互式视频视频会议用AF41DSCP34。视频比语音容忍度高一点但也需要保障AF41给的是“高优先级、低丢弃”。信令流量用CS3DSCP24。信令本身不大但非常关键SIP协商包丢了通话根本建立不起来。关键业务数据用AF21/AF31保证带宽和较低丢包。普通上网、下载用BEDSCP0。很多新手喜欢图省事全标成EF这是大忌。EF在队列调度中通常进PQ优先级队列如果大量高带宽流量都进PQ拥塞时PQ排队过长语音反而跟着遭殃。所以EF只给语音视频用AF类各司其职才是合理的标记策略。3.3 信任模式决定“认不认”报文的标签配置标记前一定要检查接口的信任模式。很多网络设备默认行为是不信任任何优先级也就是说哪怕终端发出的报文带了DSCP EF交换机也会按普通流量处理这在接入层尤其常见。不信任模式的意义在于防止终端用户乱打标签“插队”让网络管理员统一控制。如果你的终端是可控的比如IP话机会自己标EF那么接入端口可以配置为信任DSCP如果终端不可控就要在接入层按VLAN、IP或ACL做一次重标记把该给语音的给语音、该给视频的给视频再向上传递。信任还是不信任本质上是个管理策略选择没有绝对对错但必须明确配置否则设备默认行为很容易让QOS策略失效。4. 实操过程与关键配置实现4.1 一个典型场景办公网语音视频优先假设一个中等规模办公园区网接入交换机上接了三种终端IP话机在VLAN 10视频会议终端在VLAN 20普通办公电脑在VLAN 30。需求是语音必须最优先视频其次普通办公流量尽力而为。方案在接入交换机上把所有语音流量统一标记为DSCP EF并信任处理视频标记为AF41普通数据保持BE。这样汇聚层和核心层只需根据DSCP做队列和带宽保障全网策略一致。4.2 华为VRP平台配置思路以华为S系列交换机为例我一般用流策略traffic policy来做入方向分类和标记。下面是一个有代表性的配置片段# 定义ACL按网段匹配语音终端 acl number 3101 rule 5 permit ip source 192.168.10.0 0.0.0.255 # 定义流分类 traffic classifier voice if-match acl 3101 traffic classifier video if-match acl 3102 # 定义流行为重新标记DSCP traffic behavior voice remark dscp ef traffic behavior video remark dscp af41 # 定义流策略并绑定关系 traffic policy access_mark classifier voice behavior voice classifier video behavior video # 在接入接口入方向应用 interface GigabitEthernet0/0/1 traffic-policy access_mark inbound如果你用的是支持直接信任DSCP的型号配置更简单只需在接口下加trust dscp但前提是终端已经打好了标记。实际项目中我会优先在接入层做重标记因为这样不管终端怎么配置最终进入网络的优先级都是可控的。还需要注意华为设备流行为里也支持remark local-precedence设置内部本地优先级这个值是设备内部调度用的不同型号有差异。建议只做DSCP重标记后续队列映射交给汇聚层统一处理避免把配置写得太死后期难维护。4.3 Cisco IOS XE等价做法Cisco体系里用的是MQC模块化QOS CLI逻辑和华为很像同样是class-map policy-map service-policy三段式。下面是等价配置class-map match-any VOICE match access-group name VOICE_ACL class-map match-any VIDEO match access-group name VIDEO_ACL policy-map ACCESS_MARK class VOICE set dscp ef class VIDEO set dscp af41 class class-default set dscp 0 interface GigabitEthernet0/1 service-policy input ACCESS_MARK注意这里 class-default 我把DSCP设置为0是为了明确告诉设备“普通流量按默认处理”防止原来报文里带了其他值造成意外。这个习惯后来帮我在多次测试里减少了很多莫名其妙的干扰。Cisco里match dscp也可以直接在 class-map 内匹配比如match dscp ef适合已经信任DSCP的场景。4.4 验证让配置真的被看到配置完不是结束必须验证。华为设备上推荐看流策略统计检查匹配报文数是否在增长display traffic classifier statistics interface GigabitEthernet0/0/1 inbound这条命令能看到每个分类器匹配到的报文数、字节数如果匹配数为0说明流量没进到预期分类需要检查ACL和策略绑定是否正确。Cisco设备则用show policy-map interface GigabitEthernet0/1能看到每个类的packets统计和动作执行情况。要确认DSCP真的被改写成预期值最直接的办法是抓包验证。在接口镜像或PC上抓包后用Wireshark看IP头里的Differentiated Services Field语音包显示DSCP: EF (46)视频包显示DSCP: AF41 (34)说明标记生效。这里有个细节很多抓包工具默认显示ToS/DSCP时带有ECN位要区分清楚DSCP数值才是真正的标记值。5. 常见问题与排查技巧实录5.1 流量没有进入预期队列最常见的问题是配置了分类策略但流量始终匹配不上。我的排查顺序是先确认流量实际走到哪个接口再看策略应用方向是否对——分类标记通常做在入方向。有些朋友把策略挂在出方向结果看到的是队列调度生效分类统计一直为0其实是方向理解错了。其次检查匹配条件。ACL配的是源网段是192.168.10.0但如果终端实际走的是另一个网段自然匹配不上。还有一种隐蔽情况设备上有多个策略叠加比如端口下的VLAN策略、全局策略匹配顺序或优先级不同可能导致你的策略根本没生效。我会先用display traffic policy applied-record之类的命令看策略实际应用情况确认没有冲突后再判断是否是匹配条件本身的问题。5.2 DSCP被改了但下游设备不认标记配置正确本机上查看DSCP也变了但下游设备依然按普通流量处理。这种问题十有八九出在“下游接口不信任DSCP”上。QOS策略是否生效取决于路径上每一跳是否配合。第一跳改了DSCP第二跳设备默认不信任照样按0处理那标记就白做了。解决思路是端到端做一次QOS域规划接入、汇聚、核心全部统一配置信任DSCP或在每跳做相同的重标记。我习惯在网络设计阶段就把“标记在哪几个设备上做、信任从哪台设备开始”写清楚避免上线后一台台排查。你可以在每一跳设备上分别用统计和抓包确认DSCP传递情况定位是哪一段“丢标签”。5.3 隧道/MPLS场景标记失效隧道场景在前面提到过实际排查中特容易让人懵。比如报文在接入设备上标记了DSCP EF但流量走VXLAN后中间设备只认出外层VXLAN头封装原有的DSCP就看不到了。更麻烦的是有些封装默认不会把内层优先级复制到外层导致中间网络完全“无视”你的标记。处理办法一般有两个一个是在隧道封装设备或出接口上加标记动作让外层IP头继承或重写DSCP另一个是采用支持DSCP/QOS映射的隧道协议配置参数很多平台上有类似qos map的选项可以配置内外层字段映射。最实用的建议是抓包看两个位置的报文头——隧道入点之前和出点之后对比外层DSCP问题立刻清晰。5.4 分类性能与硬件表项简单分类之所以叫“简单”正是因为对设备硬件友好。但有一些所谓“简单配置”其实消耗不小例如把ACL规则写得特别多、特别碎或者每条流分类都单独建一条匹配规则累积起来可能占满设备硬件表项。中低端交换机上复杂ACL规则数量是有限制的规则过多会直接导致后续规则匹配不上或转发性能下降。我的习惯是尽量合并规则能用网段的不用单IP能用DSCP区间不用逐条枚举能按VLAN区分的就不写IP。对于需要精细分类的流量只针对核心关键业务做规则匹配其他流量全部归到类默认。这样既保证QOS效果又保住设备转发性能和表项余量。每次配置完我都会在终端设备上刷新一下数据面统计观察CPU和表项占用确保没有引入隐性负载。做QOS的这几个月里我感触最深的一点是分类标记看起来只是“给报文贴个标签”但真正的难点在于让全网的设备按同一套规则认标签、传标签。先把简单分类和标记这一步做扎实后面的队列、带宽、丢包策略才有意义。最后再分享一个实操小习惯每台设备的QOS配置模板我都会注释清楚用途、DSCP取值和对应业务并建议团队统一用同一个模板变体。这样每次排查问题时不用从头猜配置意图直接对照模板就能定位是哪一跳出了问题。