Hi all, we are currently experiencing a rather strange behaviour of the OVS in an OpenFlow environment, RYU being used as controller. This behaviour occurs both in the current 2.4 release and in the latest code from master branch compiled yesterday. OS is Debian 8 running in an ESXi virtualized environment.
While the traffic generation is already running, Ryu installs a set of rules using OpenFlow13, which also can be seen using "ovs-ofctl -O OpenFlow13 dump-flows br0". The following snipped shows an example to explain the nature of the installed flow entries. --- cookie=0x0, duration=65322.938s, table=0, n_packets=253215, n_bytes=133444585, ip,in_port=1,nw_dst=10.10.0.0/16 actions=write_metadata:0xa/0xff,goto_table:10 cookie=0x0, duration=65322.938s, table=0, n_packets=0, n_bytes=0, ip,in_port=1,nw_dst=10.0.0.0/29 actions=write_metadata:0xa/0xff,goto_table:10 cookie=0x0, duration=65322.938s, table=10, n_packets=253215, n_bytes=133444585, ip,metadata=0xa actions=set_field:(...)->eth_dst,set_field:(...)->eth_src,push_mpls:0x8847,set_field:(...)>mpls_label,output:2 --- For the sake of completeness, this paste shows the full output of the command above: http://pastebin.com/Wnq5CYtV Those flows are also shown using ovs-dpctl dump-flows, so they are installed in the kernel (there are plenty of them, however, so we posted the command output externally): http://pastebin.com/jncDptCV One example flow is shown below. The only thing we note here is the "bad key length" warning when setting the Ethernet addresses. It is however working in the first place. Putting 150Mbps of traffic works perfectly, it is forwarded and sent through the network. --- recirc_id(0),in_port(2),eth(src=00:50:56:82:59:b2,dst=00:50:56:82:dc:83),eth_type(0x0800),ipv4(src=8.0.0.0/8.0.0.0,dst=10.19.0.0/255.255.0.0,tos=0/0xfc,ttl=126,frag=no), packets:1864, bytes:1236339, used:0.118s, flags:FP., actions:set(eth(bad key length 24, expected 12)(00 50 56 82 29 cb 00 50 56 82 7c ac 0c 00 09 00 03 e9 31 7e 88 47 00 00)),push_mpls(label=16019,tc=0,ttl=126,bos=1,eth_type=0x8847),3 --- Next we remove the traffic load, such that there is no traffic at all going through the OVS instance. After a few seconds, the kernel cache seems to be cleared, as "ovs-dpctl dump-flows" produces no output at all. Then we start the same traffic again, which actually does arrive at the OVS instance (TX packets on ingress interface seen with bwm-ng), but it is not forwarded. In the first few seconds, the flow rules are installed again (but much less than before): http://pastebin.com/uAhqAaMQ After a few more seconds, there is only one rule left which actually drops all the packets: --- recirc_id(0),in_port(2),eth(src=00:50:56:82:59:b2,dst=00:50:56:82:dc:83),eth_type(0x0800),ipv4(src=2.0.0.0/2.0.0.0,dst=10.0.0.0/250.0.0.0,frag=no), packets:2882140, bytes:1198579242, used:0.000s, flags:SFPR.C, actions:drop --- In the OpenFlow rules installed by RYU there is not a single rule which drops packets. The OpenFlow rules are however still present, "ovs-ofctl -O OpenFlow13 dump-flows br0" still shows the same flows than before. Further, the switch is still connected to the controller, and we can see no error output in the log files. Restarting RYU and hence re-installing the OpenFlow rules solves the issue for the moment, but as soon the flows are removed from the kernel datapath and are re-inserted again, this problem appears again. It is reproducible on our nodes. This problem seems to be related by the communication between the userspace and kernel module. When the datapath is set to be a netdev device, this issue does not occur at all, but throughput is limited. Could this be a bug of some kind? And another question: Do you think using DPDK as datapath could solve the issue? Thanks in advance and best regards Daniel _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
