[ovs-discuss] Wrong flow statistics

hui pang pchui2012 at gmail.com
Thu Aug 27 23:27:56 UTC 2015


Thanks for your reply. I have noticed the procedure of flow expire yet. In
this situation, I think, the packet count of the first rule should smaller
than the other two, say 52, 54, 54. But in my experiment, I also find some
situations in which the packet count of the first rule is bigger than the
other two, e.g., 54, 52, 52. I want to know if there is any explanation
about this? Thanks!

2015-08-28 0:53 GMT+08:00 Ben Pfaff <blp at nicira.com>:

> On Thu, Aug 27, 2015 at 09:48:25AM -0700, Alex Wang wrote:
> > On Thu, Aug 27, 2015 at 5:36 AM, hui pang <pchui2012 at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I'm attempting to collect packet statistics from flow remove messages.
> But
> > > I found some flow statistics are of no consistence.
> > >
> > > The topology of my experiment is a linear one, which is generated from
> "mn
> > > --topo=linear,5,1".
> > > i.e., h1 -- s1-eth1 -- s1-eth2 -- s2-eth2 -- s2-eth3 -- s3-eth2 --
> s3-eth3
> > > -- s4-eth2 -- s4-eth3 -- s5-eth2 -- s5-eth1 -- h5. (some host are
> ignored).
> > > And in my experiment, packets are forwarded according to its IPv4
> > > destination address.
> > > Firstly, I inject the following rules to assure every IP packets can be
> > > forwarded from h1 to h5 without any PacketIn message being triggered.
> > >
> > >
> ----------------------------------------------------------------------------------------
> > >   switch |                          rule
> > >
> > >
> ----------------------------------------------------------------------------------------
> > >     s1     |   ip,nw_dst=10.0.0.5,priority=1,actions=output:2
> > >     s2     |   ip,nw_dst=10.0.0.5,priority=1,actions=output:3
> > >     s3     |   ip,nw_dst=10.0.0.5,priority=1,actions=output:3
> > >     s4     |   ip,nw_dst=10.0.0.5,priority=1,actions=output:3
> > >     s5     |   ip,nw_dst=10.0.0.5,priority=1,actions=output:1
> > >
> > >
> -----------------------------------------------------------------------------------------
> > > Secondly, I use traffic generation tool (nping) to inject traffic from
> h1
> > > to h5 (h1 nping -N -udp -g 2000 -p 3000-3600 -delay 0.2 -c 1
> 10.0.0.5). And
> > > destination port is also used as an identity.
> > > Thirdly, I insert new rules on s5 and s3 to count packets directed to
> h5
> > > and with the tos field set to 24, and the hard timeout of those rule
> is set
> > > to 30 seconds. Besides, those rules have a priority of 2.
> > > Finally, I install a new rule on s1 to set the tos field to 24 for all
> > > traffic toward to 10.0.0.5. Also, this rule have a priority of 2 and
> its
> > > hard timeout is set to 10 seconds.
> > > Those three rules are listed as follows:
> > >
> > >
> ----------------------------------------------------------------------------------------------------------------------------------------
> > >   switch |                          rule
> > >
> > >
> ----------------------------------------------------------------------------------------------------------------------------------------
> > >     s1     |
> > >
> ip,nw_dst=10.0.0.5,priority=2,hardtimeout=10,actions=mod_nw_tos=24,output:2
> > >     s3     |
> > > ip,nw_dst=10.0.0.5,nw_tos=24,priority=2,hardtimeout=30,actions=output:3
> > >     s5     |
> > > ip,nw_dst=10.0.0.5,nw_tos=24,priority=2,hardtimeout=30,actions=output:1
> > >
> > >
> -----------------------------------------------------------------------------------------------------------------------------------------
> > > In general, those three rules should report the same flow statistics
> after
> > > their expire, but actually, the first rule (on s1) report a different
> (at a
> > > distance of about 1 or 2 packets) packet count and byte count some
> times.
> > > For example, the statistics may be: 52 55 55.
> > >
> >
> > Hey,
> >
> > Here is my understanding,
> >
> > Not sure the version of ovs you used, but say for branch-2.3, the flow
> > expiration is handled by
> > ofproto_rule_expire(), which will call delete_flow__()...
> >
> > The delete_flow__() will first call ofproto_rule_send_removed() which
> sends
> > the flow deletion
> > notification to any controller, and then actually deletes the flow...
> >
> > In other words, when ovs reports the flow deletion, the flow is valid
> still
> > there...  and we may fail
> > to include the final stats (between notifying flow deletion and actually
> > deleting the flow in
> > datapath)...
> >
> > Ben, do you think we should address this?
>
> It's hard to get statistics that are perfect in all cases without
> hurting performance.  It's not usually that important.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150828/2d5777d5/attachment-0002.html>


More information about the discuss mailing list