干过网络的人应该都知道网络卡顿排查到最后的归宿往往不是带宽不够而是“优先级”没人管。尤其语音、视频会议、关键业务和下载流量混在一起跑的时候设备对着满队列的数据包往往一脸茫然——到底先转发谁这时候DSCP标记就派上用场了。它其实就是IP报文头里那6个比特用来告诉沿途每一台设备“我这个包是语音别给我乱丢那个包是下载实在不行先丢它。”这6个比特看似简单但它在差分服务DiffServ模型里是核心中的核心没有DSCP标记后面所有关于队列调度、拥塞避免、带宽保障的策略都无从谈起。这篇文章我想完整聊一聊DSCP标记的设计思路、常用码点取值、端到端的配置手法以及我在实际项目里踩过的那些坑。无论你是刚接触QoS的入门工程师还是正在做园区网、广域网优化的老手这篇应该都能帮你少走弯路。1. DSCP到底在管什么从IP头里的8个比特说起1.1 ToS字段的演进与DSCP的由来IP报文头里有个字节历史上叫ToSType of Service服务类型字段总共8个比特。最早的设计是把前3个比特叫作IP优先级IP Precedence从0到7一共8个等级。3个比特只能表达8种“重要程度”这在早期网络里勉强够用但随着语音、视频、以及越来越复杂的应用出现8个等级很快就捉襟见肘了。更麻烦的是不同厂商对“优先级6”“优先级7”的理解并不一致有的拿去做路由协议控制面有的干脆给数据面用跨厂商组网时经常鸡同鸭讲。后来RFC 2474对ToS字段做了重新定义取前6个比特作为DSCPDifferentiated Services Code Point差分服务代码点后2个比特留给ECN显式拥塞通知使用。6个比特意味着最多可以定义64个码点从0到63。这件事的本质变化其实不只是“等级变多了”而是“含义标准化了”。DSCP不再像IP Precedence那样只是告诉你“这个包很重要”而是告诉你“这个包对应的转发行为是什么”是低延迟、低丢包的EF还是分等级、可丢弃的AF还是全力而为的BE路由器看到标记就知道该往哪个队列里放、丢包时按照什么概率去丢。1.2 DiffServ模型的核心理念边界做标记核心做转发如果只把DSCP当成“优先级字段”看那就小看它了。差分服务DiffServ的整个设计哲学是在网络边缘做复杂的分类和标记在网络核心只做简单的调度和丢弃。换句话说接入层设备要学会“察言观色”——识别应用、打标、重写核心设备就不用想那么多只看DSCP值按预定义的PHBPer-Hop Behavior逐跳行为处理。这套思想可以用快递行业来类比。你寄件的时候快递网点的人负责验视包裹、称重、贴上“易碎”“加急”“生鲜”之类的面单标签之后包裹进入分拨中心和干线运输分拣员不关心里面装的是什么只看面单标签就知道该把它放进哪个筐、装哪辆车。如果每个分拨中心都要重新拆包验货整个物流体系早就瘫痪了。DSCP就是网络世界里的那张贴纸分类的“验货动作”只在网络边界做一次中间设备高效转发。这个设计相比更早的IntServ综合服务模型优势非常明显IntServ需要为每一条流在沿途设备上预留状态核心路由器要为每个会话维护资源信息在大规模网络上根本撑不住。DiffServ则是让核心设备保持“无状态”只管按照标记干活扩展性一下子就好了。不过这里必须说清楚一件事DSCP标记本身不等于QoS。完整的QoS链路至少包括分类、标记、队列调度、拥塞避免、限速这五个环节。DSCP只负责“标记”这一环它做得再好后面没有队列调度配合、没有丢弃策略兜底那也只是一张贴纸贴在包裹上分拨中心不认识或者干脆不执行照样白搭。理解这一点后面才不会把方案想得太简单。2. DSCP的常用标记值从0到63该怎么选2.1 一张表快速掌握常用码点DSCP总共64个码点实际项目里常用的其实就二十多个。我先把最核心的几类列个表大家后面查起来也方便类别值十进制二进制高6位典型用途Default / BE0000000普通上网、下载、后台流量尽力而为CS18001000低于BE的背景流量或用于某些网络管理CS216010000一般用于OAM/网管类流量CS324011000某些信令类流量或园区内部预留CS432100000实时交互类业务的备选标记CS540101000视频/语音的一种过渡标记CS648110000路由协议、网络控制面流量比如BGP/OSPF/IS-ISCS756111000最高级控制面一般用于设备紧急管理AF11 / AF12 / AF1310 / 12 / 14001010/001100/001110一类业务三个丢弃优先级AF21 / AF22 / AF2318 / 20 / 22010010/010100/010110二类业务比如重要数据AF31 / AF32 / AF3326 / 28 / 30011010/011100/011110三类业务比如呼叫信令、关键交易AF41 / AF42 / AF4334 / 36 / 38100010/100100/100110四类业务比如会议视频EF46101110低延迟低丢包语音媒体流首选这张表看着数值很多其实规律非常清晰AF类码点由“类别”1到4和“丢弃优先级”1到3组成格式就是AFxy。比如AF41代表第4类、丢弃优先级为1翻译成人话就是“这一类里最不能丢的”。每类内部数值越大丢包概率越高AF13比AF11更容易被丢弃。2.2 EF为什么偏偏是46很多初学者都会问EF直接等于46这个数字怎么来的不能随便挑一个吗当然不是随便挑的。EF的标准定义是RFC 3246选择46这个码点其实是刻意为之。46的二进制是101110它高3位是101也就是十进制的5。对照老的IP Precedence5对应的是以前预留的最高用户优先级。之所以要把高3位设计成101是为了兼容那些只认识旧IP Precedence字段的老设备即便一台老路由器看不懂DSCP它也能从高3位看出这流量等级不低不至于一上来就给丢掉。EF在排队设计上目标非常明确——低延迟、低抖动、低丢包它对应的就是话音媒体流这类对实时性要求极高的流量。还有一个细节值得注意EF没有选择43或者47而是选了46目的就是让它和老的控制面优先级CS6值48错开。控制面流量比如BGP、OSPF这类路由协议报文需要在极端拥塞时仍然可达但它和多媒体数据流的“实时”语义不同。把EF放在46而不是48、56就是明确地告诉网络设备用户实时业务不要占用控制面的最高优先级否则一旦数据面霸占最高队列出故障时路由协议都被卡住整个网络就真“叫天天不应”了。2.3 AF组的三个丢弃等级到底解决什么问题AF类的设计精妙之处在于它把“重要性”和“可丢弃性”拆成了两个维度。同样是视频会议业务主讲人画面、共享屏幕和录制备份的优先级显然不该一样。如果一刀切全部标EF拥塞时每个包对网络“同等重要”的诉求会让队列瞬间膨胀——收效未必好还容易造成语音抖动。用AF组就能做到给不同子流量打不同丢弃优先级网络发生拥塞时用WRED加权随机早期检测先丢那些低等级的包保住核心内容。比如视频会议里画面数据标AF41内容共享标AF42文件传输/录制流标AF43。拥塞一发生AF43先被丢弃AF42次之AF41能坚持到最后一刻。这样业务的体验是一种“逐渐降级”而不是“瞬间全断”用户感知会好很多。AF组还有一个实际好处WRED对同一类AF的不同丢弃等级可以使用不同的丢包曲线这让网络在拥塞时具备“弹性”。如果你连这个维度都不设计路由器面对拥塞时只能一刀切所有同一类包一起丢那用户的体感就是会议画面卡成PPT之后直接断线。2.4 CS类码点的取舍建议CS类其实就是把旧的IP Precedence左移3位得到的码点所以CS1到CS7分别对应8、16、24、32、40、48、56。它最大的作用是“兼容”和“控制面”。我个人的经验是CS6/CS7最好只用于设备之间的路由协议报文、网管报文这类控制面流量不要让普通业务报文打CS6/CS7。理由有两点第一很多核心设备对CS6/CS7的队列处理策略和控制面保护机制是绑定在一起的用户流量混进去极有可能触发控制面管制第二一旦你把某个数据流标成CS7在网络拥塞时它会比路由协议还“优先”万一这个流本身有突发反而会挤掉关键控制报文。这属于给自己埋雷。CS1这类低于BE的码点也很有用。我经常把内部的文件备份、日志上报、非关键监控流量统一标CS1这样在网络拥塞时它们会被优先丢弃而不是和办公上网流量抢带宽。很多团队在方案设计时只盯着“怎么让重要业务更优”忽略了“怎么让不重要的业务更低”其实CS1就是干这个的别浪费。3. 端到端DSCP方案设计信任边界、映射与设备配置3.1 先定信任边界再谈标记做DSCP方案最容易犯的错误就是一上来就配命令。真正动手之前必须先回答一个问题网络里哪些设备、哪些端口打上来的DSCP值我们选择相信这就是“信任边界”Trust Boundary。简单说设备是否直接采信入向报文的DSCP还是把所有入向报文一律重写成默认值再由本地策略重新打标。信任边界如果画得太靠内比如在整个园区都信任终端的DSCP那任何一台被攻破或配置错误的PC都能给自己打上EF拥塞时全网语音队列被垃圾流量塞满。信任边界如果画得太靠外比如连语音网关发给交换机的话音流量都不信任那交换机还得通过ACL重新识别语音配置量巨大不说识别效率和准确性都受影响。我目前比较推荐的做法是接入交换机面向用户PC的端口一律不信任DSCP默认把入向流量先改写成默认值0再通过ACL按应用特征分类、打标面向IP话机、视频会议终端这类专用设备的端口可以信任它们自带的标准标记因为专用设备打的标记一般符合标准不会乱来面向服务器接口的流量要看服务器上有没有跑特殊应用通常先在服务器侧或接入交换机上按五元组打标。边界问题想清楚后面配置才有依据。3.2 典型接入与核心的标记与重写配置我先描述一个典型的园区网场景某制造企业园区出口是1Gbps的专线内部有语音、视频会议、ERP系统和普通上网。规划如下语音电话标记EF视频会议标记AF41ERP系统标记AF31内部文件备份标记CS1其余全部保持默认值BE。接入交换机上对面向PC的端口做入方向策略匹配不同应用特征改写DSCP。这里我用常见的命令行风格做个示意具体关键字以自己手头设备手册为准# 入方向匹配IP话机地址段并标记EF traffic classifier VOICE if-match acl 3001 // 匹配话机网段 traffic behavior MARK_EF remark dscp ef traffic policy INPUT_POLICY classifier VOICE behavior MARK_EF # 接口下应用同时关闭信任 interface GigabitEthernet0/0/1 trust dscp disable // 不信任终端标记 traffic-policy INPUT_POLICY inbound核心设备上面向出口的物理接口做队列调度策略根据DSCP把流量映射到不同队列class-map match-any EF_QUEUE match ip dscp ef class-map match-any AF41_QUEUE match ip dscp af41 class-map match-any AF31_QUEUE match ip dscp af31 policy-map WAN_OUT class EF_QUEUE priority percent 10 police cir 100000000 // 防止EF队列被滥用 class AF41_QUEUE bandwidth percent 20 class AF31_QUEUE bandwidth percent 30 class class-default bandwidth percent 35 random-detect // 对BE启用WRED这里有个细节要特别提醒标签标记通常是在“入方向”做的因为数据包一进入网络我们就要决定它享受什么待遇而队列调度、拥塞管理是在“出方向”做的因为拥塞总是发生在接口发出的那一刻。这两个方向如果搞反配置会莫名失效而且排查起来相当痛苦。3.3 队列调度和丢弃策略必须跟DSCP配合起来标记只是“说”这个包重要队列调度才是“做”。接口拥塞时设备靠队列决定先送谁、后送谁、丢谁。通常EF类流量放进优先级队列PQPQ的特点就是只要队列里有包就先把它送出去。这保证了语音的低延迟但PQ是“霸道的优先级”必须配一个管制器police限制EF流量总量否则语音和伪语音流量会把后面的队列饿死。AF类流量一般放入CBWFQ基于类的加权公平队列每个类可以配置保证带宽bandwidth percent拥塞时各类按权重分享剩余带宽。实现拥塞避免时对AF类和BE类启用WREDAF内部使用三个不同丢弃等级让AF43比AF41更容易被丢弃BE则按默认曲线丢弃让后台大流量成为拥塞时的“牺牲品”。再放一组我常用的带宽规划参考在1Gbps出口上EF预留10%按实际并发话路计算一般100路语音需要10Mbps左右留10%已经很充裕AF41预留20%AF31预留30%CS6/CS7预留5%剩下的给BE。这里计算的关键不是“数字越大越好”而是“保证带宽的总和不能超过接口实际带宽”。有些设备对百分比会自动换算但你自己心里要对每条业务的实际流量模型有数。还有一点很有意思调度策略并不是非要在核心设备的出接口上做。如果你的园区出口路由器上同时接了几条链路必须确认每个出接口都挂了同样的策略或者至少关键的出接口都挂了。我见过只优化了主链路、备份链路完全裸奔的案例平时没事主备切换时语音直接全断。这种“备份链路没策略”的坑比DSCP本身配置错误更隐蔽。3.4 不同网络场景下的DSCP映射要点DSCP不是在所有网络里都能原样透传的跨二层、跨无线、跨MPLS、跨Overlay隧道时都要处理映射关系。二层VLAN场景报文在交换机之间传递时如果走的是Trunk口可以去信任802.1p优先级即VLAN头里的User Priority也可以按DSCP重新映射。纯二层组网通常建议把信任点设在接入交换机这样从接入往上走Trunk里的优先级已经一致不容易乱。无线场景Wi-Fi报文在无线侧用的是WMMWi-Fi多媒体的User PriorityAP收到无线报文时要把UP映射成DSCP反过来AP从有线口收到带DSCP的报文转发到无线侧时也要映射成UP。很多AP默认会把所有非语音流量映射成最低UP某一天你发现手机上的视频会议画面卡到不行抓包一看DSCP确实是EF但AP映射时把它降成了普通数据那问题就出在这个映射环节。MPLS场景MPLS报头里的实验位EXP现在叫Traffic Class用来标记优先级。IP报文进入MPLS网络时PE设备通常会把DSCP复制到EXP如果在P核心设备上要做队列调度那就必须看EXP而不是外层看不到的IP DSCP。这里最常见的问题是对端运营商没有把EXP映射好导致IP侧和MPLS侧优先级脱节。Overlay隧道场景GRE、IPSec、VXLAN这类封装会把原始IP报文包进新IP报文里外层IP头的DSCP默认是0还是复制内层完全取决于封装实现。很多默认行为是“不复制”甚至有些老版本干脆置零。在这种情况下中间网络只能看到外层IP头内层DSCP再漂亮也不会被感知。解决办法一般是在隧道接口上开启预分类pre-classify或者配置DSCP复制让外层继承内层标记。这块我后面还会专门讲。4. DSCP落地中的坑与排查实录4.1 现象一抓包看到DSCP全是0但配置明明标记了有一次我在一个园区网络里排查视频会议卡顿终端上抓包看到报文DSCP确实是AF41可是到了汇聚交换机再抓DSCP居然变回了0。配置检查了一遍又一遍标记策略明明生效了问题在哪儿后来逐跳打点才发现问题出在接入交换机上从接入到汇聚用了Trunk口汇聚交换机在这个Trunk口上配置了“不信任入向DSCP”把收到的所有报文优先级全部重写成默认值。这其实就是一个信任边界设置的问题——接入设备打了标汇聚设备不相信又给擦掉了。排查思路其实很简单从源到目的逐跳抓包看DSCP在哪一跳消失然后检查那一跳的端口信任关系和QoS策略方向。很多时候不是你标错了而是别人在下一跳把你的标记擦了。4.2 现象二隧道流量优先级失效某次做跨地域网络优化业务通过GRE隧道互联语音流量在隧道两端都打了EF但中间链路的拥塞还是影响了语音质量。抓包一看隧道外层IP头的DSCP是0内层IP头是46。中间路由器根本不看内层头的DSCP它只知道外层是一个普通IP包于是语音和大量数据一起在队列里排队。这种问题的修复方式要看是哪种隧道。如果是GRE隧道一般需要在隧道接口上开启预分类让隧道接口能够看到内层IP头的信息并把内层DSCP复制到外层如果是IPSec隧道涉及加密和封装通常要配置QoS预分类或者选择保留DSCP的封装参数如果是VXLAN这类Overlay网络则要看VTEP设备是否支持把内层DSCP复制到VXLAN/UDP/IP外层。核心原则就一条中间网络只能看到外层报文头所以优先级必须体现在外层头里。我前面反复强调这个因为在实际项目里遇到的频率实在太高了。4.3 现象三EF队列反而把网络搞抖了有些团队喜欢把“重要的流量”统统标成EF视频标EF语音标EF核心交易也标EF。结果就是拥塞时PQ队列被塞满后面CBWFQ里的关键业务反而得不到服务网络更抖了。EF的标准定位就是“带宽小、延迟低、必须优先”的实时业务典型就是语音RTP流。视频会议带宽需求很大不分青红皂白全标EF会让PQ队列带宽消耗很高反而增大语音抖动风险。正确的做法是语音媒体流用EF视频会议根据重要性用AF41/AF42关键交易用AF31/AF32网络控制面用CS6。普通流量用BE后台垃圾流量用CS1。这样一个码点一层用途真正做到各司其职。EF队列务必配置police把进入PQ的突发流量限制住否则任何一次异常突发都能瞬间击穿全网QoS设计。4.4 现象四无线环境手机业务优先级丢失还有一个很常见的坑在无线侧。手机连接Wi-Fi打电话或开会报文从手机发出时WMM的UP值一般是根据应用自行设置的但部分手机厂商的实现并不规范很多报文到了AP之后UP值全是0。AP把无线流量转成有线流量时需要根据UP映射成DSCP如果UP是0映射出来的DSCP自然是0。此时有线侧再怎么配置EF队列它也匹配不到这些语音报文因为它们在源端就已经丢标了。这类问题的解法通常是在AP或无线控制器上做“重打标”策略根据报文的应用特征比如SIP端口号、RTP端口范围、以及目标IP地址段重新对无线流量分类匹配语音的报文统一设置DSCP为EF匹配视频的统一设置AF41。不要指望终端自己会给你打一个完美的标记无线环境里终端各行其是的概率极高。真要做企业级无线语音接入侧重写几乎是必经之路。4.5 常见问题速查表最后把我在项目中反复遇到的DSCP问题整理成一个速查表方便大家定位现象可能原因排查/解决手段抓包看到DSCP0接入端口不信任、上行端口重写、ACL未匹配逐跳抓包定位消失点检查trust配置检查入向策略是否生效隧道流量无优先级封装外层DSCP未复制/inner head不可见在隧道接口开预分类或配置DSCP复制查看封装实现说明语音时好时坏EF队列被占用/police未配置检查EF队列深度和丢弃计数为EF配置police和带宽约束视频会议卡顿但语音正常视频标EF或AF映射错误把视频改为AF4x按丢弃等级区分不要和语音共用EF无线手机流量全部BEWMM UP映射不当或终端未打标在AP/AC上按应用重打DSCP重新梳理DSCP到UP映射表二层Trunk后优先级丢失汇聚设备信任/重写策略覆盖了接入标记统一信任链路的策略口径确定单一信任点跨运营商QoS失效运营商侧的标记被清/重写在运营商网络边界再次标记与对端明确DSCP策略5. 关于DSCP项目实施我的几点个人体会做这套东西做久了越来越觉得DSCP的难点从来不在“怎么配命令”而在于你到底愿不愿意、能不能信任整条链路上的每一个节点。你在这头费尽心思打了EF中间一台设备随手就给你清零整个方案就是白做。所以真正靠谱的做法是在项目规划阶段就把“信任边界”画清楚并且把每一级设备上的标记、信任、映射、调度策略全部列成一张表逐台核对。这比装机时现场拍脑袋写ACL可靠得多。我个人的小心得是平时做任何网络排障抓包时先看一眼IP头的DSCP值再往下查往往会省掉大量时间。很多所谓的“线路质量差”“设备性能不行”追到根上就是DSCP在某处被改写成0或者被标错类别。养成看标记的习惯以后你会发现网络拥塞时的表现其实非常“讲理”——它完全按照你贴的标签在做事。贴对了关键业务哪怕带宽紧张也能稳住贴错了再大的带宽也救不了语音的抖动。就这么简单也这么残酷。
干过网络的人应该都知道网络卡顿排查到最后的归宿往往不是带宽不够而是“优先级”没人管。尤其语音、视频会议、关键业务和下载流量混在一起跑的时候设备对着满队列的数据包往往一脸茫然——到底先转发谁这时候DSCP标记就派上用场了。它其实就是IP报文头里那6个比特用来告诉沿途每一台设备“我这个包是语音别给我乱丢那个包是下载实在不行先丢它。”这6个比特看似简单但它在差分服务DiffServ模型里是核心中的核心没有DSCP标记后面所有关于队列调度、拥塞避免、带宽保障的策略都无从谈起。这篇文章我想完整聊一聊DSCP标记的设计思路、常用码点取值、端到端的配置手法以及我在实际项目里踩过的那些坑。无论你是刚接触QoS的入门工程师还是正在做园区网、广域网优化的老手这篇应该都能帮你少走弯路。1. DSCP到底在管什么从IP头里的8个比特说起1.1 ToS字段的演进与DSCP的由来IP报文头里有个字节历史上叫ToSType of Service服务类型字段总共8个比特。最早的设计是把前3个比特叫作IP优先级IP Precedence从0到7一共8个等级。3个比特只能表达8种“重要程度”这在早期网络里勉强够用但随着语音、视频、以及越来越复杂的应用出现8个等级很快就捉襟见肘了。更麻烦的是不同厂商对“优先级6”“优先级7”的理解并不一致有的拿去做路由协议控制面有的干脆给数据面用跨厂商组网时经常鸡同鸭讲。后来RFC 2474对ToS字段做了重新定义取前6个比特作为DSCPDifferentiated Services Code Point差分服务代码点后2个比特留给ECN显式拥塞通知使用。6个比特意味着最多可以定义64个码点从0到63。这件事的本质变化其实不只是“等级变多了”而是“含义标准化了”。DSCP不再像IP Precedence那样只是告诉你“这个包很重要”而是告诉你“这个包对应的转发行为是什么”是低延迟、低丢包的EF还是分等级、可丢弃的AF还是全力而为的BE路由器看到标记就知道该往哪个队列里放、丢包时按照什么概率去丢。1.2 DiffServ模型的核心理念边界做标记核心做转发如果只把DSCP当成“优先级字段”看那就小看它了。差分服务DiffServ的整个设计哲学是在网络边缘做复杂的分类和标记在网络核心只做简单的调度和丢弃。换句话说接入层设备要学会“察言观色”——识别应用、打标、重写核心设备就不用想那么多只看DSCP值按预定义的PHBPer-Hop Behavior逐跳行为处理。这套思想可以用快递行业来类比。你寄件的时候快递网点的人负责验视包裹、称重、贴上“易碎”“加急”“生鲜”之类的面单标签之后包裹进入分拨中心和干线运输分拣员不关心里面装的是什么只看面单标签就知道该把它放进哪个筐、装哪辆车。如果每个分拨中心都要重新拆包验货整个物流体系早就瘫痪了。DSCP就是网络世界里的那张贴纸分类的“验货动作”只在网络边界做一次中间设备高效转发。这个设计相比更早的IntServ综合服务模型优势非常明显IntServ需要为每一条流在沿途设备上预留状态核心路由器要为每个会话维护资源信息在大规模网络上根本撑不住。DiffServ则是让核心设备保持“无状态”只管按照标记干活扩展性一下子就好了。不过这里必须说清楚一件事DSCP标记本身不等于QoS。完整的QoS链路至少包括分类、标记、队列调度、拥塞避免、限速这五个环节。DSCP只负责“标记”这一环它做得再好后面没有队列调度配合、没有丢弃策略兜底那也只是一张贴纸贴在包裹上分拨中心不认识或者干脆不执行照样白搭。理解这一点后面才不会把方案想得太简单。2. DSCP的常用标记值从0到63该怎么选2.1 一张表快速掌握常用码点DSCP总共64个码点实际项目里常用的其实就二十多个。我先把最核心的几类列个表大家后面查起来也方便类别值十进制二进制高6位典型用途Default / BE0000000普通上网、下载、后台流量尽力而为CS18001000低于BE的背景流量或用于某些网络管理CS216010000一般用于OAM/网管类流量CS324011000某些信令类流量或园区内部预留CS432100000实时交互类业务的备选标记CS540101000视频/语音的一种过渡标记CS648110000路由协议、网络控制面流量比如BGP/OSPF/IS-ISCS756111000最高级控制面一般用于设备紧急管理AF11 / AF12 / AF1310 / 12 / 14001010/001100/001110一类业务三个丢弃优先级AF21 / AF22 / AF2318 / 20 / 22010010/010100/010110二类业务比如重要数据AF31 / AF32 / AF3326 / 28 / 30011010/011100/011110三类业务比如呼叫信令、关键交易AF41 / AF42 / AF4334 / 36 / 38100010/100100/100110四类业务比如会议视频EF46101110低延迟低丢包语音媒体流首选这张表看着数值很多其实规律非常清晰AF类码点由“类别”1到4和“丢弃优先级”1到3组成格式就是AFxy。比如AF41代表第4类、丢弃优先级为1翻译成人话就是“这一类里最不能丢的”。每类内部数值越大丢包概率越高AF13比AF11更容易被丢弃。2.2 EF为什么偏偏是46很多初学者都会问EF直接等于46这个数字怎么来的不能随便挑一个吗当然不是随便挑的。EF的标准定义是RFC 3246选择46这个码点其实是刻意为之。46的二进制是101110它高3位是101也就是十进制的5。对照老的IP Precedence5对应的是以前预留的最高用户优先级。之所以要把高3位设计成101是为了兼容那些只认识旧IP Precedence字段的老设备即便一台老路由器看不懂DSCP它也能从高3位看出这流量等级不低不至于一上来就给丢掉。EF在排队设计上目标非常明确——低延迟、低抖动、低丢包它对应的就是话音媒体流这类对实时性要求极高的流量。还有一个细节值得注意EF没有选择43或者47而是选了46目的就是让它和老的控制面优先级CS6值48错开。控制面流量比如BGP、OSPF这类路由协议报文需要在极端拥塞时仍然可达但它和多媒体数据流的“实时”语义不同。把EF放在46而不是48、56就是明确地告诉网络设备用户实时业务不要占用控制面的最高优先级否则一旦数据面霸占最高队列出故障时路由协议都被卡住整个网络就真“叫天天不应”了。2.3 AF组的三个丢弃等级到底解决什么问题AF类的设计精妙之处在于它把“重要性”和“可丢弃性”拆成了两个维度。同样是视频会议业务主讲人画面、共享屏幕和录制备份的优先级显然不该一样。如果一刀切全部标EF拥塞时每个包对网络“同等重要”的诉求会让队列瞬间膨胀——收效未必好还容易造成语音抖动。用AF组就能做到给不同子流量打不同丢弃优先级网络发生拥塞时用WRED加权随机早期检测先丢那些低等级的包保住核心内容。比如视频会议里画面数据标AF41内容共享标AF42文件传输/录制流标AF43。拥塞一发生AF43先被丢弃AF42次之AF41能坚持到最后一刻。这样业务的体验是一种“逐渐降级”而不是“瞬间全断”用户感知会好很多。AF组还有一个实际好处WRED对同一类AF的不同丢弃等级可以使用不同的丢包曲线这让网络在拥塞时具备“弹性”。如果你连这个维度都不设计路由器面对拥塞时只能一刀切所有同一类包一起丢那用户的体感就是会议画面卡成PPT之后直接断线。2.4 CS类码点的取舍建议CS类其实就是把旧的IP Precedence左移3位得到的码点所以CS1到CS7分别对应8、16、24、32、40、48、56。它最大的作用是“兼容”和“控制面”。我个人的经验是CS6/CS7最好只用于设备之间的路由协议报文、网管报文这类控制面流量不要让普通业务报文打CS6/CS7。理由有两点第一很多核心设备对CS6/CS7的队列处理策略和控制面保护机制是绑定在一起的用户流量混进去极有可能触发控制面管制第二一旦你把某个数据流标成CS7在网络拥塞时它会比路由协议还“优先”万一这个流本身有突发反而会挤掉关键控制报文。这属于给自己埋雷。CS1这类低于BE的码点也很有用。我经常把内部的文件备份、日志上报、非关键监控流量统一标CS1这样在网络拥塞时它们会被优先丢弃而不是和办公上网流量抢带宽。很多团队在方案设计时只盯着“怎么让重要业务更优”忽略了“怎么让不重要的业务更低”其实CS1就是干这个的别浪费。3. 端到端DSCP方案设计信任边界、映射与设备配置3.1 先定信任边界再谈标记做DSCP方案最容易犯的错误就是一上来就配命令。真正动手之前必须先回答一个问题网络里哪些设备、哪些端口打上来的DSCP值我们选择相信这就是“信任边界”Trust Boundary。简单说设备是否直接采信入向报文的DSCP还是把所有入向报文一律重写成默认值再由本地策略重新打标。信任边界如果画得太靠内比如在整个园区都信任终端的DSCP那任何一台被攻破或配置错误的PC都能给自己打上EF拥塞时全网语音队列被垃圾流量塞满。信任边界如果画得太靠外比如连语音网关发给交换机的话音流量都不信任那交换机还得通过ACL重新识别语音配置量巨大不说识别效率和准确性都受影响。我目前比较推荐的做法是接入交换机面向用户PC的端口一律不信任DSCP默认把入向流量先改写成默认值0再通过ACL按应用特征分类、打标面向IP话机、视频会议终端这类专用设备的端口可以信任它们自带的标准标记因为专用设备打的标记一般符合标准不会乱来面向服务器接口的流量要看服务器上有没有跑特殊应用通常先在服务器侧或接入交换机上按五元组打标。边界问题想清楚后面配置才有依据。3.2 典型接入与核心的标记与重写配置我先描述一个典型的园区网场景某制造企业园区出口是1Gbps的专线内部有语音、视频会议、ERP系统和普通上网。规划如下语音电话标记EF视频会议标记AF41ERP系统标记AF31内部文件备份标记CS1其余全部保持默认值BE。接入交换机上对面向PC的端口做入方向策略匹配不同应用特征改写DSCP。这里我用常见的命令行风格做个示意具体关键字以自己手头设备手册为准# 入方向匹配IP话机地址段并标记EF traffic classifier VOICE if-match acl 3001 // 匹配话机网段 traffic behavior MARK_EF remark dscp ef traffic policy INPUT_POLICY classifier VOICE behavior MARK_EF # 接口下应用同时关闭信任 interface GigabitEthernet0/0/1 trust dscp disable // 不信任终端标记 traffic-policy INPUT_POLICY inbound核心设备上面向出口的物理接口做队列调度策略根据DSCP把流量映射到不同队列class-map match-any EF_QUEUE match ip dscp ef class-map match-any AF41_QUEUE match ip dscp af41 class-map match-any AF31_QUEUE match ip dscp af31 policy-map WAN_OUT class EF_QUEUE priority percent 10 police cir 100000000 // 防止EF队列被滥用 class AF41_QUEUE bandwidth percent 20 class AF31_QUEUE bandwidth percent 30 class class-default bandwidth percent 35 random-detect // 对BE启用WRED这里有个细节要特别提醒标签标记通常是在“入方向”做的因为数据包一进入网络我们就要决定它享受什么待遇而队列调度、拥塞管理是在“出方向”做的因为拥塞总是发生在接口发出的那一刻。这两个方向如果搞反配置会莫名失效而且排查起来相当痛苦。3.3 队列调度和丢弃策略必须跟DSCP配合起来标记只是“说”这个包重要队列调度才是“做”。接口拥塞时设备靠队列决定先送谁、后送谁、丢谁。通常EF类流量放进优先级队列PQPQ的特点就是只要队列里有包就先把它送出去。这保证了语音的低延迟但PQ是“霸道的优先级”必须配一个管制器police限制EF流量总量否则语音和伪语音流量会把后面的队列饿死。AF类流量一般放入CBWFQ基于类的加权公平队列每个类可以配置保证带宽bandwidth percent拥塞时各类按权重分享剩余带宽。实现拥塞避免时对AF类和BE类启用WREDAF内部使用三个不同丢弃等级让AF43比AF41更容易被丢弃BE则按默认曲线丢弃让后台大流量成为拥塞时的“牺牲品”。再放一组我常用的带宽规划参考在1Gbps出口上EF预留10%按实际并发话路计算一般100路语音需要10Mbps左右留10%已经很充裕AF41预留20%AF31预留30%CS6/CS7预留5%剩下的给BE。这里计算的关键不是“数字越大越好”而是“保证带宽的总和不能超过接口实际带宽”。有些设备对百分比会自动换算但你自己心里要对每条业务的实际流量模型有数。还有一点很有意思调度策略并不是非要在核心设备的出接口上做。如果你的园区出口路由器上同时接了几条链路必须确认每个出接口都挂了同样的策略或者至少关键的出接口都挂了。我见过只优化了主链路、备份链路完全裸奔的案例平时没事主备切换时语音直接全断。这种“备份链路没策略”的坑比DSCP本身配置错误更隐蔽。3.4 不同网络场景下的DSCP映射要点DSCP不是在所有网络里都能原样透传的跨二层、跨无线、跨MPLS、跨Overlay隧道时都要处理映射关系。二层VLAN场景报文在交换机之间传递时如果走的是Trunk口可以去信任802.1p优先级即VLAN头里的User Priority也可以按DSCP重新映射。纯二层组网通常建议把信任点设在接入交换机这样从接入往上走Trunk里的优先级已经一致不容易乱。无线场景Wi-Fi报文在无线侧用的是WMMWi-Fi多媒体的User PriorityAP收到无线报文时要把UP映射成DSCP反过来AP从有线口收到带DSCP的报文转发到无线侧时也要映射成UP。很多AP默认会把所有非语音流量映射成最低UP某一天你发现手机上的视频会议画面卡到不行抓包一看DSCP确实是EF但AP映射时把它降成了普通数据那问题就出在这个映射环节。MPLS场景MPLS报头里的实验位EXP现在叫Traffic Class用来标记优先级。IP报文进入MPLS网络时PE设备通常会把DSCP复制到EXP如果在P核心设备上要做队列调度那就必须看EXP而不是外层看不到的IP DSCP。这里最常见的问题是对端运营商没有把EXP映射好导致IP侧和MPLS侧优先级脱节。Overlay隧道场景GRE、IPSec、VXLAN这类封装会把原始IP报文包进新IP报文里外层IP头的DSCP默认是0还是复制内层完全取决于封装实现。很多默认行为是“不复制”甚至有些老版本干脆置零。在这种情况下中间网络只能看到外层IP头内层DSCP再漂亮也不会被感知。解决办法一般是在隧道接口上开启预分类pre-classify或者配置DSCP复制让外层继承内层标记。这块我后面还会专门讲。4. DSCP落地中的坑与排查实录4.1 现象一抓包看到DSCP全是0但配置明明标记了有一次我在一个园区网络里排查视频会议卡顿终端上抓包看到报文DSCP确实是AF41可是到了汇聚交换机再抓DSCP居然变回了0。配置检查了一遍又一遍标记策略明明生效了问题在哪儿后来逐跳打点才发现问题出在接入交换机上从接入到汇聚用了Trunk口汇聚交换机在这个Trunk口上配置了“不信任入向DSCP”把收到的所有报文优先级全部重写成默认值。这其实就是一个信任边界设置的问题——接入设备打了标汇聚设备不相信又给擦掉了。排查思路其实很简单从源到目的逐跳抓包看DSCP在哪一跳消失然后检查那一跳的端口信任关系和QoS策略方向。很多时候不是你标错了而是别人在下一跳把你的标记擦了。4.2 现象二隧道流量优先级失效某次做跨地域网络优化业务通过GRE隧道互联语音流量在隧道两端都打了EF但中间链路的拥塞还是影响了语音质量。抓包一看隧道外层IP头的DSCP是0内层IP头是46。中间路由器根本不看内层头的DSCP它只知道外层是一个普通IP包于是语音和大量数据一起在队列里排队。这种问题的修复方式要看是哪种隧道。如果是GRE隧道一般需要在隧道接口上开启预分类让隧道接口能够看到内层IP头的信息并把内层DSCP复制到外层如果是IPSec隧道涉及加密和封装通常要配置QoS预分类或者选择保留DSCP的封装参数如果是VXLAN这类Overlay网络则要看VTEP设备是否支持把内层DSCP复制到VXLAN/UDP/IP外层。核心原则就一条中间网络只能看到外层报文头所以优先级必须体现在外层头里。我前面反复强调这个因为在实际项目里遇到的频率实在太高了。4.3 现象三EF队列反而把网络搞抖了有些团队喜欢把“重要的流量”统统标成EF视频标EF语音标EF核心交易也标EF。结果就是拥塞时PQ队列被塞满后面CBWFQ里的关键业务反而得不到服务网络更抖了。EF的标准定位就是“带宽小、延迟低、必须优先”的实时业务典型就是语音RTP流。视频会议带宽需求很大不分青红皂白全标EF会让PQ队列带宽消耗很高反而增大语音抖动风险。正确的做法是语音媒体流用EF视频会议根据重要性用AF41/AF42关键交易用AF31/AF32网络控制面用CS6。普通流量用BE后台垃圾流量用CS1。这样一个码点一层用途真正做到各司其职。EF队列务必配置police把进入PQ的突发流量限制住否则任何一次异常突发都能瞬间击穿全网QoS设计。4.4 现象四无线环境手机业务优先级丢失还有一个很常见的坑在无线侧。手机连接Wi-Fi打电话或开会报文从手机发出时WMM的UP值一般是根据应用自行设置的但部分手机厂商的实现并不规范很多报文到了AP之后UP值全是0。AP把无线流量转成有线流量时需要根据UP映射成DSCP如果UP是0映射出来的DSCP自然是0。此时有线侧再怎么配置EF队列它也匹配不到这些语音报文因为它们在源端就已经丢标了。这类问题的解法通常是在AP或无线控制器上做“重打标”策略根据报文的应用特征比如SIP端口号、RTP端口范围、以及目标IP地址段重新对无线流量分类匹配语音的报文统一设置DSCP为EF匹配视频的统一设置AF41。不要指望终端自己会给你打一个完美的标记无线环境里终端各行其是的概率极高。真要做企业级无线语音接入侧重写几乎是必经之路。4.5 常见问题速查表最后把我在项目中反复遇到的DSCP问题整理成一个速查表方便大家定位现象可能原因排查/解决手段抓包看到DSCP0接入端口不信任、上行端口重写、ACL未匹配逐跳抓包定位消失点检查trust配置检查入向策略是否生效隧道流量无优先级封装外层DSCP未复制/inner head不可见在隧道接口开预分类或配置DSCP复制查看封装实现说明语音时好时坏EF队列被占用/police未配置检查EF队列深度和丢弃计数为EF配置police和带宽约束视频会议卡顿但语音正常视频标EF或AF映射错误把视频改为AF4x按丢弃等级区分不要和语音共用EF无线手机流量全部BEWMM UP映射不当或终端未打标在AP/AC上按应用重打DSCP重新梳理DSCP到UP映射表二层Trunk后优先级丢失汇聚设备信任/重写策略覆盖了接入标记统一信任链路的策略口径确定单一信任点跨运营商QoS失效运营商侧的标记被清/重写在运营商网络边界再次标记与对端明确DSCP策略5. 关于DSCP项目实施我的几点个人体会做这套东西做久了越来越觉得DSCP的难点从来不在“怎么配命令”而在于你到底愿不愿意、能不能信任整条链路上的每一个节点。你在这头费尽心思打了EF中间一台设备随手就给你清零整个方案就是白做。所以真正靠谱的做法是在项目规划阶段就把“信任边界”画清楚并且把每一级设备上的标记、信任、映射、调度策略全部列成一张表逐台核对。这比装机时现场拍脑袋写ACL可靠得多。我个人的小心得是平时做任何网络排障抓包时先看一眼IP头的DSCP值再往下查往往会省掉大量时间。很多所谓的“线路质量差”“设备性能不行”追到根上就是DSCP在某处被改写成0或者被标错类别。养成看标记的习惯以后你会发现网络拥塞时的表现其实非常“讲理”——它完全按照你贴的标签在做事。贴对了关键业务哪怕带宽紧张也能稳住贴错了再大的带宽也救不了语音的抖动。就这么简单也这么残酷。
