区分服务DiffServ在路由器中的实现:分类、标记、PHB与队列调度
发布时间:2026/9/30 12:36:40 作者:尧图编辑部 阅读量:1,286

简介《区分服务在路由器中的实现》是一份面向网络工程师、通信专业学生及技术研究者的参考文献重点解决传统尽力而为网络难以满足不同业务差异化服务质量需求的问题。内容基于IETF提出的DiffServ体系从IP分组头的DS域与DSCP编码讲起梳理了边缘网络设备的流分类、标记功能以及核心路由器依据每一跳行为PHB进行转发的完整流程。文章着重剖析了绝对区分服务中加速转发EF与保证转发AF两种服务类别在路由器内的实现方法包括队列设置、带宽约束、时延控制、拥塞时的优先级丢弃等关键技术并讨论了带宽代理BB如何通过SLA协商为用户提供有保证的转发资源。整个资源为1个PDF文件压缩包约192KB篇幅精简但覆盖面完整。目前已有103人学习/下载适合需要系统理解QoS策略、路由节点工作原理或撰写相关技术报告的人员参考。1. 区分服务在路由器中的实现这份方案到底在解决什么问题拿到《区分服务在路由器中的实现》这类资料时最容易被标题里的“实现”两个字带偏以为它是某台设备的配置手册。实际上它讲的是一套已经在现网跑了二十多年的QoS框架把流量按业务类型在入口打上标记路径上的路由器只认这个标记来决定排队、调度、丢弃。这套机制叫区分服务DiffServ设计哲学是边缘做细活核心做粗活。语音、视频会议、关键业务和普通上网流量挤在一条链路上时靠它保证高优先级流量不被低优先级拖死。这篇内容适合两类人刚接触路由器QoS、想搞清楚标记和队列关系的新手已经配过优先级队列、正被“链路一拥塞策略就失效”困扰的熟手。文章把这条链路从分类到丢弃一次讲透参数和坑一个不落。2. 区分服务的四段链路分类、标记、PHB与队列调度任何DiffServ实现追到底都是四个环节串起来的入接口对报文做分类分类结果以DSCP值写进IP头路由器转发时读取这个值出接口按DSCP把报文映射到具体的硬件队列队列按调度算法和丢弃策略决定谁先走、谁被丢。这四个环节是流水线关系缺一环策略就只是配置文件里的几行字。2.1 报文分类与DSCP标记让流量一进门就带身份分类是整个DiffServ里最费心思的环节因为流量形态千奇百怪分类规则却是有限的几种常见做法。最常用的是按五元组匹配用ACL描述源IP、目的IP、协议、源端口、目的端口也可以直接按接口分类比如接视频会议终端的接口进来的流量整体进高优先级队列还可以信任上游设备已经打好的标记按DSCP值直接分类。我一般落地企业网时用“信任加重标记”的组合对上行的核心/汇聚端口配置信任DSCP对接终端的接入端口用ACL做精细分类。纯靠信任不可靠纯靠ACL又规则爆炸两者配合才顺手。标记动作发生在IP头的ToS字节。路由器把ToS字节拆成两部分前6位是DSCP后2位是ECN所以DSCP的取值范围是0到63。配置时最常见的是直接写十进制值下面这张表是必须记牢的底子。DSCP名称二进制十进制典型用途EF10111046语音、低延迟实时业务AF4110001034高优先级视频AF3101101026关键业务数据AF2101001018普通业务数据AF1100101010低优先级数据BE0000000尽力而为流量为什么要把十进制值记这么细因为后面所有队列映射、丢弃策略都拿这个值当索引。配置里写错一位流量就静默地进了别的队列。AF41对应十进制34不是40这类低级错误我见过不止一次。另一个容易混淆的点是本地优先级和DSCP的区别很多路由器内部调度看的是本地优先级local-precedenceDSCP只是对外传递的标签。入接口重标记DSCP的同时一般要同步把本地优先级设置好否则报文带着高DSCP进了设备内部调度却一视同仁策略照样不生效。2.2 PHB与队列路由器怎么“看懂”一个DSCP值DSCP只是标签真正决定转发待遇的是PHB逐跳行为。RFC 2474之后的PHB分三大类EF、AF和BE路由器对这三类的处理逻辑完全不同。EF快速转发对应低延迟低丢包典型承载语音。它要求队列的服务速率不低于报文到达速率否则延迟和抖动一路恶化。实现上通常把EF映射到优先级最高的队列用严格优先调度PQ处理。AF确保转发分成AF1到AF4四个等级每个等级内部又有三个丢弃优先级比如AF21、AF22、AF23的区别不是带宽大小而是拥塞时谁先被丢。路由器实现时按AF等级分配队列同一队列内部再做WRED分类丢弃。BE就是尽力而为没有保障拥塞时最先被丢。队列调度是PHB落到转发平面的最后一步。一台路由器的出接口通常有8个硬件队列配置要做的就三件事把DSCP映射到某个队列、给队列分配调度方式和带宽比例、给队列设置丢弃阈值。之前在GNS3里搭拓扑验证DiffServ抓包看DSCP已经标上去了但出接口不排队最后查到是队列映射那一步漏了。这种错位在模拟器和真机上都很常见。2.3 为什么是DiffServ而不是IntServ规模化才是关键有必要说一句对比。IntServRSVP要为每一条流做端到端的资源预留核心路由器也要维护每条流的状态在现网规模下基本撑不住。DiffServ把复杂度推到网络边缘核心节点只按DSCP做转发不维护流状态这是它能存活到今天的原因。生产环境里常见的是两者混用骨干用MPLS TE做带宽规划接入和汇聚用DiffServ做优先级调度各管一段。还有一点容易被忽略DiffServ的进出方向配置通常不对称。入接口做的是分类和标记出接口才做队列调度。很多人只在出接口配了队列模板入接口既没信任DSCP也没重标记流量到了出接口全是默认值策略当然不生效。动手配置之前先做一张分类规划表什么业务、什么DSCP值、落在哪个队列、拥塞时怎么丢。表先画好再敲命令比边配边想要靠谱得多。3. 在路由器上把区分服务跑起来从入接口到出接口的配置链路这一章给一套能直接照着敲的配置模板。命令以华为VRP通用风格为例不同版本字段略有差异但语义一致。拓扑也很简单一台路由器接语音网关和视频终端上行口接核心交换机出口带宽有限需要在路由器上做优先级保障。3.1 入接口做分类与重标记华为AR系配置与说明先定义分类器。语音按DSCP EF匹配视频按AF41匹配普通流量不匹配就走默认行为。这一步要做的就是把业务流量从背景流量里摘出来。# 定义分类器按DSCP值匹配语音和视频流量 traffic classifier voice if-match dscp ef traffic classifier video if-match dscp af41 # 定义行为重标记DSCP并同步设置本地优先级 traffic behavior mark-voice remark dscp ef local-precedence 7 traffic behavior mark-video remark dscp af41 local-precedence 5 # 绑定策略到入接口 traffic policy diffserv-in classifier voice behavior mark-voice classifier video behavior mark-video interface GigabitEthernet0/0/1 traffic-policy diffserv-in inbound qos trust dscp命令逻辑是三层嵌套classifier定义“匹配谁”behavior定义“匹配后做什么”policy把两者绑在一起最后应用在接口的入方向。这里有两个关键参数。remark dscp改的是报文IP头里的标记local-precedence改的是设备内部调度的优先级两步必须配套否则外部标记对了内部调度不认。qos trust dscp表示该接口信任已经携带DSCP的报文如果上游设备已经打好了标记这里可以直接继承而不是重写。实际落地时接入终端的接口不建议直接trust因为终端发的包大多不带DSCP或者乱带必须在策略里用ACL按业务特征重标记才能保证分类可控。3.2 出接口的队列映射与调度让不同DSCP落到不同队列入接口标好了身份出接口要建队列模板。8个硬件队列里队列7留给语音队列5给视频队列3给关键数据队列0是默认的BE流量。# 创建队列模板定义各队列的调度方式和权重 qos queue-profile voip-q queue 7 schedule pq queue 5 schedule wfq weight 30 queue 3 schedule wfq weight 20 queue 0 schedule wfq weight 10 # 把DSCP值映射到对应队列 interface GigabitEthernet0/0/2 qos queue-profile voip-q qos map-dscp dscp 46 queue 7 qos map-dscp dscp 34 queue 5 qos map-dscp dscp 26 queue 3 qos map-dscp dscp 0 queue 0调度参数分两类。schedule pq是严格优先队列7只要有余量就最先被转发不被其他队列打断适合语音。schedule wfq weight是加权公平队列各队列按权重比例分享剩余带宽权重30比10意味着视频在竞争时能拿到约3倍的带宽配额。这里要留意qos map-dscp是逐条映射配置前最好先查一下设备默认的DSCP映射表因为很多设备默认就把AF41映射到队列5如果自定义模板没有全量覆盖漏掉的DSCP值会落到默认队列上出现“明明配了策略流量却走了别的队列”的怪象。3.3 拥塞丢弃配置WRED的落地与“丢谁”的决策有排队就有拥塞有拥塞就得决定先丢谁。WRED的思路是队列深度超过低阈值就开始随机丢弃超过高阈值就全部丢弃中间用丢弃百分比控制丢弃强度。配置如下。qos queue-profile voip-q queue 7 wred green low-limit 90 high-limit 100 discard-percentage 5 queue 5 wred green low-limit 70 high-limit 90 discard-percentage 20 queue 3 wred green low-limit 50 high-limit 80 discard-percentage 30 queue 0 wred green low-limit 30 high-limit 70 discard-percentage 40这几个参数的作用要分开看。low-limit和high-limit是队列深度的百分比阈值discard-percentage是达到低阈值后的丢包强度。语音队列的丢包百分比只给5因为语音不重传丢一个包就是一段听不清的话BE队列给到40因为普通流量可以重传丢了不心疼。AF队列内部的三个丢弃优先级是另一层逻辑AF41、AF42、AF43在同一个队列里通过匹配不同的DSCP在WRED里设置不同阈值实现同一队列内部的梯次丢弃。这里的原则一句话高优先级队列阈值设高、丢弃百分比设低低优先级反过来。3.4 用eNSP或GNS3练手把配置先跑在模拟环境里没有真机的时候eNSP里拖两台华为AR路由器就能把这个流程完整跑一遍。拓扑不用复杂AR1接两个PC模拟语音和视频终端AR1上行接AR2模拟核心网在AR1的出接口上做队列调度。GNS3里用开源路由器镜像思路完全一致只是命令风格不同队列、WRED这些概念是通用的。模拟环境最大的价值是能看到计数器策略应用后分类命中的报文数、各队列的收发包数、丢弃数全部列得清清楚楚。我建议先在模拟器里把配置敲一遍再用打流工具验证最后再上真机省下的排错时间足够再学一遍配置。4. 参数怎么调调度算法、DSCP映射与丢弃阈值的配合配置模板只是骨架真正决定服务质量的是参数。这一章把调度算法、映射表和阈值放在一起讲因为它们不是独立变量调一个就要重新审视其他两个。4.1 队列调度算法的选型PQ、WRR、WFQ、DRR的取舍出接口队列调度是DiffServ里最有讲究的一步。常见算法有四种选型直接决定高优先级流量和低优先级流量在拥塞时的关系。调度算法原理优点风险典型场景PQ高优先级队列先走完延迟最低低优先级可能饿死语音流量单独占用WRR各队列按权重轮询实现简单带宽可控权重在拥塞时不够精确多等级业务的汇聚出口WFQ按报文大小和权重动态分配公平性好小包不吃亏CPU占用高队列多时处理慢数据业务为主的出口DRR按队列深度轮询对变长报文更公平配置复杂度高运营商边缘设备实网里常见组合是PQ加WFQ语音走PQ保证延迟其他流量走WFQ保证带宽按比例分配。注意PQ有个致命副作用如果语音流量异常暴涨比如环路导致广播包大量进入语音队列PQ会一直转发这个队列数据流量全部饿死。解决思路是给PQ队列设带宽上限华为设备上可以通过队列限速实现或者用类别的LLQ思想替代纯PQ。我自己有个习惯任何把某类流量设为严格优先的配置都同时给它加一个最大带宽约束防止单个业务异常拖垮整条链路。4.2 DSCP到队列的默认映射表动手前先看清默认值很多设备出厂时已经带了一套DSCP到队列的默认映射不了解它就会踩“配了没反应”的坑。以下是一套典型的8队列默认映射具体值要以设备实际查询为准但结构大体如此。队列默认DSCP分类队列7EF(46)、CS7(56)语音、网络控制队列6CS6(48)网络控制队列5AF41(34)、AF42(36)、AF43(38)、CS5(40)视频队列4AF31(26)、AF32(28)、AF33(30)、CS4(32)关键数据队列3AF21(18)、AF22(20)、AF23(22)、CS3(24)业务数据队列2AF11(10)、AF12(12)、AF13(14)、CS2(16)低优先级数据队列1CS1(8)最低优先级队列0BE(0)尽力而为这张表透露了一个关键信息AF的三个丢弃优先级共享一个队列。也就是说AF41和AF43在硬件队列层面是同一个队列区分它们靠的是WRED内部的不同丢弃阈值而不是单独的队列。明白了这一点就能理解为什么配置8队列的设备能承载超过8种DSCP值的业务——队列只分8类丢包策略在队列内部细分。查询命令各厂商各不相同但思路一致先show默认映射再在默认映射基础上改而不是从零开始建一套全新的表后者容易漏值。4.3 带宽比例、队列深度与丢弃阈值的计算思路参数设定的核心是回答一个问题出口带宽一定时每个队列分多少。以一个1Gbps出口为例语音规划50M视频200M关键数据100M剩余650M留给BE。语音用PQ不参与权重分配视频、关键数据、BE的权重就按200:100:650换算简化成20:10:60。WFQ权重不要求严格精确但要保证比例关系符合业务预期视频的权重至少是BE的三分之一以上否则视频拥塞时带宽跟不上。队列深度是另一个常被忽略的参数。语音队列深度要小因为语音报文小、对延迟敏感队列里堆几十个包就能引入几十毫秒延迟数据队列深度可以大利用缓冲吸收突发流量。很多硬件平台队列深度不支持直接配置那就退而求其次语音队列不要开WRED或者把阈值设得很宽松让拥塞时直接尾丢反而比随机丢几个语音包更可预测。WRED阈值的设定我给一组参考语音高阈值100%、低阈值90%、丢弃百分比5%以内视频高阈值90%、低阈值70%、丢弃百分比20%BE高阈值70%、低阈值30%、丢弃百分比40%。这套参数的逻辑是越重要的流量让它丢得越晚、丢得越少把丢包的痛苦全部转嫁给低优先级业务。5. 区分服务在路由器实现中的常见坑现象、原因、解决DiffServ这套方案实现层面有个被反复提到的缺陷它不是配完就万事大吉的黑匣子任何一环配置错位流量都静默地走默认队列而且不报任何错。下面五条是我自己踩过或者帮别人排过的每一条都是真实现象。5.1 流量全进了BE队列分类规则就是匹配不上现象策略配置完整出接口各队列统计显示几乎全部报文落在队列0语音队列计数为零。原因分类用的if-match条件和实际报文特征不一致。最常见的是上游设备标记的是IP优先级ToS前3位而分类器匹配的是DSCP两者数值对不上或者视频流量实际DSCP是AF41但配置里写成了AF31。解决抓包确认报文的DSCP实际值再看分类器匹配条件。华为设备上display traffic policy statistics能看到每个分类器的命中计数先确认这个计数在涨再往下查映射。5.2 入接口没配信任DSCP在入口就被丢弃了现象出接口队列映射完全正确抓包看报文到了出接口DSCP也在但队列统计里大量报文落在默认队列。原因入接口默认不对报文上的DSCP做信任处理报文进入设备时如果未在策略里显式匹配DSCP标记不会被读取本地优先级是默认值。解决入接口加qos trust dscp或者在traffic-policy里用匹配DSCP的分类器做重标记。顺带一提如果你在入接口配了重标记策略策略里没匹配到的流量DSCP保持原样但本地优先级仍然是默认所以看内部调度时这类流量还是会走默认路径。5.3 DSCP映射表没查默认映射把流量带偏了现象AF11配置成进队列2实际统计却到了队列0。原因部分设备的默认DSCP映射里AF11并不在队列2自定义qos map-dscp又只覆盖了部分DSCP值未覆盖的走了默认路径。解决动手改映射前先查设备的默认映射表在默认表的基础上做增量调整。这个坑在更换设备型号时最容易踩不同厂商、同一厂商不同系列的默认映射都存在差异。5.4 PQ把低优先级流量饿死TCP业务全军覆没现象语音高峰期数据业务掉到几乎为零TCP连接大量超时重传。原因PQ严格优先队列在持续有流量时不会被其他队列打断语音流量稍有波动低优先级队列全部停摆。解决给PQ队列配置最大带宽限制或者在调度器支持的情况下改用CBWFQ/LLQ只对语音流量做优先级保证而不是绝对优先。配置后要压测把语音流量灌到超过预期峰值同时观察数据流量的存活情况这是验证PQ是否健壮的最直接方法。5.5 测试脚本测不出效果打流工具根本不标记DSCP现象策略配完用iperf打流不管怎么调优先级带宽表现没有差别。原因iperf默认发出的报文DSCP是0全部落进BE队列策略自然没有表现。解决打流前先确认工具是否支持设置ToS/DSCPiperf3可以指定--tos参数或者用Scapy构造带指定DSCP的测试流。这个问题在模拟器里尤其容易翻车因为eNSP和GNS3里的PC终端默认不发带DSCP的报文。6. 验证与进阶让区分服务的每个环节都看得见验证DiffServ配置是否生效只看配置不回显远远不够。我的验证习惯分三步先看计数再抓包最后压测。设备上查看策略命中统计和队列统计确认分类器计数在增长、各队列有对应的收发包数然后在入接口和出接口分别抓包确认入接口报文DSCP被正确标记、出接口报文带着预期的DSCP值离开最后用打流工具分别发送BE和EF标记的流量观察拥塞时两者的丢弃差异。三步走完配置链路才算闭环。打流这一步可以用Scapy快速构造带指定DSCP的报文省去改终端系统路由表之类的麻烦from scapy.all import IP, UDP, Ether, sendp # 构造一个DSCP为46EF的UDP报文从测试口发出 pkt Ether()/IP(dst192.168.1.2, tos46)/UDP(dport1234)/bqos-test # 循环发送1000个报文观察对端优先级 for _ in range(1000): sendp(pkt, ifaceeth0, verbose0)这段脚本里最关键的参数是tos46Scapy的tos字段直接映射到IP头ToS字节46对应EF。测试时分别构造DSCP 0、26、46的报文对比它们在拥塞场景下的延迟和丢包差异。脚本只负责制造带标记的流量真正的验证还要回到设备的队列统计上去看。进阶方向有两个值得投入一个是把静态分类升级为动态标记比如语音网关通过VLAN或802.1p自动映射DSCP省去每条流的ACL配置另一个是IPv6环境下DiffServ的位置从ToS字段变成了Traffic Class字段规则虽同但抓包时别再看错了位置。做DiffServ这几年我最大的教训是配置命令只是最后一步分类规划表和验证步骤才是真正花时间的部分——顺序反了后面全是返工。希望帮到你。本文还有配套的精品资源点击获取