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 流行为把“怎么处理”定下来流行为里能配的动作分几大类我按使用频率排个序并用一张表说明各自适用场景和容易踩的坑动作类型典型命令适用场景注意点允许并统计permitstatistics enable摸清某类流量基线统计必须显式开启光 permit 不产生计数拒绝deny封禁违规终端或危险端口入方向丢弃后上游无感知排查时看计数重标记优先级remark 8021p/remark dscp语音、视频优先保障需下游设备信任该优先级才有效流量限速car cir ... cbs ...限制某终端或某业务上行带宽单位换算易错cbs 不宜设过小重定向redirect ip-nexthop引流到审计或清洗设备下一跳必须可达否则黑洞流量镜像mirror to observe-port抓包分析观察口带宽要够否则丢包其中 CARCommitted Access Rate承诺访问速率是使用最广也最容易配错的。参数有两个cir 是承诺信息速率单位 kbpscbs 是承诺突发尺寸单位 byte。cbs 设置有个经验公式粗略取cbs cir × 突发时间 / 8突发时间一般给 100ms 到 500ms。举个具体例子要给某终端限 10Mbpscir 就是 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 10192.168.10.0/24。运维发现某台服务器 192.168.10.50 在夜间做备份时把上联带宽吃满影响其他业务。需求是对该服务器上传流量限制在 50Mbps同时统计它实际跑了多少便于后续评估是否需要单独拉线。注意这里的方向陷阱我们要限制的是服务器“上传”到上联的流量。如果策略挂在服务器所连接口的入方向那限制的是服务器发出来的流量是对的。但如果服务器和上联不在同一台设备或者你挂在级联口上就要想清楚哪一侧是入方向。本场景假设服务器直连本交换机 GigabitEthernet0/0/1策略挂在该口入方向。3.2 配置步骤逐条落地先建 ACL把目标主机圈出来。这里用 3000 号段的高级 ACLacl number 3000 rule 5 permit ip source 192.168.10.50 0 quit接着建流分类引用该 ACLtraffic classifier limit_server operator or if-match acl 3000 quitoperator or表示多条 if-match 之间是“或”关系只要命中一条就算命中。如果要求同时满足多个条件比如特定源 IP 且特定目的端口用operator and。这个关键字很多人不写默认值在不同版本上行为可能不同我建议显式写清楚省得跨版本迁移时出问题。然后建流行为限速并开启统计traffic behavior limit_server car cir 51200 cbs 1280000 green pass yellow pass red discard statistics enable quitcir 51200 对应 50Mbps51200 × 1000 bit/scbs 给 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最后别忘了提交commit3.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检查 ACL 掩码、协议号、端口范围统计值只有单向只在一个方向应用了策略确认入方向是哪一侧必要时对端也配统计值时有时无策略被其他策略覆盖或接口切换查 applied-record 状态与策略绑定顺序计数增长但业务异常car 的 cbs 过小导致误丢加大 cbs按 200ms 突发重算其中第一条最隐蔽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 编号、分类名、行为名、策略名四层嵌套过三个月自己都未必记得当初为什么这么写。我现在的规矩是每建一条策略在设备描述或者配套的变更文档里写清楚三件事——管谁、管什么、为什么管。尤其是为什么这是后来人包括未来的自己最需要的信息也是判断这条策略能不能下线的唯一依据。没有这条记录的策略宁可不加。常见问题及排查技巧速查常见问题可能原因排查与解决方法策略配置后不生效忘记 commit 或接口未绑定执行 commit检查 applied-record 状态统计计数始终为 0ACL 未命中、方向错误、流量未经过该接口放宽 ACL 验证、确认入方向、检查流量路径限速后网速远低于设定值cbs 过小导致突发流量被丢按 cir×200ms/8 重算 cbs 并调大多个流分类顺序错乱宽泛规则在前覆盖了精确规则调整绑定顺序精确规则优先策略下发失败硬件资源不足或动作不支持精简匹配字段、减少条目、查看资源占用统计值与业务量不符单向统计或部分流量绕过接口双向部署策略或在对端设备补充统计策略被覆盖同接口同方向重复应用变更前查看 applied-record合并策略
