流量整形这个词，干网络这行的听到都不陌生，但真到设备上敲命令的时候，不少人还是会卡壳。华为设备上的流量整形配置，说难不难，说简单也真不简单——参数算错一个数量级，整条链路的体验就全毁了。我这些年调过的限速场景少说也有几十个，从企业出口带宽收敛到专线两端速率匹配，踩过的坑比配置过的命令还多。这篇内容就把华为流量整形的配置逻辑、参数计算、实操步骤和排查经验一次性讲透，适合刚接触QoS的运维新人对照操作，也适合有一定基础的朋友查漏补缺。核心关键词流量整形、令牌桶、队列调度、带宽限速会贯穿全文，读完你至少能做到：拿到一个限速需求，知道该用整形还是监管，知道CIR和PIR怎么算，知道命令敲下去之后怎么验证效果。
1. 流量整形到底在解决什么问题
1.1 从一条专线的真实困境说起
先讲个我印象很深的场景。某公司总部到分支有一条100M专线，分支侧接入的是50M带宽，总部这边出口设备却按100M往外发。结果就是分支侧设备缓冲区被打满，丢包率飙升，视频会议卡成PPT。很多人第一反应是“加带宽”，但问题根源不在带宽总量，而在发送速率和接收能力不匹配。流量整形干的事，就是把出口流量削峰填谷，让发送速率不超过下游能承受的阈值，同时把超出的部分缓存起来后续再发，而不是直接丢掉。
这里要区分两个容易混淆的概念：流量监管（Policing）和流量整形（Shaping）。监管是“超了就扔”，整形是“超了先存着慢慢发”。监管实现简单、对设备资源消耗小，但丢包对TCP流不友好；整形需要缓冲区，会引入额外时延，但对业务连续性更友好。华为设备上，监管通常用car命令实现，整形则依赖队列和令牌桶机制。选哪个，取决于你的业务对丢包和时延哪个更敏感。
1.2 整形和监管的选型判断表
我把常见的判断逻辑整理成一张表，实际项目中照着对号入座基本不会错：
| 判断维度 | 选流量监管 | 选流量整形 |
|---|---|---|
| 业务对丢包敏感度 | 低（如尽力而为业务） | 高（如视频、VoIP） |
| 业务对时延敏感度 | 高（如实时交互） | 低（可容忍毫秒级缓存） |
| 下游设备缓冲能力 | 强 | 弱 |
| 设备资源开销要求 | 低 | 较高（需队列缓冲） |
| 典型场景 | 入口限速、防攻击 | 出口带宽收敛、专线速率匹配 |
这张表背后的逻辑其实很简单：整形是用“时间”换“平滑”，监管是用“丢弃”换“简单”。你在出口方向做带宽收敛，下游缓冲区又不够大，那就老老实实上整形；你在入口方向做流量清洗，超出的报文本来就不该进来，那就用监管直接扔。
1.3 令牌桶：整形背后的核心机制
流量整形的底层是令牌桶（Token Bucket）算法。你可以把它想象成一个水桶，桶里按固定速率注入“令牌”，每个报文要发送前必须从桶里取走对应数量的令牌，取不到就排队等着。桶的容量决定了能应对多大的突发流量。这里有两个关键参数：CIR（承诺信息速率）决定令牌注入的快慢，CBS（承诺突发尺寸）决定桶有多大。
华为设备上配置整形时，CIR和CBS的换算关系必须搞清楚。CIR单位通常是kbps，CBS单位是字节。一个常用的经验公式是：CBS = CIR × 突发时间 / 8。比如CIR设为10Mbps，希望容忍100ms的突发，那CBS = 10×1024×1024×0.1/8 ≈ 131072字节。这个值设太小，正常突发会被削掉；设太大，缓冲区压力大且平滑效果变差。实际配置中我一般会先按业务特征估一个值，再通过观测调整。
2. 华为设备上的整形配置入口与命令体系
2.1 不同产品线的配置差异
华为设备产品线很宽，路由器、交换机、防火墙上的整形配置入口不完全一样。NE系列路由器一般在接口视图下用qos shaping命令；S系列交换机部分型号支持在接口或队列上做整形；AR系列企业路由器则通过流分类加流行为的方式组合配置。我下面以最通用的基于流分类的MQC配置方式为主线来讲，因为这套逻辑在华为多数中高端设备上是通的，学会了迁移成本最低。
MQC全称是Modular QoS Command-Line Interface，模块化QoS命令行。它的核心思路是三步走：流分类（traffic classifier）定义“哪些流量”，流行为（traffic behavior）定义“对这些流量做什么”，流策略（traffic policy）把分类和行为绑在一起，最后应用到接口方向。这个设计的好处是解耦，分类可以复用，行为可以组合，改需求时不用推倒重来。
2.2 配置前的信息准备清单
动手敲命令之前，有几项信息必须先确认清楚，否则配到一半发现参数不对，返工很麻烦：
- 接口实际带宽：用display interface查看，注意区分物理带宽和可用带宽，有些接口标称1G但实际转发能力受License限制。
- 业务流量特征：平均速率、峰值速率、突发持续时间，这些决定了CIR和CBS的取值。
- 下游设备接收能力：对端接口速率、缓冲区大小，这是整形目标值的直接依据。
- 方向确认：整形一般做在出方向（outbound），因为要控制的是“发出去”的速率；入方向更多用监管。
- 现网QoS策略：用display traffic policy查看是否已有策略占用，避免冲突。
注意：在现网设备上配置前，务必确认当前接口是否已有流策略应用。华为设备同一接口同一方向通常只允许应用一个流策略，直接覆盖可能导致原有业务策略失效。
2.3 一个最小可用的配置骨架
先给一个最简骨架，让大家对整体结构有数，后面再逐段展开：
# 定义流分类，匹配所有流量（也可细化匹配特定网段） traffic classifier shaper_class operator or if-match any # 定义流行为，做流量整形，CIR设为50Mbps traffic behavior shaper_behavior queue af bandwidth 50000 shaping cir 50000 kbps # 定义流策略，绑定分类和行为 traffic policy shaper_policy classifier shaper_class behavior shaper_behavior # 应用到接口出方向 interface GigabitEthernet0/0/1 traffic-policy shaper_policy outbound这段配置的意思是：从GigabitEthernet0/0/1出去的流量，整体整形到50Mbps。注意shaping cir和queue af bandwidth的配合关系，前者控制整体速率，后者给队列分配带宽保证。实际项目中这两个值要匹配，否则可能出现队列带宽够但整形卡住，或者整形放行但队列拥塞的情况。
3. 参数计算与队列调度的实操细节
3.1 CIR和CBS的计算过程拆解
参数计算是整形配置里最容易出错的地方，我见过把kbps当bps填的，也见过CBS设成0导致突发全丢的。这里把计算过程完整走一遍。
假设需求是：某接口出口带宽1Gbps，需要把某业务流量整形到200Mbps，业务报文平均长度1000字节，希望容忍50ms的突发。
第一步算CIR：200Mbps = 200 × 1024 kbps = 204800 kbps。华为命令里cir参数单位是kbps，所以填204800。
第二步算CBS：CBS = CIR × 突发时间 / 8。CIR用bps表示是200×1024×1024 bps，突发时间0.05秒，则CBS = 200×1024×1024×0.05/8 = 1310720字节。华为部分命令的cbs参数单位是字节，部分平台用kb，配置时要看清命令帮助。
第三步校验：CBS对应的突发报文数 = 1310720 / 1000 ≈ 1310个报文。这个数量级对于50ms突发是合理的，如果业务突发更集中，可以适当放大到2倍。
提示：不同华为产品线对cbs参数的单位定义可能不同，有的用字节，有的用千字节。配置前用
?查看命令帮助，或者查对应版本的命令参考，这一步千万别想当然。
3.2 队列调度与整形的配合关系
整形不是孤立存在的，它和队列调度是配合关系。华为设备出方向通常有多个队列（如EF、AF1-AF4、BE），整形作用在队列或端口层面，调度决定队列之间怎么抢带宽。常见的配合方式有两种：
一种是端口级整形加队列调度：端口整体整形到某个速率，内部各队列按优先级调度。这种方式适合出口带宽收敛场景，整体不超下游能力，内部再按业务重要性分配。
另一种是队列级整形：每个队列单独整形，互不影响。适合多业务各自有独立带宽承诺的场景，比如视频业务承诺50M、数据业务承诺100M，各自整形互不挤占。
配置队列级整形时，queue af bandwidth指定的是队列保证带宽，shaping cir指定的是该队列的整形速率。两者关系是：保证带宽是下限承诺，整形速率是上限约束。实际配置中整形速率一般大于等于保证带宽，否则保证带宽形同虚设。
3.3 实操心得：参数调试的三个阶段
我调整形参数一般分三个阶段走，分享出来供参考：
第一阶段是理论估算，按上面的公式算出CIR和CBS，先配上去。第二阶段是观测验证，用display命令看整形前后的速率对比、丢包计数、队列缓存占用。第三阶段是微调收敛，根据观测结果调整CBS，如果发现突发被削得太狠就放大CBS，如果发现时延明显增加就缩小CBS。
这里有个经验值：CBS对应的突发时间一般设在10ms到100ms之间。低于10ms，正常业务突发都扛不住；高于100ms，缓存时延对实时业务影响明显。这个范围是我多次调试后总结的，比纯理论公式更贴近实际。
4. 完整配置流程与验证方法
4.1 从零到一的配置步骤
下面按顺序走一遍完整配置，假设场景是：GigabitEthernet0/0/1出方向，将192.168.10.0/24网段流量整形到100Mbps，CBS按50ms突发计算。
第一步，算参数。CIR = 100×1024 = 102400 kbps。CBS = 100×1024×1024×0.05/8 = 655360字节。
第二步，配置流分类，匹配源网段：
traffic classifier shape_net10 operator or if-match acl 3010配套的ACL：
acl number 3010 rule 5 permit ip source 192.168.10.0 0.0.0.255第三步，配置流行为，做整形：
traffic behavior shape_net10_beh shaping cir 102400 kbps cbs 655360第四步，配置流策略并绑定：
traffic policy shape_net10_pol classifier shape_net10 behavior shape_net10_beh第五步，应用到接口出方向：
interface GigabitEthernet0/0/1 traffic-policy shape_net10_pol outbound第六步，验证配置生效：
display traffic policy user-defined shape_net10_pol display traffic-policy applied-record display interface GigabitEthernet0/0/1重点看display interface输出中的outbound速率是否被压在100M附近，以及是否有大量discard计数。如果速率没压住，先查策略是否应用成功；如果discard多，查CBS是否太小。
4.2 验证环节的关键观测点
配置敲完不等于完事，验证才是见真章的地方。我一般盯三个观测点：
第一个是速率观测。用display interface看接口出方向的实际速率，或者用流量分析工具抓包统计。整形生效后，出方向速率应该稳定在CIR附近，允许有小幅波动但不应该持续超过CIR。
第二个是丢包观测。整形本身不丢包（超出部分缓存），但如果缓存满了还是会丢。用display qos queue statistics interface看各队列的丢弃计数，如果丢弃持续增长，说明CBS或队列缓存不够。
第三个是时延观测。整形引入的时延主要来自缓存，缓存越满时延越大。可以用业务侧的ping或专用探针测端到端时延，如果时延明显上升，考虑缩小CBS。
4.3 一个容易忽略的细节：整形与接口速率的匹配
有个细节很多人不注意：整形速率不能超过接口物理速率，否则配置了也没意义。比如接口是100M，你整形设200M，那等于没限。反过来，整形速率远低于接口速率时，要确认队列缓存是否足够支撑平滑效果。我遇到过接口1G、整形设10M的场景，结果CBS按公式算出来很小，突发一来就丢包，后来把CBS放大到公式值的3倍才稳住。这个案例说明公式是起点不是终点，实际要结合缓存能力调。
5. 常见问题排查与避坑实录
5.1 整形不生效的排查路径
整形配了但速率没变化，这是最高频的问题。排查按这个顺序走：
先查策略是否应用成功，用display traffic-policy applied-record确认接口和方向对得上。再查流分类是否匹配到流量，用display traffic classifier和ACL计数确认报文命中。然后查流行为里的整形参数是否被正确解析，用display traffic behavior看cir和cbs值。最后查接口本身是否有其他限速或策略冲突。
我遇到过一次，策略应用了但分类没命中，原因是ACL写的是源网段，实际流量是从另一个网段过来的。这种问题只能靠逐层验证，没有捷径。
5.2 常见问题速查表
| 现象 | 可能原因 | 排查命令 | 解决方向 |
|---|---|---|---|
| 速率未压制 | 策略未应用或方向错 | display traffic-policy applied-record | 检查接口和outbound方向 |
| 速率未压制 | 流分类未命中 | display traffic classifier | 核对ACL匹配条件 |
| 丢包严重 | CBS过小 | display qos queue statistics | 放大CBS值 |
| 时延增大 | CBS过大或缓存满 | 业务侧时延探测 | 缩小CBS或降CIR |
| 部分流量未限速 | 分类粒度不够 | display acl | 细化匹配规则 |
| 配置后业务中断 | 策略覆盖冲突 | display current-configuration | 合并或调整策略顺序 |
5.3 独家避坑技巧三条
第一条，先在测试环境验证参数再上现网。整形参数对业务影响直接，现网直接调风险高。测试环境用打流工具模拟业务特征，把CIR和CBS调稳了再迁移。
第二条，CBS宁大勿小，但要配合时延观测。CBS小了突发丢包，大了时延上升，这个平衡点靠观测找。我的习惯是先给公式值的1.5倍，观测后再收。
第三条，整形策略尽量做在靠近源头的出方向。越早整形，下游设备压力越小。如果等到下游拥塞了再整形，上游已经把流量灌进来了，效果打折扣。
6. 进阶场景：多业务分级整形
6.1 分级整形的设计思路
单业务整形会了之后，多业务分级整形是绕不开的进阶场景。典型需求是：出口总带宽200M，视频业务保证80M、数据业务保证100M、其余尽力而为。这种场景要用到层次化整形或者队列加整形组合。
设计思路是先做端口级整形把总量压到200M，再在内部用队列调度分配保证带宽。华为设备上可以用qos queue scheduling配合队列整形实现。关键是保证带宽之和不能超过端口整形速率，否则保证承诺无法兑现。上面例子中80+100=180M，小于200M，留了20M给尽力而为，这个分配是合理的。
6.2 分级整形的配置示例
# 端口级整形 interface GigabitEthernet0/0/1 qos shaping cir 204800 kbps # 队列调度配置 qos queue 1 scheduling wrr weight 40 qos queue 2 scheduling wrr weight 50 qos queue 3 scheduling wrr weight 10 # 队列整形（视频队列） traffic behavior video_beh queue ef bandwidth 81920 cbs 819200 shaping cir 81920 kbps这段配置的逻辑是：端口总量200M，队列1和2按权重分带宽，视频队列单独整形到80M。权重40:50:10对应大约80M:100M:20M的分配比例，和需求基本吻合。实际调的时候权重和整形速率要联动看，不能各调各的。
6.3 分级整形的观测重点
分级整形配完后，除了看总速率，还要看各队列的实际分配是否符合预期。用display qos queue statistics interface看每个队列的转发和丢弃计数，如果某个队列丢弃多而其他队列空闲，说明权重或整形速率分配不合理。这时候要回头调权重，而不是简单加带宽。
我在一个项目中遇到过视频队列丢弃严重但数据队列很空闲的情况，查下来是视频队列的整形速率设低了，权重再高也受整形上限约束。把整形速率从60M提到80M后问题解决。这个案例说明整形速率是硬上限，权重是在上限内的分配比例，两者要匹配。
7. 写在最后的实操体会
流量整形这套东西，命令本身不难记，难的是参数背后的业务理解和观测调优。我个人的体会是，配置只占三成功夫，剩下七成在验证和微调。每次配完别急着收工，盯着display输出看几分钟，看速率稳不稳、丢包有没有、时延变没变，这几个观测点比任何理论公式都实在。另外，整形策略的变更一定要有回退方案，现网调参前把原配置备份好，出问题能快速恢复。这个习惯帮我避免过好几次深夜救火。
