David Erickson wrote:
1. If you query the flow stats before the expiration message, do you
get the right results? You mentioned that this was true before but
these flows are less than your 10 second polling interval.
The values still look wrong from the stats message, I just did a test
where I bumped up the polling rate so I would send a stats message
while the flow was idle but before timeout and got the following:
Nov 12 16:14:01 epic nox: 00087|Flow_tracker:DBG Posting an update
event- dpid: 003048b06117 duration: 16 pkt count: 58467 byte count
254630713
Nov 12 16:14:02 epic nox: 00101|Flow_tracker:DBG Flow expiration from
dpid: 003048b06117 duration: 16 pkts: 58467 bytes: 254630713 flow:
port0002:vlanffff mac22:db:ed:04:cb:a4->7a:4a:0f:e9:1b:bd proto0800
ip10.79.2.13->10.79.2.12 port80->54241
Can you also send me the output of ovs-dpctl dump-flows while running
this test? Hopefully it isn't too hard to hit the time window. So:
ovs-dpctl dump-flows <bridge>
2. Does the problem also occur if you use wildcarded rules instead of
exact match?
It actually gets worse, I wildcarded vlan and the expiration messages
now have 0's, but the stats message is similar to the above listed
message.
It looks like what is happening is that two expiration messages are sent
out - one for the actual wildcarded flow with the correct stats and one
or more for the exact match flows from actual traffic with zeroed
stats. I sent out patch for review which suppresses the exact match
flows from wildcarded entries.
3. When do you insert the flows? Before any packets are sent? In
response to a packet in?
In response to a packet in.
Is it possible that your controller is adding the same flow more than
once? Doing so would zero out all that stats on the previously add rule.
5. Do you see similar results with NetFlow? You can use Wireshark as
a simple NetFlow collector if you don't have one - just tell it to
decode the traffic as cflow.
Can you give me more information on how to do this? IE are netflow
packets automatically broadcast out? IE if I start up tcpdump on
xen's dom0 which interface should I listen to? Do I need to explicitly
tell OVS somehow to pump out netflow messages?
The easiest thing to do is set the key
netflow.<bridge>.host=<host>:<port> to some machine running Wireshark
and then tell it to decode that destination port as cflow. You could
also point it to any random place and capture from dom0. The packets
will go out dom0's IP stack, so whatever interface that is on the
appropriate network (probably xenbr0) is where you want to capture
from. I don't think that tcpdump itself knows how to decode NetFlow though.
Thanks,
Jesse
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
