On Thu, Aug 27, 2015 at 5:36 AM, hui pang <pchui2...@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?

Thanks,
Alex Wang,



> My test script is as attached as the attachement. An example output is as
> follows:
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=185.030s, table=0, n_packets=549, n_bytes=23058,
> hard_timeout=3000, idle_age=64, priority=1,ip,nw_dst=10.0.0.5
> actions=output:2
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=185.028s, table=0, n_packets=601, n_bytes=25242,
> hard_timeout=3000, idle_age=64, priority=1,ip,nw_dst=10.0.0.5
> actions=output:3
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=185.026s, table=0, n_packets=546, n_bytes=22932,
> hard_timeout=3000, idle_age=64, priority=1,ip,nw_dst=10.0.0.5
> actions=output:3
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=185.023s, table=0, n_packets=601, n_bytes=25242,
> hard_timeout=3000, idle_age=64, priority=1,ip,nw_dst=10.0.0.5
> actions=output:3
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=185.021s, table=0, n_packets=546, n_bytes=22932,
> hard_timeout=3000, idle_age=64, priority=1,ip,nw_dst=10.0.0.5
> actions=output:1
> They are statistics from the flow rules injected firstly(the rules in the
> first table).
> The packet statistics of the second batch of flow rules is calculated from
> those statistics, say 52 = 601-549, 55 = 601-546, 55=601-546
>
> So, my doubt is why those statistics are not of the same quantity? Is
> there anything wrong with my method?
>
>
>
>
> _______________________________________________
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to