[ovs-discuss] Flow Expiration returning zeros for byte/packet counts
derickso at stanford.edu
Fri Nov 13 19:28:05 UTC 2009
Jesse Gross wrote:
> 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
>> 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>
Here is output after the transfer is complete from the machine doing the
[root at mg-xen1 ~]# ovs-dpctl dump-flows xenbr1
in_port0002:vlan65535 mac7a:4a:0f:e9:1b:bd->22:db:ed:04:cb:a4 type0800
proto6 ip10.79.2.12->10.79.2.13 port49041->80, packets:18781,
bytes:1253463, used:4.258s, actions:1
in_port0001:vlan65535 mac22:db:ed:04:cb:a4->7a:4a:0f:e9:1b:bd type0800
proto6 ip10.79.2.13->10.79.2.12 port80->49041, packets:173232,
bytes:262219683, used:4.258s, actions:2
and the machine hosting apache:
[root at mg-xen2 ~]# ovs-dpctl dump-flows xenbr1
in_port0002:vlan65535 mac22:db:ed:04:cb:a4->7a:4a:0f:e9:1b:bd type0800
proto6 ip10.79.2.13->10.79.2.12 port80->49041, packets:6508,
bytes:251215899, used:2.689s, actions:1
in_port0001:vlan65535 mac7a:4a:0f:e9:1b:bd->22:db:ed:04:cb:a4 type0800
proto6 ip10.79.2.12->10.79.2.13 port49041->80, packets:18782,
bytes:1253529, used:2.689s, actions:2
>>> 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
> 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.
No I wiresharked the controller and it is only sending the one flow mod
in each direction to all switches at the same time.
>>> 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
I've attached the packet dump of the netflow message from the switch
causing the problems. Also as an aside, I was only able to get it to
send one netflow message because my machine returned an icmp error back
to ovs since I am not listening on that port.. is there a way to
disregard those errors and keep sending netflow messages?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 202 bytes
Desc: not available
More information about the discuss