Hi All,
We encountered a dramatic drop of bandwidth on some OVS ports, and
discovered that it was caused by overly broad slow_path flow that does not
disappear as long as there is any traffic on the port. The flow looks like
this:
recirc_id(0),in_port(3),*eth()*,eth_type(0x0800),ipv4(frag=no), packets:1,
bytes:54, used:0.928s, *actions:userspace(pid=4294967295,slow_path(match)) *
Note that it intercepts _all_ IP traffic from a port.
It looks like this situation is triggered when an IGMP packet arrives on
the port in the presence of user-installed openflow rules that prevent it
from being processed by the flow "priority=0 table=0 actions=NORMAL" that
is created in any bridge by default.
The following script reproduces this situation by installing a flow that
redirects traffic, but any other user defined flow will do, if it diverts
or drops the packet before it can reach the default flow.
```
#!/usr/bin/sudo /bin/sh
ip link del veth0 2>/dev/null
ip link del lnxbr 2>/dev/null
ovs-vsctl del-br ovsbr 2>/dev/null
# cleanup done
ovs-vsctl add-br ovsbr
ip link add lnxbr type bridge
ip link add veth0 type veth peer veth1
ip link set veth1 master lnxbr
ovs-vsctl add-port ovsbr veth0
ofport=`ovs-dpctl show | awk '/veth0/{gsub(":","",$2); print $2}'`
ovs-ofctl add-flow ovsbr cookie=0x1,priority=10,actions=${ofport}
ip link set veth0 up
ip link set veth1 up
ip link set lnxbr up # This triggers some multicast packets
sleep 1 # Give OVS time to install kernel flows
echo ==== userspace flows:
ovs-ofctl dump-flows ovsbr
echo ==== kernel flows:
ovs-appctl dpctl/dump-flows
```
( In the above config, one end of a veth pair is enslaved to the ovs bridge
while the other is part of a linux bridge. This is for the ease of
generating IGMP traffic. )
After running this, there is a kernel flow similar to the one shown above.
Particular kernel flow depends on the contents of the user- defined flow;
if user-defined flow had actions "output" or "resubmit", the kernel flow
will be slow_path.
This looks like a problem in the way OVS handles IGMP traffic? Maybe there
is some way to mitigate it?
Something worth noting is that, if the IGMP traffic hits the rule with
"actions=NORMAL" (in the absence of any other matching rule of higher
prio), then the userpath rule is installed with a filter
*eth(src=xx:xx:xx:xx:xx,
dst=**01:00:5e:00:00:16), *which looks like the right approach.
Would be great if this could be fixed to behave the same even in the
presence of other user-defined openflow rules matching the traffic, or if
you could share some workaround for the same. Thanks in advance!
Thanks,
Reshma
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
