1. 为什么要在交换机上做流策略与流量统计

园区网里最容易被忽略的一句话是：链路通了不等于网络管好了。我见过太多机房，物理链路、VLAN、路由都配得整整齐齐，可一旦某个部门开始跑大文件备份，或者某台终端中了循环发包的毛病，整栋楼的办公网就开始卡。这时候你要是只会display interface brief看端口速率，基本等于拿体温计量发动机转速——能看到异常，但定位不到病灶。

流策略（Traffic Policy）配合流量统计（Traffic Statistics）就是解决这类问题的组合拳。前者解决“怎么管”，后者解决“管了之后怎么验证”。具体来说，流策略通过流分类（Traffic Classifier）+ 流行为（Traffic Behavior）+ 流策略（Traffic Policy）三段式结构，实现对特定流量的识别、处理与统计。识别靠 ACL 匹配五元组、VLAN、DSCP、MAC 等字段，处理靠 permit、deny、重标记、限速、重定向、镜像这些动作，统计则挂载在流行为里，按字节和报文数记录命中情况。

这套东西解决的问题很实在：某条专线带宽被谁吃掉了、某个业务口到底跑了多少流量、某类报文有没有被正确丢弃，全都能用命令行回答，不需要额外买探针设备。适合谁看？我建议三类人重点研究：一是负责园区网日常运维、需要给领导汇报“带宽去哪了”的工程师；二是做网络割接和策略变更、需要变更前后有量化对比的负责人；三是备考网络方向认证、流策略是必考且必须真机验证的考生。

需要提前说清楚一个前提：流策略是有方向性的，只能在接口的入方向（inbound）应用。很多人第一次配的时候习惯性想往出方向挂，结果命令敲下去报错，白白折腾半小时。记住这句话：想管从交换机出去的流量，得去它上游那台设备的入方向做。这个设计不是厂商偷懒，而是入方向处理可以在转发查表前完成，代价更低、对转发性能影响更小，出方向做复杂处理会牵涉队列调度，实现成本高。

2. 三段式结构拆解：分类、行为、策略各管什么

2.1 流分类：把“哪些流量”说清楚

流分类的本质是一个匹配器。你可以用 ACL 编号引用一条已经写好的访问控制列表，也可以直接在流分类里写 if-match 语句匹配 VLAN ID、802.1p 优先级、DSCP 值、源 MAC、目的 MAC 等。实际项目里我推荐用 ACL 的方式来组织，原因是 ACL 的匹配规则更丰富，源/目的 IP、端口号、协议号都能表达，而且 ACL 单独维护起来思路清晰，后期加条目不容易乱。

这里有个关键细节：ACL 里的规则是 permit 还是 deny，在流分类语境下表示的是“是否命中”，不表示“是否放行”。也就是说，一条rule 5 permit ip source 192.168.10.0 0.0.0.255放进流分类里，意思是“源网段为 192.168.10.0/24 的 IP 报文算作命中”，而不是“允许它通过”。这个语义错位是新手最容易栽的地方，我曾经见过有人为了“拒绝某网段”在 ACL 里写 deny，然后在流行为里配 permit，最后发现流量还是通的，百思不得其解。

流分类的匹配顺序也值得注意。同一条流策略里如果挂了多个流分类，设备是按绑定顺序从上往下匹配的，命中即停。所以写规则时要把更精确、更小的匹配范围放在前面，宽泛的兜底规则放最后。顺序写反了，宽规则会把细规则全部吃掉，表现为“我明明配了限速，怎么没生效”。

2.2 流行为：把“怎么处理”定下来

流行为里能配的动作分几大类，我按使用频率排个序，并用一张表说明各自适用场景和容易踩的坑：

其中 CAR（Committed Access Rate，承诺访问速率）是使用最广也最容易配错的。参数有两个：cir 是承诺信息速率，单位 kbps；cbs 是承诺突发尺寸，单位 byte。cbs 设置有个经验公式，粗略取cbs = cir × 突发时间 / 8，突发时间一般给 100ms 到 500ms。举个具体例子，要给某终端限 10Mbps，cir 就是 10240，如果按 200ms 突发算，cbs ≈ 10240 × 0.2 / 8 = 256，单位是 kbyte，命令里填 256000 字节。cbs 设太小的后果是正常突发流量被误丢，表现为“网速没到限速值就开始掉包”，这个现象很容易被误判成链路故障，我早期就被坑过一次，查了两天才发现是 cbs 抠得太紧。

2.3 流策略：把前两者绑在一起

流策略是个容器，里面用classifier 名字 behavior 名字把流分类和流行为配对。一个流策略可以绑多组分类-行为对，但顺序敏感。写完策略必须commit提交，这是华为设备的习惯，不提交不生效。这一条看起来是废话，但真有人忘了敲，然后对着配置界面发呆。

策略本身不带方向，应用到接口时才指定方向。基本格式是traffic-policy 策略名 inbound。应用之后可以用display traffic-policy applied-record看绑定关系，用display traffic policy statistics interface 接口 inbound看计数。计数清零用reset traffic policy statistics interface 接口 inbound，这个操作不可逆，变更前后对比数据时一定要先截图或导出。

3. 完整实操：从零配一条带统计的限速策略

3.1 需求定义与拓扑假设

我用一个虚拟场景把流程走完：某办公区接入交换机（假设为 S 系列三层交换机），上联口为 GigabitEthernet0/0/24，下挂终端位于 VLAN 10（192.168.10.0/24）。运维发现某台服务器 192.168.10.50 在夜间做备份时把上联带宽吃满，影响其他业务。需求是：对该服务器上传流量限制在 50Mbps，同时统计它实际跑了多少，便于后续评估是否需要单独拉线。

注意这里的方向陷阱：我们要限制的是服务器“上传”到上联的流量。如果策略挂在服务器所连接口的入方向，那限制的是服务器发出来的流量，是对的。但如果服务器和上联不在同一台设备，或者你挂在级联口上，就要想清楚哪一侧是入方向。本场景假设服务器直连本交换机 GigabitEthernet0/0/1，策略挂在该口入方向。

3.2 配置步骤逐条落地

先建 ACL，把目标主机圈出来。这里用 3000 号段的高级 ACL：

acl number 3000 rule 5 permit ip source 192.168.10.50 0 quit

接着建流分类，引用该 ACL：

traffic classifier limit_server operator or if-match acl 3000 quit

operator or表示多条 if-match 之间是“或”关系，只要命中一条就算命中。如果要求同时满足多个条件（比如特定源 IP 且特定目的端口），用operator and。这个关键字很多人不写，默认值在不同版本上行为可能不同，我建议显式写清楚，省得跨版本迁移时出问题。

然后建流行为，限速并开启统计：

traffic behavior limit_server car cir 51200 cbs 1280000 green pass yellow pass red discard statistics enable quit

cir 51200 对应 50Mbps（51200 × 1000 bit/s），cbs 给 1280000 字节，约等于 200ms 的突发量，计算方式：51200 kbps × 0.2 s / 8 = 1280 kbyte = 1280000 byte，和命令里的值对得上。green/yellow/red 分别代表承诺内、超出承诺但在突发内、超出突发，这里全用 pass 和 discard 是最简单粗暴的处理，实际生产里可以把 yellow 改成remark dscp af11降级转发，给关键业务让路。

接着建流策略并绑定：

traffic policy limit_server_policy classifier limit_server behavior limit_server quit

绑定到接口入方向：

interface GigabitEthernet0/0/1 traffic-policy limit_server_policy inbound quit

最后别忘了提交：

commit

3.3 验证与数据读取

配完不能就这么放着，要立刻验证三件事：策略是否挂上、流量是否命中、限速是否生效。

第一件事，看接口应用记录：

display traffic-policy applied-record

输出里会列出接口、方向、策略名、状态。状态显示 success 才算真正生效，显示 unsuccessful 通常是资源不足或者策略里有不支持的动作。

第二件事，看统计计数：

display traffic policy statistics interface GigabitEthernet0/0/1 inbound

输出里重点看两个字段：匹配该流分类的报文数和字节数。如果字节数一直是 0，说明没有流量命中，可能 ACL 写错、主机 IP 变了、或者流量方向搞反了。

第三件事，实测带宽。我一般用两台机器对打 iperf 的方式验证，或者直接在服务器上跑一个大文件传输，同时观察交换机计数增长速度。粗略换算：计数每秒增长多少字节，乘以 8 再除以 1000000，就是 Mbps。比如 10 秒增长了 62.5MB，那速率约等于 50Mbps，说明限速生效了。这个换算方法比看界面直观得多，我至今保留这个习惯。

提示：display traffic policy statistics默认只显示有命中的条目，如果策略刚配上还没流量，可能什么都不显示，别误以为是配置失败。

4. 流量统计的进阶用法与常见误区

4.1 只用统计不限速：摸清带宽基线

很多场景我们并不想限制，只想“看清楚”。这时候流行为里只配permit和statistics enable就够了，不需要 car。这种用法我强烈推荐给刚接手一个新网络的同行：先花一周时间把关键网段、关键业务端口的流量摸清楚，再决定哪里该限、限多少。没有基线的限速都是拍脑袋。

具体做法是按网段分类，比如给每个业务 VLAN 各建一个流分类，流行为统一 permit 加统计，策略挂在上联口入方向。这样上联口就成了一个天然的水表，每个 VLAN 跑了多少一目了然。要注意的是上联口入方向统计的是“从外部进入上联口”的流量，也就是下行流量；想看上行，得在下挂口入方向做，或者在对端设备的对应接口做。方向这件事说一百遍都不嫌多。

4.2 统计与 ACL 计数的区别

有人会问，ACL 本身也能配rule 5 permit ... counting，干嘛还要流策略统计?两者能用，但粒度不同。ACL 计数只能告诉你这条规则命中了多少报文，没法叠加限速、重标记、镜像这些动作，也没法按流策略维度统一查看。流策略统计的好处是可以和动作绑定，一边限速一边看命中量，还能按接口维度汇总。我的习惯是：纯排查用 ACL 计数，快；有策略需求用流策略统计，全。

4.3 一个高频坑：统计数字对不上业务量

有同行反馈，明明服务器跑了 100GB 的备份，流策略统计只有 40GB。排查下来有三种可能，我整理成速查表：

其中第一条最隐蔽：ACL 里写了source 192.168.10.0 0.0.0.255，但服务器实际走的是另一个网段或者有多个 IP，自然会漏。我的经验是排查阶段先把 ACL 放宽到整个网段，确认有计数后再收紧到单主机，一步步缩小范围，比一上来就精确匹配高效得多。

4.4 性能与资源注意事项

流策略不是免费的。每条策略都要占用设备的 TCAM 或等效硬件资源，流分类条目越多、匹配字段越复杂，占用越大。中低端盒式交换机上，复杂 ACL 加多级流策略可能导致资源耗尽，表现为策略下发失败或者部分规则不生效。实操中有几个降低风险的做法：能用一条 ACL 概括的不要拆成十条；匹配字段尽量少，比如能只看源 IP 就不要同时匹配源目 IP 加端口；上线前先在测试设备或者低峰期验证，观察display traffic-policy resource之类的资源占用命令。

还有一点，流量统计本身也消耗资源，尤其是开启统计的流分类数量多的时候。我的建议是统计只开在真正需要观测的条目上，观测完及时清理，别当成永久监控手段。长期监控还是得上网管系统采 SNMP 或者 NetStream/sFlow，交换机本地统计适合短周期、点对点的验证。

5. 我在实际项目里踩过的几个坑

先说一个印象最深的。某次割接，需要在核心交换机上给一条专线做限速，我按惯例写了 ACL、分类、行为、策略，挂到接口，commit，一套动作行云流水。结果第二天业务方反馈“网速确实慢了，但比约定的还慢一半”。查了半天配置没问题，最后发现是限速值单位理解偏差：我按 1Mbps = 1024kbps 换算的，设备那边 car 的 cir 是按 1000 进制理解的，数值上差了 2.4%，这不足以解释一半的差距，真正的元凶是 cbs 设成了默认值，突发量不够，导致 TCP 大量重传。这件事之后我养成一个习惯：凡是限速，必做 iperf 实测，不看数字看结果。

第二个坑关于策略顺序。有一次一个接口上挂了两条策略（不同时期加的，方向相同），设备只允许一个方向挂一条，结果新策略把旧的顶掉了，旧策略里的统计和限速全部失效，而且没有任何告警。发现这个问题是因为一周后复盘时发现某类流量突然没了统计。所以变更前一定要display traffic-policy applied-record看一眼现有的绑定关系，别想当然。

第三个是 ACL 的隐含 deny。ACL 末尾默认有一条 deny any，这没错，但流分类引用 ACL 时，未命中的流量走的是“不命中任何流分类”的路径，最终由流策略的默认动作决定——通常是 permit。也就是说，ACL 里没写进去的流量不会被悄悄丢掉，而是正常转发且不统计。这个行为是对的，但如果你误以为“挂上策略就全都管住了”，就会得出错误结论。要兜底，就在策略里加一个匹配 any 的流分类放最后，动作按需设置。

第四个关于统计清零的时机。变更前后对比数据是常规操作，但reset traffic policy statistics是按接口和方向整体清零的，不是按流分类。如果一个接口上挂了多个流分类，清零会一起清掉，这时候如果没提前记录其他条目的基线，对比就白做了。我的做法是变更前把所有相关计数导出成文本存档，命名带上时间戳，事后有据可查。

最后一个心得关于文档。流策略这种配置，ACL 编号、分类名、行为名、策略名四层嵌套，过三个月自己都未必记得当初为什么这么写。我现在的规矩是：每建一条策略，在设备描述或者配套的变更文档里写清楚三件事——管谁、管什么、为什么管。尤其是为什么，这是后来人（包括未来的自己）最需要的信息，也是判断这条策略能不能下线的唯一依据。没有这条记录的策略，宁可不加。

常见问题及排查技巧速查