4.2 Meter 表与限速报文

4.2 Meter 表与限速报文

本节摘要：Meter 是 OpenFlow 1.3 引入的原生限速结构：流条目通过 METER 指令把包送进计量器，计量器按若干 band 的速率阈值决定放行、降级或丢弃。本节拆解 Meter 与 band 的两级字段结构、令牌桶语义，并在实验台上配一个双速率限速器验证效果。

学习目标

阅读完本节，你应当能够：

1. 画出 Meter 条目与 band 的字段层次
2. 解释 DROP band 与 DSCP_REMARK band 的行为差异
3. 配置并验证一个双速率 Meter

Meter 条目与 band 层次

令牌桶语义

rate 是长期平均速率，burst_size 是允许的瞬间突发容量。工程直觉：令牌以 rate 恒速注入桶（容量 burst_size），包消耗令牌，桶空则触发 band。所以限速初期一小段流量不会掉包（消耗积累的令牌），稳态后才精确贴合 rate——这不是 bug，是避免"锯齿式"断流的设计。

双速率限速器（CBT 风格）用两个 band 实现：低阈值 band 用 DSCP_REMARK 降级，高阈值 band 用 DROP 兜底。配合 4.4 节的队列，就构成"软惩罚 + 硬惩罚"的完整 QoS 手段。

动手：限住 h1 的流量

实验台上配一个 1 Mbps、允许 10 KB 突发的 DROP Meter，并把 h1 的流量指过去：

sudo ovs-ofctl -O OpenFlow13 add-meter s1 \
  "meter=1,flags=kbps,burst,actions=drop" # 速率默认按 kbps 计

# OVS 语法展开写法（设置速率与突发）
sudo ovs-ofctl -O OpenFlow13 add-meter s1 \
  "meter=1,kbps,burst,band=rate=1000,burst_size=10240,actions=drop"

sudo ovs-ofctl -O OpenFlow13 add-flow s1 \
  "in_port=1,actions=meter:1,output:2"

# 验证：h1 用 iperf3 打流，观察吞吐被压在约 1 Mbps
mininet> h1 iperf3 -c h2 -t 10
​

再查 Meter 的统计（band 计数直接反映丢弃量）：

sudo ovs-ofctl -O OpenFlow13 dump-meter-stats s1
# 输出含 flow count、packet-in-band、byte-in-band
​

Wireshark 里的对应标本是 Meter-Mod（type=29）消息：meter_id、flags 位域、band 数组逐字段可见。

⚠️ 常见坑：flags 漏了 burst，突发容量退化为 0，限速器变成"逢包就掐"的锯齿刀，TCP 吞吐惨不忍睹。测出来的速率远低于配置值时先查这里。
⚠️ 常见坑：硬件交换机的 Meter 槽位有限（有时只有几个），逐台核对能力再规划计量器数量。

排错现场：限速不生效的三个原因

配了 Meter 却压不住流量，是限速实验的第一名问题。原因一，流表没引用：Meter 是被动结构，只有流条目里出现 meter 指令它才工作，dump-flows 确认目标流是否真的带着 meter:1。原因二，flags 不匹配：Meter 的 PKTPS 与 KBPS 两个标志决定 rate 的单位是包每秒还是千比特每秒，控制器按 kbps 下发、交换机按 pps 解释，结果就是"限了个寂寞"或干脆全丢。单位错配在抓包里表现为 Meter-Config-Stats 的回读值与你下发的数字对不上，回读永远是核对单位的第一手段：

sudo ovs-ofctl -O OpenFlow13 dump-meter-config s1
#   type=DROP rate=1000 burst_size=64   <- 回读确认单位与数值
sudo ovs-ofctl -O OpenFlow13 dump-meter-stats s1
#   duration=45.2s  <- band 计数在涨，说明确实有流量越限被处理
​

原因三，burst 给得太宽：令牌桶的突发额度允许短时间冲高，用短包突发测试时会看到吞吐先冲过阈值再回落，这不是 bug，是桶的数学。验证限速效果要用持续 30 秒以上的 iperf3，看的是稳态段而不是起始尖峰。

概念辨析：Meter 与防火墙限速、队列整形的边界

三件工具容易混用。Meter 在逻辑上挂在流水线里（meter 指令），对"匹配到这条流的包"执法，位置偏入口；队列整形挂物理端口，对所有进入该队列的流量统一调度，位置在出口；主机侧限速（tc 之类）在端系统，管的是发送方。设计防扫描策略时用 Meter（按流执法），保障语音带宽时用队列（按出口调度），两者解决的问题不同却常被当作同一个"限速功能"。判断口诀：问"限的是谁"——限一条流的行为用 Meter，限一个出口的总量用队列，限一个主机的发送用端上工具。三个都用对的系统，才谈得上完整的 QoS 设计，这也是下一节队列内容的引子。

还要点破一个容量事实：Meter 的个数是稀缺资源，软件交换机上看似无限，商用芯片上往往只有几百到几千个计量器。这意味着"按流限速"在硬件网络里常要退化为"按聚合限速"——几万条流共享一个 Meter，或者只在边界对租户级聚合执法。设计限速策略时先 dump-meter-features 问清容量，再决定粒度，顺序反了就会遇到"策略写完了装不进去"的尴尬。同理，band 数量也有限制，双速率结构（承诺速率加峰值速率）用两个 band 表达已是常见上限。

本节要点回顾

• 两级结构：Meter（id + flags + bands）→ band（rate + burst + 动作）
• band 两类：DROP 丢弃、DSCP_REMARK 降级；取最低触发阈值执行
• 令牌桶：rate 定长期、burst 定瞬时，初期放行是特性不是缺陷
• 验证链：Meter-Mod 下发 → 流表 METER 引用 → dump-meter-stats 观察

端口本身的生死与属性怎么管？下一节继续。