★ FEATURED ARTICLE 1. 流量整形到底在解决什么问题很多人第一次接触流量整形是因为遇到了一个很具体的现象某条链路上行带宽被某类业务吃满导致关键业务丢包、时延飙升用户投诉不断。这时候如果只是简单粗暴地限速往往会出现限了但没完全限住的尴尬——突发流量照样冲垮队列关键业务照样受影响。流量整形Traffic Shaping和流量监管Traffic Policing这两个概念经常被混着用但它们的处理逻辑完全不同用错了场景效果天差地别。流量监管的做法是超了就丢对超出承诺速率的报文直接丢弃或降级标记简单直接但容易造成业务抖动流量整形的做法是超了就缓把超出速率的报文先缓存进队列等带宽空闲时再按节奏发出去输出曲线更平滑。打个生活化的比方监管像高速公路收费站超载的车直接不让上整形像水库调蓄洪峰来了先蓄着下游按恒定流量放水。对于语音、视频这类对抖动敏感的业务整形通常比监管更友好因为它不会制造突发丢包。在华为设备上做流量整形核心是围绕**令牌桶Token Bucket**这套机制展开的。理解令牌桶是理解所有整形配置的前提系统以承诺速率CIR往桶里投放令牌桶有容量CBS报文要发送必须从桶里取走与报文长度等量的令牌桶里令牌不够就缓存等待。这里有两个关键参数——CIR决定长期平均速率CBS决定能容忍多大的突发。很多人配完整形发现限速不准八成是CBS设得不合理而不是CIR写错了。这篇内容面向的是需要在中高端路由器或交换机上落地流量整形策略的网络从业者包括运营商边缘、企业出口、数据中心互联等场景。我会从参数计算、配置骨架、队列调度、验证排错几个层面把这件事讲透重点放在那些文档里不写、但实际配下去就会踩的坑上。全文基于华为VRP系统的通用配置逻辑展开不同产品型号的命令细节可能有差异但原理和思路是通用的。2. 令牌桶参数不是拍脑袋填的2.1 CIR、CBS、PIR三者的关系与计算流量整形最容易被忽视的一步就是参数计算。我见过太多人直接抄一个car cir 10000就上线结果业务侧反馈限速忽高忽低。问题出在CBS上。CBS承诺突发尺寸的物理含义是桶能装多少令牌它决定了在CIR速率下能允许多大的瞬时突发。业界常用的经验公式是CBS CIR × 突发时间突发时间一般取几十毫秒到几百毫秒。举个具体例子CIR设为10 Mbps希望容忍50 ms的突发那么CBS 10 Mbps × 0.05 s 500000 bit ≈ 62.5 KB。如果你把CBS设得极小比如默认的几千字节那么即使CIR够大稍微来一点突发报文桶就空了报文被迫排队实际吞吐会明显低于CIR表现为限速偏低反过来CBS设得过大突发报文能一口气冲出去瞬时速率远超CIR下游设备可能被打爆表现为限速偏高、抖动大。对于双速三色标记场景还会涉及PIR峰值信息速率和PBS峰值突发尺寸。PIR是允许的瞬时最高速率PBS对应峰值桶容量。三色标记的逻辑是速率在CIR以内的标记为绿色承诺内CIR到PIR之间的标记为黄色超出承诺但在峰值内超过PIR的标记为红色超标。整形时绿色报文优先转发黄色报文降级处理红色报文丢弃或最后处理。这套机制在需要区分业务等级时非常有用但前提是PIR和PBS也要算对不能只盯着CIR。参数含义典型取值思路设错的后果CIR承诺信息速率按业务保障带宽设定直接决定平均限速值CBS承诺突发尺寸CIR × 50~200ms过小限速偏低过大突发失控PIR峰值信息速率通常为CIR的1.2~2倍影响黄色报文判定PBS峰值突发尺寸PIR × 突发时间影响峰值容忍度2.2 为什么突发时间要按业务特性选突发时间的选择不是随便取个中间值就行它跟业务流量的统计特性强相关。像HTTP这类请求-响应型业务天然就是突发型的一个页面加载会瞬间拉出一串报文这时候突发时间要留够否则页面加载会被整形拖慢而像大文件传输这种持续流流量本身就平稳突发时间可以取小一点让限速更贴近CIR。我的经验是面向交互式业务网页、API调用取100~200 ms面向批量传输取20~50 ms面向实时音视频取50~100 ms并配合低时延队列。这个取值没有绝对标准但有一个验证方法——配完之后用打流工具发一个持续流加周期性突发流观察实际输出速率曲线如果曲线在CIR附近小幅波动就是合理的如果出现明显的锯齿或者长时间低于CIR就要回头调CBS。还有一个常被忽略的点报文长度对令牌消耗的影响。令牌桶是按字节消耗令牌的一个1500字节的大包和一个64字节的小包消耗的令牌差二十多倍。如果业务里小包占比很高比如游戏、VoIP同样的CIR下桶的消耗节奏和大包业务完全不同这时候CBS要相应调整。实测中我遇到过VoIP业务配了按大包业务算的CBS结果小包突发把桶瞬间抽干语音出现规律性卡顿把CBS调大后才恢复正常。3. 华为设备上的整形配置骨架3.1 基于接口的整形与基于队列的整形华为VRP系统里做流量整形主要有两个落点接口级整形和队列级整形。接口级整形作用于整个出接口把接口的总发送速率压到某个值以下适合这条链路总共只能跑这么多的场景队列级整形作用于某个具体队列适合这个业务类别只能占这么多的场景。两者可以叠加使用但叠加时要注意整形是逐级收敛的接口级整形会约束所有队列的总和。接口级整形的配置骨架大致是这样以通用VRP语法示意具体接口类型和命令以设备为准# 进入接口视图 interface GigabitEthernet 0/0/1 # 配置接口出方向流量整形 qos shaping cir 10000000 cbs 62500这里的cir单位通常是bit/scbs单位是byte配置时务必确认单位这是新手最容易栽的地方——把cir写成10000以为是10 Mbps实际是10 kbps配完发现业务几乎不通排查半天才发现单位错了。队列级整形则要先进队列模板或者直接在接口下针对队列配置语法上会多一层队列索引。接口级整形的一个隐含行为是它整形的是出方向流量。入方向流量的速率控制一般用流量监管car而不是整形因为入方向缓存报文再延迟处理会引入额外时延且占用缓冲得不偿失。所以配整形之前先想清楚方向别在入方向配了个shaping然后疑惑为什么没效果。3.2 队列调度与整形的配合逻辑光有整形还不够整形只是把速率压下来压下来之后报文在队列里怎么排队、怎么调度出去决定了最终的时延和公平性。华为设备上常见的队列调度方式是PQ优先队列、WFQ加权公平队列和WRR加权轮询的组合。典型做法是把语音、信令这类低时延业务放进PQ队列保证它们永远优先出队把普通数据业务放进WFQ或WRR队列按权重分配剩余带宽。整形和调度的关系可以这样理解整形是总闸门控制整体出水速度调度是分水阀决定各个队列谁先出水、出多少。如果只配整形不配调度所有报文挤在一个默认队列里先来先服务关键业务照样被大包堵在后面。所以完整的方案一定是整形 队列调度 必要时配合拥塞避免三件套。配置队列调度时有个细节值得注意PQ队列如果配置不当可能把低优先级队列饿死。比如语音队列权重给得过高数据队列长期分不到带宽业务侧表现为语音很清晰但文件传不动。合理的做法是给PQ队列设一个速率上限配合整形让它最多占用某个比例剩余带宽留给其他队列。这个上限的设定要参考语音业务的峰值带宽留20%余量即可。3.3 一个可复用的配置模板把上面的要素串起来一个面向关键业务保障 普通业务限速场景的配置模板大致如下# 定义流分类识别关键业务 traffic classifier critical_business operator or if-match acl 3000 # 定义流行为关键业务标记高优先级 traffic behavior critical_behavior remark dscp ef queue ef # 定义流策略绑定分类与行为 traffic policy business_policy classifier critical_business behavior critical_behavior # 接口下应用流策略 interface GigabitEthernet 0/0/1 traffic-policy business_policy outbound # 接口级整形总闸门 qos shaping cir 100000000 cbs 625000这个模板里ACL 3000负责匹配关键业务的地址和端口remark dscp ef把报文标记为加速转发等级queue ef把它映射到低时延队列。接口级整形把总出口速率压在100 Mbps。实际部署时还要根据设备支持的队列数量和调度算法补充WRR权重配置这里为了简洁省略了。提示流策略的应用方向inbound/outbound必须和整形方向一致否则会出现分类生效了但整形没生效的假象。排查时先确认方向再看计数器。4. 配完之后限速不准的排查链路4.1 从计数器入手定位问题层级整形配下去之后最常见的反馈就是限速不准可能是实际速率高于CIR也可能是低于CIR。排查的第一步永远是看计数器而不是凭感觉改参数。华为设备上可以用display命令查看接口和队列的流量统计、整形丢包计数、队列丢弃计数。看计数器的顺序建议是先看接口总收发速率确认物理链路本身没问题再看整形模块的通过和丢弃计数确认整形是否真的在起作用最后看各队列的丢弃分布定位是哪个队列在超限。如果整形丢弃计数为0但实际速率明显超过CIR说明整形根本没生效优先怀疑三个方向配置没提交、应用方向错了、或者流策略没有匹配上流量。如果整形丢弃计数很高但实际速率远低于CIR说明桶太小或者队列调度把报文堵住了这时候要回头看CBS和队列权重。我踩过的一个典型坑是流分类里ACL匹配的地址写错了一个网段导致关键业务流量根本没进整形策略走的还是默认转发路径速率自然不受控。这种问题计数器上表现为整形模块计数远小于接口总流量一眼就能看出来。所以排查时对比接口总流量和整形模块流量这两个数差值就是没被策略覆盖的流量顺着差值去找漏网的流量特征效率很高。4.2 突发流量导致的瞬时超限误判还有一种情况是监控工具报瞬时速率超过CIR但平均速率是达标的。这往往不是配置错误而是令牌桶的正常行为——CBS允许一定程度的突发瞬时速率超过CIR是设计内的。判断方法是看超限持续时间如果只是毫秒级的尖峰且平均速率在CIR附近属于正常如果持续数秒超限那才是真问题。监控工具的采样周期也会造成误判。很多监控按5秒或1分钟采样采样点恰好落在突发尖峰上就会显示超限。这时候不要急着改配置先把采样周期调细或者直接看设备上的整形计数器以设备侧数据为准。我一般建议用设备计数器做最终判定监控工具只做趋势参考。4.3 多级整形叠加时的收敛问题当接口级整形和队列级整形同时存在或者流量经过多台设备逐级整形时会出现逐级收敛现象。比如第一台设备把某业务整到50 Mbps第二台设备又整到30 Mbps最终出口就是30 Mbps这本身没问题。但如果两级整形的CBS设置不匹配可能出现报文在两级之间反复排队时延叠加。表现是业务能通、速率也对但时延比预期高很多。排查这类问题要看每一级的队列深度和排队时延。华为设备上可以查看队列的当前深度和丢弃统计如果某一级队列长期处于高水位说明这一级是瓶颈要么放宽这一级的整形参数要么把上游的速率再压低让瓶颈前移到一个缓存更充足的位置。原则是让瓶颈出现在缓存最深、调度最合理的那一级而不是让报文在浅缓存的环节反复丢。5. 实战中几个反直觉的经验5.1 整形参数不是越小越安全很多运维人员出于保守心理把CIR设得比业务实际需求低很多觉得这样肯定不会超。结果业务高峰期报文大量排队时延飙升用户体验反而更差。整形的目的是平滑而不是压制CIR应该贴着业务的实际保障需求设留10%~20%余量即可。设得过低等于人为制造拥塞这是典型的用力过猛。5.2 先抓流量特征再定参数配整形之前我强烈建议先抓一段时间的流量做基线分析峰值速率多少、平均速率多少、突发持续时间多长、大小包比例如何。这些数据直接决定CIR和CBS怎么取。没有基线数据就配整形等于闭着眼睛调音。抓流量的工具用设备自带的流量统计或者镜像抓包都行关键是拿到真实的速率分布而不是拍脑袋估一个数。5.3 变更窗口和回退预案整形策略一旦配错影响的是整条链路的业务所以变更一定要有回退预案。我的习惯是配置前先保存当前配置配置后用最小业务集验证确认关键业务和普通业务都正常再全量放开。如果设备支持配置回滚提前准备好回滚脚本。整形这类涉及全局速率的配置最忌讳在生产高峰期直接改选业务低峰窗口操作出问题时影响面最小。5.4 文档里不写的单位陷阱最后再强调一次单位问题。华为不同产品线、不同命令里cir的单位可能是bit/s也可能是kbpscbs的单位可能是byte也可能是bit配置前务必查对应型号的命令手册确认。我见过把cbs按bit填结果桶大了8倍的案例也见过cir按kbps填结果限速只有预期的千分之一的案例。单位错了参数算得再准也白搭。养成配完先看计数器验证实际速率的习惯能挡住绝大多数单位错误。流量整形这件事原理不复杂难的是把参数算准、把方向配对、把调度配合理再在真实流量下验证到位。把这几个环节都走一遍限速不准的问题基本就能绝迹了。
阅读完成 · 觉得有帮助？
