[ovs-discuss] Flow Expiration returning zeros for byte/packet counts

David Erickson 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 
>> 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-> 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-> 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-> 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-> 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-> 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 
>> 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.

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 
> though.

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...
Name: ovs_netflow.log
Type: text/x-log
Size: 202 bytes
Desc: not available
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20091113/b4296af8/attachment-0004.bin>

More information about the discuss mailing list