OpenFlow规则匹配咨询：低优先级规则为何被执行？附具体规则

我来帮你拆解这个问题——这事儿涉及OpenFlow规则匹配的核心逻辑，还有OVS可能的特殊行为细节，咱们一步步来捋清楚。

先给你划个重点：按照OpenFlow官方规范，当多个流规则都能匹配同一个数据包时，交换机必须选择优先级最高的规则执行（优先级数值越大，等级越高）。你提供的两条规则里，第二条优先级是9999，远高于第一条的1，所以按规范要求，应该执行第二条规则。

那为什么实际场景中OVS反而执行了低优先级的第一条？咱们先把两条规则清晰列出来，再逐个分析可能的原因：

第一条规则（优先级1）：

cookie=0x20000002000000, duration=14647.575s, table=0, n_packets=1297621, n_bytes=145897910, idle_timeout=65535, priority=1, udp, in_port=3, dl_src=02:6d:f3:c1:b4:7b, dl_dst=02:54:ab:ce:ba:0f, nw_src=10.10.10.6, nw_dst=10.10.10.1, tp_src=46329, tp_dst=1000 actions=output:1

第二条规则（优先级9999）：

cookie=0xa000004039d1ae, duration=164.680s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=9999, udp, in_port=ANY, nw_src=10.10.10.6, nw_dst=10.10.10.1, tp_dst=1000 actions=set_field:10.10.10.6->ip_src, output:1

可能的原因分析： #

• 数据包未真正匹配第二条规则
  虽然看起来两条规则的核心匹配项（UDP协议、IP地址、目标端口）一致，但第二条规则的in_port=ANY是否真的覆盖了数据包的入端口？在OVS里ANY确实代表所有端口，但如果你的数据包入端口是3（和第一条一致），理论上应该匹配第二条。不过可以检查细节：比如第二条规则的send_flow_rem和priority=9999之间缺少逗号，这可能导致OVS解析规则时出错，规则实际未被正确安装（毕竟它的n_packets=0，说明从来没有数据包匹配过）。

• OVS旧版本的性能优化特性
  很多人会误以为“更精确的匹配优先”，但OpenFlow规范里优先级是第一判定条件。不过在某些旧版本的OVS中，存在一个特殊的性能优化：如果一条规则是完全精确匹配（所有字段都指定了具体值），而另一条是通配匹配，即使精确匹配的规则优先级更低，也可能被优先执行——因为精确匹配的规则被放在了更快的硬件/内存查找路径中，绕过了优先级判断。

• 硬件加速的影响
  如果你的OVS启用了硬件加速（比如SR-IOV或Open vSwitch硬件卸载），第一条规则可能被卸载到硬件中执行，而第二条规则因为包含set_field动作（部分硬件不支持这类动作卸载），只能在软件路径执行。硬件路径的规则会优先于软件路径，即使它的优先级更低。

验证建议： #

1. 用ovs-ofctl dump-flows <你的网桥名>确认两条规则都正确存在，且优先级无误；
2. 发送一个符合第二条规则但不符合第一条规则的数据包（比如从in_port=2进入，IP和端口匹配的UDP包），看是否能触发第二条规则；
3. 如果启用了硬件加速，暂时禁用后再测试原有数据包的匹配情况。

内容的提问来源于stack exchange，提问作者mnmp