一个流在 OVS 不正确地命中了 OpenFlow 流表

Question

我的问题是，尽管流的属性与表完美匹配，但流并未命中 OpenFlow 流表。

---

我用mininet,ONOS,Iperf做了一个小实验。

我想根据srcIP、dstIP、UDP、dstPort查看流路由。

因此，我生成了一个 UDP 流（srcIP=10.0.0.3，dstIP=10.0.0.2，dstPORT=50000）

我使用ONOS REST api 向每个 mininet 交换机添加流规则。

您可以在原始流规则下方看到两个流规则。

1)  cookie=0x4c0000ef7faa8a, duration=332.717s, table=0, n_packets=8974, 
n_bytes=557090858, idle_age=153, priority=65050,ip,nw_dst=10.0.0.2 
actions=output:4

2) cookie=0x4c0000951b3b33, duration=332.636s, table=0, n_packets=10, 
n_bytes=460,idle_age=168,priority=65111,udp,nw_src=10.0.0.3,nw_dst=10.0.0.2,
tp_dst=50000 actions=output:3

虽然 2) 流规则有更多的优先级更高的匹配字段，但流中的大多数数据包都符合 1) 流规则。

我使用Wireshark 来检查流量是否正确生成。不过没问题。(srcIP=10.0.0.3, dstIP=10.0.0.2, dstPORT=50000)

这怎么可能发生？能否给我一些解决问题的提示？

感谢阅读！

---

nimdrak@nimdrak-VirtualBox:~$ sudo ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
 cookie=0x4c0000ef7faa8a, duration=332.717s, table=0, n_packets=8974, n_bytes=557090858, idle_age=153, priority=65050,ip,nw_dst=10.0.0.2 actions=output:4
 cookie=0x4c0000ef7fb20c, duration=332.679s, table=0, n_packets=127, n_bytes=36814, idle_age=305, priority=65050,ip,nw_dst=10.0.0.4 actions=output:3
 cookie=0x4c0000ef7f9b86, duration=332.736s, table=0, n_packets=518, n_bytes=102960, idle_age=138, priority=65050,ip,nw_dst=10.0.0.254 actions=output:5
 cookie=0x4c0000ef7fae4b, duration=332.698s, table=0, n_packets=270, n_bytes=49059, idle_age=138, priority=65050,ip,nw_dst=10.0.0.3 actions=output:2
 cookie=0x4c0000ef7fa6c9, duration=332.751s, table=0, n_packets=125, n_bytes=36646, idle_age=305, priority=65050,ip,nw_dst=10.0.0.1 actions=output:1
 cookie=0x10000487f5557, duration=348.362s, table=0, n_packets=285, n_bytes=23085, idle_age=66, priority=40000,dl_type=0x88cc actions=CONTROLLER:65535
 cookie=0x10000487f63a1, duration=348.362s, table=0, n_packets=285, n_bytes=23085, idle_age=66, priority=40000,dl_type=0x8942 actions=CONTROLLER:65535
 cookie=0x10000488ebd5d, duration=348.362s, table=0, n_packets=12, n_bytes=504, idle_age=148, priority=40000,arp actions=CONTROLLER:65535
 cookie=0x10000464443e2, duration=348.362s, table=0, n_packets=0, n_bytes=0, idle_age=348, priority=5,arp actions=CONTROLLER:65535
 cookie=0x4c0000951a5275, duration=332.671s, table=0, n_packets=0, n_bytes=0, idle_age=332, priority=65050,udp,nw_src=10.0.0.3,nw_dst=10.0.0.1,tp_dst=50000 actions=output:1
 cookie=0x4c0000951b3b33, duration=332.636s, table=0, n_packets=10, n_bytes=460, idle_age=168, priority=65111,udp,nw_src=10.0.0.3,nw_dst=10.0.0.2,tp_dst=50000 actions=output:3

Answer 1

我解决了这个问题。该问题与 UDP 碎片

有关

当我写评论时，我发现只有小的 UDP 数据报正确地命中了流表。

也就是说，是因为UDP数据报太大了。

我将 UDP 数据报设置为 63k。然后在IP层进行分片。

然后唯一的第一个数据包具有 UDP 标头信息，并且只有数据包正确地命中了流表，正如我所料。

为了解决这个问题，我使用 Jumbo 帧，这意味着 OVS 可以处理更大 MSS 的数据包。

我们还应该设置 NIC MSS。 (http://docs.openvswitch.org/en/latest/topics/dpdk/jumbo-frames/)

我们更新 OVS 版本高于 2.6.0 （使用http://docs.openvswitch.org/en/latest/intro/install/general/ 比我们可以google 的其他网站更好）

设置 Jumbo 帧后，我们可以看到流表命中对于较大的 UDP 数据报正常工作。