简介区分服务Diffserv在高性能路由器中的实现是一篇出自中文核心期刊《微计算机信息》的技术文献面向路由器研发、网络运维与QoS学习研究人员。文章从传统尽力而为服务的不足入手对比集成服务Intserv的扩展性瓶颈引出Diffserv在网络边界分类、内部节点转发的体系优势系统阐述数据包分类机制、流量控制与路由调度设计并结合国家863项目“可扩展到T比特高性能IPv4/v6路由器基础平台”的测试验证。压缩包内含单篇PDF文件约199KB内容涵盖Diffserv三种服务质量类别尽力而为BE、奖赏服务EF、保证服务AF与DSCP映射PHB等关键概念也可作为IPv4/v6路由器、网络服务质量方向的参考文献与专业指导。目前已有104人学习适合需要快速掌握Diffserv在路由器中落地思路的技术读者阅读后可了解从数据包标记到队列调度的核心设计路径。1. 区分服务Diffserv在高性能路由器上的落脚点一场拥塞事故的复盘某个周五晚高峰出口链路被视频流量打满语音和ERP事务的延迟飙到300ms。路由器转发能力完全够CPU占用也不高可流量一旦拥塞就“一视同仁”地全部排队。要解决这类问题常见做法是在高性能路由器上启用区分服务Diffserv按业务打上DSCP标号再用队列调度与丢弃策略分等级保障。它解决的不是“带宽不够”而是“带宽分配不公”适合所有需要线速转发的企业网出口和运营商边缘场景。我最初以为Diffserv就是给报文打个标记直到自己把队列、整形、WRED全部配完后打了一轮拥塞测试才发现真正的难点在路由器内部的调度行为有限队列怎么承载五类业务为什么高优先级流量依然会丢包边界和核心设备各自该承担什么动作。这篇文章把我搭建这套方案时的理解、配置手法和踩过的坑完整记录下来。2. Diffserv模型拆解DSCP、PHB与分类计量怎么选才不失控2.1 为什么Diffserv能在高性能路由器上跑起来而Intserv不行在Diffserv之前网络界先提出的是Intserv综合服务它用RSVP信令为每一条应用流预留带宽。思路很完美但要落地在高性能路由器上根本跑不动核心路由器需要为每条流维护状态流数量一多转发表项和定时器就把内存吃光还要逐流做软状态刷新转发性能直接被拖垮。这也是Intserv最后只在小规模网络里存活的原因。Diffserv的思路完全不同它不逐流维护状态而是把流量按类聚合成少量行为集合。路由器转发面只需要看IP头里的DSCP字段按预先配置的PHB逐跳行为来决定放进哪个队列、使用什么丢弃策略。“状态在边界、行为在核心”的设计让中间节点变得极简单天然适合高性能路由器的硬件转发流水线。这也是区分服务Diffserv成为企业网和运营商实际部署标准的核心原因。在搭建这套体系前要先区分两个角色边界路由器负责“分类标记计量整形”核心路由器只负责“按标记调度丢弃”。边界设备通常要处理复杂ACL和应用识别性能瓶颈在策略匹配核心设备要处理聚合后的海量流量性能瓶颈在队列调度。理解这个分工后续所有配置才不容易做反。如果反过来让核心路由器做深度分类线速转发会立刻变成CPU转发。2.2 DSCP编码与PHBEF、AF、CS、BE各管哪一类业务DSCP差分服务代码点占用IP头TOS字段的高6位共64个码点。为了运维可读实际部署不会用全64个而是用RFC 2474、RFC 2597、RFC 3246定义的标准PHB集合。这里要把“DSCP值”和“PHB行为”分开记DSCP是报文里的标号PHB是路由器针对这个标号执行的动作集合。EFExpedited ForwardingDSCP 46提供低延迟、低抖动、低丢弃的“管道式”服务适合语音和实时视频通常配合LLQ严格优先队列。AFAssured Forwarding分为AF1到AF4四类每类内部又有三个丢弃等级比如AF41、AF42、AF43适合企业内部不同重要程度的业务。CSClass Selector兼容旧IP优先级便于从老网络平滑迁移。BEDSCP 0是默认尽力而为。PHBDSCP典型值适用业务队列丢包策略要点EF46语音、实时协作严格优先需限制带宽上限AF434/36/38关键事务、ERP带宽预留WRED按丢弃等级逐级丢弃AF326/28/30视频会议/直播带宽预留容忍一定抖动AF218/20/22一般业务、数据库中等带宽保障AF110/12/14批量传输、备份低带宽保障可被更高等级抢占CS6/CS748/56网络控制面只给协议报文不分配给业务BE0默认流量使用剩余带宽WRED早丢弃上表的分配方式是业界最常见的模板实际规划时要注意一个原则标记类别不要超过6至8个。很多项目一上来就设计了12个AF子类真实配置时会发现队列资源根本不够硬件队列通常只有8到16个强行细分会造成多个PHB共用队列优先级互相干扰。我一般建议企业网按“语音、视频、关键事务、一般业务、批量、默认”六类设计数量正好对应典型硬件队列数。实际组网里还涉及和二层优先级的映射。业务从接入交换机进入路由器时802.1p优先级需要先映射成DSCP否则标记只能在三层边界重新做一遍。常见做法是802.1p 5映射到EF、4映射到AF41、3映射到AF31。这一步如果没做接入层的视频流量在路由器上会被当成BE处理后面所有队列设计都白搭。我在设计Diffserv域时会把二三层映射表一起规划。2.3 分类器与计量器MF分类、BA分类和两种令牌桶的适用边界分类发生在流量进入Diffserv域的那一刻。边界路由器用MF多字段分类器通过五元组、应用端口或应用识别把流量归入某个业务等级。核心路由器不需要重新看五元组直接读DSCP做BA行为聚合分类原因是五元组查表在核心节点要做更多匹配动作会拉低线速转发性能。计量器负责判断流量是否超过约定速率。常见做法是单速率三色标记srTCM和双速率三色标记trTCM。srTCM用一个CIR承诺信息速率加CBS承诺突发判断报文标绿、标黄或标红适合对带宽上限严格要求但不关心峰值突发的业务trTCM在CIR之外再给一个PIR峰值信息速率允许短期突发适合视频和Web类流量。这里有个容易误用的点计量器的作用并不只是限速它还承担“重新标记”职责。超出CIR的报文不是简单丢弃而是被标记成低一级的DSCP或黄色路由器在拥塞时优先丢弃黄色报文。这样业务的整体体验是平滑降级而不是瞬间中断。如果直接丢弃超限报文语音和事务类业务会频繁闪断这就是为什么计量后通常还要接一个“标记动作”而不是“丢弃动作”的原因。还有一点计量器最好放在边界核心节点不做计量。核心节点要求快对每个报文做令牌桶操作也会消耗硬件配额。虽然部分高性能路由器可以线速计量但部署成本都会反映在设备选型上。计量放边界、调度放核心这个分工能让你用最少的硬件资源换取最清晰的QoS行为。3. 高性能路由器的队列调度从LLQ到WRED带宽比例与丢弃阈值怎么调3.1 队列架构与硬件转发为什么调度必须做在芯片里Diffserv的最终效果不是标记完成那一刻决定的而是在出接口拥塞时由调度器决定。高性能路由器之所以能同时跑满多线卡流量核心在于转发和调度都在专用芯片内完成流量进入端口后先按DSCP查映射表进入对应队列再由硬件调度器按配置好的权重和优先级把报文从队列取出。这个过程要是放到CPU里做线速转发马上就变成线速丢包。所以看一台路由器能不能扛住Diffserv不要只看它支持多少个类要看队列资源和调度精度。常见实现是每端口8至16个硬件队列队列深度以KB或MB为单位可调。配置时思考的是“队列怎么映射到PHB”和“每个队列分配多少带宽”而不是软件模拟队列那些花哨算法。转发芯片的调度粒度通常能做到64Kbps甚至更低带宽占比控制得越细AF类业务的区分度就越好。另一个常被忽略的点是内存缓冲。高性能路由器普遍采用VoQ虚拟输出队列或共享内存池队列深度决定突发吸收能力。调度算法可以保证带宽比例但如果所有队列都被填满丢包依然会发生。配置前先查一下设备的“队列深度上限”和“最大缓冲”这两个数字直接影响后续所有WRED阈值设计。3.2 LLQCBWFQ优先级和带宽比例怎么分配才不互相挤占队列调度最经典的组合是LLQ低延迟队列加CBWFQ基于类的加权公平队列。LLQ给EF语音流一个严格优先级保证它先于其他所有队列被调度与此同时又必须给EF队列设一个带宽上限百分比或绝对值防止语音或恶意流量挤占全部带宽。这个“严格优先限速”的组合是语音不卡顿的关键。下面是一段典型配置写在边界路由器的出方向class-map match-any CLASS-EF match dscp ef class-map match-any CLASS-AF4 match dscp af41 af42 af43 class-map match-any CLASS-AF3 match dscp af31 af32 af33 policy-map WAN-OUT class CLASS-EF priority percent 20 // LLQ严格优先带宽上限20% class CLASS-AF4 bandwidth percent 30 // CBWFQ保证带宽30% queue-depth 512 // 队列长度限制 class CLASS-AF3 bandwidth percent 20 // 视频类带宽保证20% class class-default fair-queue // 剩余流量走尽力而为这里priority percent 20的含义是该队列可以获得严格优先调度但它自身的速率不会超过接口带宽的20%。注意这不是“预留20%”而是“最多20%”EF流量少时剩余带宽依然能分给其他类使用。bandwidth percent 30则是承诺带宽AF4队列在拥塞时至少能拿到30%如果它没用到剩余带宽也可以被其他类借用。带宽百分比加起来不建议超过90%留出10%给协议报文和链路开销否则控制面报文在拥塞时也会被业务流量挤掉。带宽分配比例怎么定常见做法是先统计一周的流量模型。语音按并发通话数折算G.711一路约80Kbps100路并发就是8Mbps视频和事务类按业务SLA填批量类给剩余。最忌不加分析就按“语音20%、视频30%、事务40%”拍脑袋上线后大概率要返工。注意LLQ里EF队列不要开WRED语音是UDP随机丢包只会制造抖动。EF队列的处理是把队列上限设死超出即丢让语音流始终走最短路径。3.3 WRED阈值AF类内部的三个丢弃等级怎么设拥塞避免是Diffserv里最容易配错的一环。WRED加权随机早期丢弃在队列变深时按概率先丢低优先级报文避免全队列填满后的尾部丢弃导致所有流一起受损。参数有三个核心最小阈值、最大阈值、丢弃概率分母。队列长度低于最小阈值不丢包达到最大阈值时丢弃所有到达报文。class CLASS-AF4 bandwidth percent 30 random-detect dscp-based random-detect dscp af41 32 48 100 random-detect dscp af42 24 40 100 random-detect dscp af43 16 32 100这段配置把AF4类内的三个丢弃等级分别设置了阈值。af41最重要在队列长度32到48之间开始随机丢弃af43最不重要在16到32之间就开始丢。这样拥塞加深时先牺牲等级低的流量保住等级高的流量。100是丢弃概率分母表示队列达到最大阈值时理论丢弃概率为1/100调小比如50会让丢弃更激进。调节WRED阈值时要结合队列深度。如果把WRED最大阈值设成64而队列深度上限是128那队列还剩一半时就已经开始丢弃带宽利用率会被压低。一般做法是最小阈值设为队列深度的1/4到1/3最大阈值设为2/3到3/4给突发留出缓冲。千万别把最大阈值直接设成队列上限那样WRED和尾部丢弃会同时触发丢包行为会变得不可控。WRED对TCP和UDP的行为差异也要记牢。TCP流遇到丢包会退避重传所以WRED对AF类的TCP业务效果很好UDP视频流不会退避被随机丢弃后就是画面劣化。因此对视频类AF3队列我倾向不启用WRED只做带宽保证或者把WRED阈值设得很接近队列上限只在极端拥塞时才丢。4. 边界节点的Diffserv动作分类标记、令牌桶整形与隧道透传4.1 入向分类标记从ACL到DSCP的映射规则写法Diffserv域入口是边界设备它要完成“识别业务并打标”的职责。常见做法是在入方向做基于类的策略先定义class-map匹配条件再定义policy-map执行标记动作最后应用到入接口。匹配条件可以基于五元组、应用端口、甚至应用识别结果。下面是个实例class-map match-any MARK-SIP match udp dst-port 5060 class-map match-any MARK-HTTPS match protocol https class-map match-any MARK-DB match ip dscp default policy-map IN-MARK class MARK-SIP set dscp ef class MARK-HTTPS set dscp af41 class MARK-DB set dscp af21 class class-default set dscp default入向标记配置对转发性能影响最大的是match protocol这类深度包检测。高性能路由器做应用识别通常依赖硬件加速普通设备会绕到CPU导致吞吐骤降。我在实际项目里会尽量在接近业务源头的位置做分类比如在接入交换机或上层设备完成应用识别路由器只按已经标记好的DSCP做BA分类。这样边界路由器的入向策略不需要跑复杂ACL线速能力才保得住。标记动作还有一个容易忽略的细节重标记。当路由器同时收到上游已经带DSCP的流量时不能盲目覆盖。常见做法是对未标记流量dscp default做映射对已有标记的流量则尊重上游设定。上面的配置里对DB类专门匹配了dscp default就是为了避免把内部已标好的AF31误改掉。4.2 出向整形CIR、CBS、EBS的计算与配置边界路由器在出方向通常要做整形目的是把流量控制在运营商承诺的速率以内避免突发被运营商惩罚。整形的实现是令牌桶报文要发送前先检查桶里有没有令牌有就放行没有就排队等待。所以整形和限速不同整形平滑突发限速直接丢弃。policy-map SHAPE-WAN class class-default shape average 20000000 service-policy output WAN-OUT这段配置把出向速率整形成20Mbps同时叠加了之前定义的调度策略。令牌桶参数CBS承诺突发在这里决定报文可以瞬时冲出多少数据。CBS太小短暂的流量尖峰会被削平表现为吞吐上不去CBS太大又会把突发传导给上游失去整形的意义。经验公式是CBS取值在CIR的1ms到5ms带宽之间20Mbps线路取12500到62500字节实际配置往往取16000或32000。计算时还要考虑链路层开销。Ethernet帧头14字节、FCS 4字节、VLAN标签4字节这些都不计入IP层速率但实际占用物理链路。如果运营商承诺的CIR是20Mbps而路由器按IP报文统计整形到20Mbps加上开销后实际已经到了20.5Mbps。所以我一般会按CIR的95%配置整形速率给三层到二层的封装留出余量。4.3 隧道与MPLS场景DSCP透传规则和EXP映射Diffserv域跨越隧道时最常出问题的是DSCP怎么穿过封装。GRE和IPsec隧道会新增外层IP头默认情况下内层DSCP不自动复制到外层如果外层DSCP被设为0流量经过中间路由器时相当于没标记。这是很多“两端都配好了中间却失效”的根因。MPLS场景同理但机制稍有不同。MPLS报文头里没有DSCP用的是EXP字段。常见做法是边界路由器把入向DSCP映射到EXP核心路由器按EXP调度出边界再把EXP还原成DSCP。配置要点是保证“入向映射表”和“出向还原表”保持一致否则业务流入MPLS域后被重新标记端到端SLA就失真了。diffserv-domain WAN-MPLS dscp ef exp 5 dscp af41 exp 4 dscp af31 exp 3 dscp af21 exp 2 dscp default exp 0这段是主流的域配置风格不同厂商命令略有差异。重点不是记命令而是理清映射原则边界设备负责DSCP与EXP转换核心设备只认一种标记体系。如果核心设备已经支持基于DSCP调度则MPLS EXP映射只需要在边界做一次不需要每台设备反复改。还有MPLS TP和伪线场景下原始IP头被完全隐藏此时必须依赖EXP透传这一步在规划Diffserv域时就要考虑不然标签多一层整个QoS链就断了。5. Diffserv落地避坑五条现场排查记录5.1 标记了DSCP但队列不生效全局QoS开关没打开现象接口上配了policy-mapclass-map匹配也正确但打流测试时所有流量还是一个队列在走高优先级完全没效果。原因很多路由器的QoS功能默认是关闭的单接口下发策略不会自动启用全局调度。有的平台还需要在系统模式下开启qos enable或者把接口从“默认优先级模式”切换到“QoS模式”。解决先在全局视图下确认QoS开关再检查接口下是否绑定了service-policy方向不能弄反。入向标记策略绑input出向调度策略绑output这两个方向错一位整个Diffserv就白配了。排查时用display qos policy interface或show policy-map interface看接口下实际生效的统计能立刻发现问题。5.2 语音流在拥塞时仍然丢包EF队列的带宽上限和WRED冲突现象EF队列的标记和调度都配了拥塞一发生语音先丢包MOS分直接掉到3以下。原因常见的分配是EF队列同时开了priority和WRED。WRED在队列抖动时随机丢弃UDP语音包导致的丢包和抖动比尾部丢弃更不可预测另一种情况是priority带宽上限设得太低比如2%而语音实际占用3%超出的部分被静默丢弃。解决EF队列关闭WRED改成绝对队列上限再把priority百分比调成实时语音带宽的1.5到2倍。验证方法是在拥塞期抓语音流的丢包率目标小于0.5%。如果还丢优先查PIR是不是被接口带宽约束了以及EF队列的优先级有没有被更高级别的控制面流量抢占。5.3 AF多个类别互相挤占CBWFQ保证带宽总和过高现象AF4和AF3都设置了带宽保证拥塞时AF4的延迟和AF3没有明显差异关键事务和普通视频一个待遇。原因路由器的CBWFQ在带宽总和超过100%时会按比例压缩所有类别的保证值而不是优先保护高类别。你配的是AF450%、AF350%拥塞时实际各分到25%优先级无从谈起。解决保证带宽总和控制在70%左右给默认类留出足够空间同时给关键事务类单独提升权重保证它在竞争中的领先地位。配置后用拥塞场景重新打流对比各类别的实际吞吐而不是只看配置数字。5.4 整形后峰值流量依旧CBS设得过大现象配置了shape average限速20Mbps可测速时流量短时间冲到25Mbps且持续了好几秒运营商侧开始丢包。原因CBS承诺突发设得过大。令牌桶允许一次突发到CBS对应的量如果CBS配成10MB那相当于允许瞬时以远超CIR的速率发送很久整形成效约等于零。解决把CBS改回1ms到5ms带宽范围重点关注超过CIR的持续时间而不是瞬时速率。打流验证时用1秒粒度采样观察平均速率是否符合CIR。如果业务真的需要长突发比如视频推流考虑改用trTCM给出独立的PIR而不是无脑调大CBS。5.5 MPLS隧道里DSCP被覆盖EXP映射表没对齐现象从CE接入的业务带AF41经过PE的MPLS隧道后出端CE测到DSCP变成了AF31或0。原因PE上做了二次标记入向映射时把AF41映射到了错误的EXP或者出向还原表没有和入向表对齐。MPLS标签栈里只认EXP出隧道路由器把EXP还原成DSCP时映射关系不同就会乱。解决检查边界设备的diffserv-domain配置入向和出向映射表必须完全对称。映射测试方法是打完流后抓MPLS报文头核对EXP字段再在出端抓IP头核对DSCP。两端不一致就查PE的域配置通常十分钟能定位。6. 验证Diffserv是否生效一组对照实验与三个统计指标6.1 对照实验用打流工具制造拥塞再验证优先级Diffserv是否生效最终要用对照实验证明。我的做法是准备三路流量一路标记EF模拟语音一路标记AF41模拟事务一路是默认BE先在无拥塞时测各自基线带宽和延迟再注入一路不限速的BE大流把接口打满观察三路的延迟、丢包和吞吐变化。工具用iperf或打流仪表都行关键是每一路必须单独跑进程并设置DSCP# 模拟BE背景流打满接口DSCP0 iperf3 -c 10.0.0.2 -u -b 200M -S 0x00 # 模拟语音流DSCP46 (EF) iperf3 -c 10.0.0.2 -u -b 2M -S 0x2E # 模拟事务流DSCP34 (AF41) iperf3 -c 10.0.0.2 -u -b 10M -S 0x22预期结果是拥塞状态下EF延迟仍然低于10ms且不丢包AF41获得其保证带宽但可能出现少量丢弃BE被大量丢弃带宽压缩到剩余空间。如果EF和AF41同时掉速说明队列调度没生效回到前面排查全局开关或策略绑定方向。6.2 三个统计指标队列丢弃计数、队列带宽占用、DSCP分布实验之外设备自身的统计计数能定位问题出在哪个环节。三个指标足够队列丢弃计数能看出丢包发生在队列溢出还是WRED主动丢弃各队列带宽占用确认保证比例在执行DSCP分布统计确认边界标记没在隧道里被改写。流量打起来后看一眼这三个计数器Diffserv链路哪个环节失效基本一目了然。关于Diffserv我的一个习惯是每次改动参数都保留一份改动前后的全量配置和实验结果。打流验证通过后还要再观察24小时真实流量峰值时段和低谷时段的表现才是最终判定标准。配置里的百分比不是调完就算完真实业务流量模型变化很快只有数据能告诉你路由器里的队列是否真的“可知”。希望帮到你。本文还有配套的精品资源点击获取
区分服务Diffserv实战：DSCP标记与队列调度保障关键业务
简介区分服务Diffserv在高性能路由器中的实现是一篇出自中文核心期刊《微计算机信息》的技术文献面向路由器研发、网络运维与QoS学习研究人员。文章从传统尽力而为服务的不足入手对比集成服务Intserv的扩展性瓶颈引出Diffserv在网络边界分类、内部节点转发的体系优势系统阐述数据包分类机制、流量控制与路由调度设计并结合国家863项目“可扩展到T比特高性能IPv4/v6路由器基础平台”的测试验证。压缩包内含单篇PDF文件约199KB内容涵盖Diffserv三种服务质量类别尽力而为BE、奖赏服务EF、保证服务AF与DSCP映射PHB等关键概念也可作为IPv4/v6路由器、网络服务质量方向的参考文献与专业指导。目前已有104人学习适合需要快速掌握Diffserv在路由器中落地思路的技术读者阅读后可了解从数据包标记到队列调度的核心设计路径。1. 区分服务Diffserv在高性能路由器上的落脚点一场拥塞事故的复盘某个周五晚高峰出口链路被视频流量打满语音和ERP事务的延迟飙到300ms。路由器转发能力完全够CPU占用也不高可流量一旦拥塞就“一视同仁”地全部排队。要解决这类问题常见做法是在高性能路由器上启用区分服务Diffserv按业务打上DSCP标号再用队列调度与丢弃策略分等级保障。它解决的不是“带宽不够”而是“带宽分配不公”适合所有需要线速转发的企业网出口和运营商边缘场景。我最初以为Diffserv就是给报文打个标记直到自己把队列、整形、WRED全部配完后打了一轮拥塞测试才发现真正的难点在路由器内部的调度行为有限队列怎么承载五类业务为什么高优先级流量依然会丢包边界和核心设备各自该承担什么动作。这篇文章把我搭建这套方案时的理解、配置手法和踩过的坑完整记录下来。2. Diffserv模型拆解DSCP、PHB与分类计量怎么选才不失控2.1 为什么Diffserv能在高性能路由器上跑起来而Intserv不行在Diffserv之前网络界先提出的是Intserv综合服务它用RSVP信令为每一条应用流预留带宽。思路很完美但要落地在高性能路由器上根本跑不动核心路由器需要为每条流维护状态流数量一多转发表项和定时器就把内存吃光还要逐流做软状态刷新转发性能直接被拖垮。这也是Intserv最后只在小规模网络里存活的原因。Diffserv的思路完全不同它不逐流维护状态而是把流量按类聚合成少量行为集合。路由器转发面只需要看IP头里的DSCP字段按预先配置的PHB逐跳行为来决定放进哪个队列、使用什么丢弃策略。“状态在边界、行为在核心”的设计让中间节点变得极简单天然适合高性能路由器的硬件转发流水线。这也是区分服务Diffserv成为企业网和运营商实际部署标准的核心原因。在搭建这套体系前要先区分两个角色边界路由器负责“分类标记计量整形”核心路由器只负责“按标记调度丢弃”。边界设备通常要处理复杂ACL和应用识别性能瓶颈在策略匹配核心设备要处理聚合后的海量流量性能瓶颈在队列调度。理解这个分工后续所有配置才不容易做反。如果反过来让核心路由器做深度分类线速转发会立刻变成CPU转发。2.2 DSCP编码与PHBEF、AF、CS、BE各管哪一类业务DSCP差分服务代码点占用IP头TOS字段的高6位共64个码点。为了运维可读实际部署不会用全64个而是用RFC 2474、RFC 2597、RFC 3246定义的标准PHB集合。这里要把“DSCP值”和“PHB行为”分开记DSCP是报文里的标号PHB是路由器针对这个标号执行的动作集合。EFExpedited ForwardingDSCP 46提供低延迟、低抖动、低丢弃的“管道式”服务适合语音和实时视频通常配合LLQ严格优先队列。AFAssured Forwarding分为AF1到AF4四类每类内部又有三个丢弃等级比如AF41、AF42、AF43适合企业内部不同重要程度的业务。CSClass Selector兼容旧IP优先级便于从老网络平滑迁移。BEDSCP 0是默认尽力而为。PHBDSCP典型值适用业务队列丢包策略要点EF46语音、实时协作严格优先需限制带宽上限AF434/36/38关键事务、ERP带宽预留WRED按丢弃等级逐级丢弃AF326/28/30视频会议/直播带宽预留容忍一定抖动AF218/20/22一般业务、数据库中等带宽保障AF110/12/14批量传输、备份低带宽保障可被更高等级抢占CS6/CS748/56网络控制面只给协议报文不分配给业务BE0默认流量使用剩余带宽WRED早丢弃上表的分配方式是业界最常见的模板实际规划时要注意一个原则标记类别不要超过6至8个。很多项目一上来就设计了12个AF子类真实配置时会发现队列资源根本不够硬件队列通常只有8到16个强行细分会造成多个PHB共用队列优先级互相干扰。我一般建议企业网按“语音、视频、关键事务、一般业务、批量、默认”六类设计数量正好对应典型硬件队列数。实际组网里还涉及和二层优先级的映射。业务从接入交换机进入路由器时802.1p优先级需要先映射成DSCP否则标记只能在三层边界重新做一遍。常见做法是802.1p 5映射到EF、4映射到AF41、3映射到AF31。这一步如果没做接入层的视频流量在路由器上会被当成BE处理后面所有队列设计都白搭。我在设计Diffserv域时会把二三层映射表一起规划。2.3 分类器与计量器MF分类、BA分类和两种令牌桶的适用边界分类发生在流量进入Diffserv域的那一刻。边界路由器用MF多字段分类器通过五元组、应用端口或应用识别把流量归入某个业务等级。核心路由器不需要重新看五元组直接读DSCP做BA行为聚合分类原因是五元组查表在核心节点要做更多匹配动作会拉低线速转发性能。计量器负责判断流量是否超过约定速率。常见做法是单速率三色标记srTCM和双速率三色标记trTCM。srTCM用一个CIR承诺信息速率加CBS承诺突发判断报文标绿、标黄或标红适合对带宽上限严格要求但不关心峰值突发的业务trTCM在CIR之外再给一个PIR峰值信息速率允许短期突发适合视频和Web类流量。这里有个容易误用的点计量器的作用并不只是限速它还承担“重新标记”职责。超出CIR的报文不是简单丢弃而是被标记成低一级的DSCP或黄色路由器在拥塞时优先丢弃黄色报文。这样业务的整体体验是平滑降级而不是瞬间中断。如果直接丢弃超限报文语音和事务类业务会频繁闪断这就是为什么计量后通常还要接一个“标记动作”而不是“丢弃动作”的原因。还有一点计量器最好放在边界核心节点不做计量。核心节点要求快对每个报文做令牌桶操作也会消耗硬件配额。虽然部分高性能路由器可以线速计量但部署成本都会反映在设备选型上。计量放边界、调度放核心这个分工能让你用最少的硬件资源换取最清晰的QoS行为。3. 高性能路由器的队列调度从LLQ到WRED带宽比例与丢弃阈值怎么调3.1 队列架构与硬件转发为什么调度必须做在芯片里Diffserv的最终效果不是标记完成那一刻决定的而是在出接口拥塞时由调度器决定。高性能路由器之所以能同时跑满多线卡流量核心在于转发和调度都在专用芯片内完成流量进入端口后先按DSCP查映射表进入对应队列再由硬件调度器按配置好的权重和优先级把报文从队列取出。这个过程要是放到CPU里做线速转发马上就变成线速丢包。所以看一台路由器能不能扛住Diffserv不要只看它支持多少个类要看队列资源和调度精度。常见实现是每端口8至16个硬件队列队列深度以KB或MB为单位可调。配置时思考的是“队列怎么映射到PHB”和“每个队列分配多少带宽”而不是软件模拟队列那些花哨算法。转发芯片的调度粒度通常能做到64Kbps甚至更低带宽占比控制得越细AF类业务的区分度就越好。另一个常被忽略的点是内存缓冲。高性能路由器普遍采用VoQ虚拟输出队列或共享内存池队列深度决定突发吸收能力。调度算法可以保证带宽比例但如果所有队列都被填满丢包依然会发生。配置前先查一下设备的“队列深度上限”和“最大缓冲”这两个数字直接影响后续所有WRED阈值设计。3.2 LLQCBWFQ优先级和带宽比例怎么分配才不互相挤占队列调度最经典的组合是LLQ低延迟队列加CBWFQ基于类的加权公平队列。LLQ给EF语音流一个严格优先级保证它先于其他所有队列被调度与此同时又必须给EF队列设一个带宽上限百分比或绝对值防止语音或恶意流量挤占全部带宽。这个“严格优先限速”的组合是语音不卡顿的关键。下面是一段典型配置写在边界路由器的出方向class-map match-any CLASS-EF match dscp ef class-map match-any CLASS-AF4 match dscp af41 af42 af43 class-map match-any CLASS-AF3 match dscp af31 af32 af33 policy-map WAN-OUT class CLASS-EF priority percent 20 // LLQ严格优先带宽上限20% class CLASS-AF4 bandwidth percent 30 // CBWFQ保证带宽30% queue-depth 512 // 队列长度限制 class CLASS-AF3 bandwidth percent 20 // 视频类带宽保证20% class class-default fair-queue // 剩余流量走尽力而为这里priority percent 20的含义是该队列可以获得严格优先调度但它自身的速率不会超过接口带宽的20%。注意这不是“预留20%”而是“最多20%”EF流量少时剩余带宽依然能分给其他类使用。bandwidth percent 30则是承诺带宽AF4队列在拥塞时至少能拿到30%如果它没用到剩余带宽也可以被其他类借用。带宽百分比加起来不建议超过90%留出10%给协议报文和链路开销否则控制面报文在拥塞时也会被业务流量挤掉。带宽分配比例怎么定常见做法是先统计一周的流量模型。语音按并发通话数折算G.711一路约80Kbps100路并发就是8Mbps视频和事务类按业务SLA填批量类给剩余。最忌不加分析就按“语音20%、视频30%、事务40%”拍脑袋上线后大概率要返工。注意LLQ里EF队列不要开WRED语音是UDP随机丢包只会制造抖动。EF队列的处理是把队列上限设死超出即丢让语音流始终走最短路径。3.3 WRED阈值AF类内部的三个丢弃等级怎么设拥塞避免是Diffserv里最容易配错的一环。WRED加权随机早期丢弃在队列变深时按概率先丢低优先级报文避免全队列填满后的尾部丢弃导致所有流一起受损。参数有三个核心最小阈值、最大阈值、丢弃概率分母。队列长度低于最小阈值不丢包达到最大阈值时丢弃所有到达报文。class CLASS-AF4 bandwidth percent 30 random-detect dscp-based random-detect dscp af41 32 48 100 random-detect dscp af42 24 40 100 random-detect dscp af43 16 32 100这段配置把AF4类内的三个丢弃等级分别设置了阈值。af41最重要在队列长度32到48之间开始随机丢弃af43最不重要在16到32之间就开始丢。这样拥塞加深时先牺牲等级低的流量保住等级高的流量。100是丢弃概率分母表示队列达到最大阈值时理论丢弃概率为1/100调小比如50会让丢弃更激进。调节WRED阈值时要结合队列深度。如果把WRED最大阈值设成64而队列深度上限是128那队列还剩一半时就已经开始丢弃带宽利用率会被压低。一般做法是最小阈值设为队列深度的1/4到1/3最大阈值设为2/3到3/4给突发留出缓冲。千万别把最大阈值直接设成队列上限那样WRED和尾部丢弃会同时触发丢包行为会变得不可控。WRED对TCP和UDP的行为差异也要记牢。TCP流遇到丢包会退避重传所以WRED对AF类的TCP业务效果很好UDP视频流不会退避被随机丢弃后就是画面劣化。因此对视频类AF3队列我倾向不启用WRED只做带宽保证或者把WRED阈值设得很接近队列上限只在极端拥塞时才丢。4. 边界节点的Diffserv动作分类标记、令牌桶整形与隧道透传4.1 入向分类标记从ACL到DSCP的映射规则写法Diffserv域入口是边界设备它要完成“识别业务并打标”的职责。常见做法是在入方向做基于类的策略先定义class-map匹配条件再定义policy-map执行标记动作最后应用到入接口。匹配条件可以基于五元组、应用端口、甚至应用识别结果。下面是个实例class-map match-any MARK-SIP match udp dst-port 5060 class-map match-any MARK-HTTPS match protocol https class-map match-any MARK-DB match ip dscp default policy-map IN-MARK class MARK-SIP set dscp ef class MARK-HTTPS set dscp af41 class MARK-DB set dscp af21 class class-default set dscp default入向标记配置对转发性能影响最大的是match protocol这类深度包检测。高性能路由器做应用识别通常依赖硬件加速普通设备会绕到CPU导致吞吐骤降。我在实际项目里会尽量在接近业务源头的位置做分类比如在接入交换机或上层设备完成应用识别路由器只按已经标记好的DSCP做BA分类。这样边界路由器的入向策略不需要跑复杂ACL线速能力才保得住。标记动作还有一个容易忽略的细节重标记。当路由器同时收到上游已经带DSCP的流量时不能盲目覆盖。常见做法是对未标记流量dscp default做映射对已有标记的流量则尊重上游设定。上面的配置里对DB类专门匹配了dscp default就是为了避免把内部已标好的AF31误改掉。4.2 出向整形CIR、CBS、EBS的计算与配置边界路由器在出方向通常要做整形目的是把流量控制在运营商承诺的速率以内避免突发被运营商惩罚。整形的实现是令牌桶报文要发送前先检查桶里有没有令牌有就放行没有就排队等待。所以整形和限速不同整形平滑突发限速直接丢弃。policy-map SHAPE-WAN class class-default shape average 20000000 service-policy output WAN-OUT这段配置把出向速率整形成20Mbps同时叠加了之前定义的调度策略。令牌桶参数CBS承诺突发在这里决定报文可以瞬时冲出多少数据。CBS太小短暂的流量尖峰会被削平表现为吞吐上不去CBS太大又会把突发传导给上游失去整形的意义。经验公式是CBS取值在CIR的1ms到5ms带宽之间20Mbps线路取12500到62500字节实际配置往往取16000或32000。计算时还要考虑链路层开销。Ethernet帧头14字节、FCS 4字节、VLAN标签4字节这些都不计入IP层速率但实际占用物理链路。如果运营商承诺的CIR是20Mbps而路由器按IP报文统计整形到20Mbps加上开销后实际已经到了20.5Mbps。所以我一般会按CIR的95%配置整形速率给三层到二层的封装留出余量。4.3 隧道与MPLS场景DSCP透传规则和EXP映射Diffserv域跨越隧道时最常出问题的是DSCP怎么穿过封装。GRE和IPsec隧道会新增外层IP头默认情况下内层DSCP不自动复制到外层如果外层DSCP被设为0流量经过中间路由器时相当于没标记。这是很多“两端都配好了中间却失效”的根因。MPLS场景同理但机制稍有不同。MPLS报文头里没有DSCP用的是EXP字段。常见做法是边界路由器把入向DSCP映射到EXP核心路由器按EXP调度出边界再把EXP还原成DSCP。配置要点是保证“入向映射表”和“出向还原表”保持一致否则业务流入MPLS域后被重新标记端到端SLA就失真了。diffserv-domain WAN-MPLS dscp ef exp 5 dscp af41 exp 4 dscp af31 exp 3 dscp af21 exp 2 dscp default exp 0这段是主流的域配置风格不同厂商命令略有差异。重点不是记命令而是理清映射原则边界设备负责DSCP与EXP转换核心设备只认一种标记体系。如果核心设备已经支持基于DSCP调度则MPLS EXP映射只需要在边界做一次不需要每台设备反复改。还有MPLS TP和伪线场景下原始IP头被完全隐藏此时必须依赖EXP透传这一步在规划Diffserv域时就要考虑不然标签多一层整个QoS链就断了。5. Diffserv落地避坑五条现场排查记录5.1 标记了DSCP但队列不生效全局QoS开关没打开现象接口上配了policy-mapclass-map匹配也正确但打流测试时所有流量还是一个队列在走高优先级完全没效果。原因很多路由器的QoS功能默认是关闭的单接口下发策略不会自动启用全局调度。有的平台还需要在系统模式下开启qos enable或者把接口从“默认优先级模式”切换到“QoS模式”。解决先在全局视图下确认QoS开关再检查接口下是否绑定了service-policy方向不能弄反。入向标记策略绑input出向调度策略绑output这两个方向错一位整个Diffserv就白配了。排查时用display qos policy interface或show policy-map interface看接口下实际生效的统计能立刻发现问题。5.2 语音流在拥塞时仍然丢包EF队列的带宽上限和WRED冲突现象EF队列的标记和调度都配了拥塞一发生语音先丢包MOS分直接掉到3以下。原因常见的分配是EF队列同时开了priority和WRED。WRED在队列抖动时随机丢弃UDP语音包导致的丢包和抖动比尾部丢弃更不可预测另一种情况是priority带宽上限设得太低比如2%而语音实际占用3%超出的部分被静默丢弃。解决EF队列关闭WRED改成绝对队列上限再把priority百分比调成实时语音带宽的1.5到2倍。验证方法是在拥塞期抓语音流的丢包率目标小于0.5%。如果还丢优先查PIR是不是被接口带宽约束了以及EF队列的优先级有没有被更高级别的控制面流量抢占。5.3 AF多个类别互相挤占CBWFQ保证带宽总和过高现象AF4和AF3都设置了带宽保证拥塞时AF4的延迟和AF3没有明显差异关键事务和普通视频一个待遇。原因路由器的CBWFQ在带宽总和超过100%时会按比例压缩所有类别的保证值而不是优先保护高类别。你配的是AF450%、AF350%拥塞时实际各分到25%优先级无从谈起。解决保证带宽总和控制在70%左右给默认类留出足够空间同时给关键事务类单独提升权重保证它在竞争中的领先地位。配置后用拥塞场景重新打流对比各类别的实际吞吐而不是只看配置数字。5.4 整形后峰值流量依旧CBS设得过大现象配置了shape average限速20Mbps可测速时流量短时间冲到25Mbps且持续了好几秒运营商侧开始丢包。原因CBS承诺突发设得过大。令牌桶允许一次突发到CBS对应的量如果CBS配成10MB那相当于允许瞬时以远超CIR的速率发送很久整形成效约等于零。解决把CBS改回1ms到5ms带宽范围重点关注超过CIR的持续时间而不是瞬时速率。打流验证时用1秒粒度采样观察平均速率是否符合CIR。如果业务真的需要长突发比如视频推流考虑改用trTCM给出独立的PIR而不是无脑调大CBS。5.5 MPLS隧道里DSCP被覆盖EXP映射表没对齐现象从CE接入的业务带AF41经过PE的MPLS隧道后出端CE测到DSCP变成了AF31或0。原因PE上做了二次标记入向映射时把AF41映射到了错误的EXP或者出向还原表没有和入向表对齐。MPLS标签栈里只认EXP出隧道路由器把EXP还原成DSCP时映射关系不同就会乱。解决检查边界设备的diffserv-domain配置入向和出向映射表必须完全对称。映射测试方法是打完流后抓MPLS报文头核对EXP字段再在出端抓IP头核对DSCP。两端不一致就查PE的域配置通常十分钟能定位。6. 验证Diffserv是否生效一组对照实验与三个统计指标6.1 对照实验用打流工具制造拥塞再验证优先级Diffserv是否生效最终要用对照实验证明。我的做法是准备三路流量一路标记EF模拟语音一路标记AF41模拟事务一路是默认BE先在无拥塞时测各自基线带宽和延迟再注入一路不限速的BE大流把接口打满观察三路的延迟、丢包和吞吐变化。工具用iperf或打流仪表都行关键是每一路必须单独跑进程并设置DSCP# 模拟BE背景流打满接口DSCP0 iperf3 -c 10.0.0.2 -u -b 200M -S 0x00 # 模拟语音流DSCP46 (EF) iperf3 -c 10.0.0.2 -u -b 2M -S 0x2E # 模拟事务流DSCP34 (AF41) iperf3 -c 10.0.0.2 -u -b 10M -S 0x22预期结果是拥塞状态下EF延迟仍然低于10ms且不丢包AF41获得其保证带宽但可能出现少量丢弃BE被大量丢弃带宽压缩到剩余空间。如果EF和AF41同时掉速说明队列调度没生效回到前面排查全局开关或策略绑定方向。6.2 三个统计指标队列丢弃计数、队列带宽占用、DSCP分布实验之外设备自身的统计计数能定位问题出在哪个环节。三个指标足够队列丢弃计数能看出丢包发生在队列溢出还是WRED主动丢弃各队列带宽占用确认保证比例在执行DSCP分布统计确认边界标记没在隧道里被改写。流量打起来后看一眼这三个计数器Diffserv链路哪个环节失效基本一目了然。关于Diffserv我的一个习惯是每次改动参数都保留一份改动前后的全量配置和实验结果。打流验证通过后还要再观察24小时真实流量峰值时段和低谷时段的表现才是最终判定标准。配置里的百分比不是调完就算完真实业务流量模型变化很快只有数据能告诉你路由器里的队列是否真的“可知”。希望帮到你。本文还有配套的精品资源点击获取