[ovs-discuss] Unexpected behavior of counters when installing new flow

Mon Jul 29 09:25:52 UTC 2013

Sorry for the late follow up...

I've tried the fix (directly pulled the code from git) and it seems to work
fine now.
However the fix is probably not yet included in any stable release on the
website (patch was submitted on 3 May and v1.10.0 was released on 1 May)...

2013/7/28 Kyriakos Zarifis <kyr.zarifis at gmail.com>

> I was wondering if there was any follow-up. I was getting a similar
> behavior with OVS 1.4, installed v1.10 and I think I am seeing the same
> (did the same commit make it to 1.10, or only 1.9?)
>
> What I'm seeing is
> a) Counters from the low-priority entry are transferred to the
> higher-priority overlapping entry once the latter gets installed, and the
> low-prio one now has empty counters (is that expected behavior?)
> b) Once the higher priority entry is removed, the lower-priority entry
> starts counting again from 0 (which makes sense, if (a) is expected
> behavior)
>
> Thanks
>
>
> On Mon, May 13, 2013 at 10:18 AM, Tmusic <Tmusic987 at gmail.com> wrote:
>
>> Not yet...
>> I'm quite busy now, but I'll try as soon as possible
>>
>> Regards,
>>
>> Tim
>>
>>
>> 2013/5/12 Ben Pfaff <blp at nicira.com>
>>
>>> Did you get a chance to verify that this commit fixes the issue for you?
>>>
>>> On Sun, May 12, 2013 at 07:03:12PM +0200, Tmusic wrote:
>>> > Just to finish this topic,
>>> >
>>> > It should be fixed with this commit:
>>> >
>>> http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commit;h=eafed69b66fa5b7b69035fe5aa2ae2102d66d6f6
>>> >
>>> > A huge thank you to Ethan Jackson and Ben Pfaff for fixing this
>>> issue!! :D
>>> >
>>> > Kind regards,
>>> >
>>> > Tim
>>> >
>>> >
>>> > 2013/5/7 Tmusic <Tmusic987 at gmail.com>
>>> >
>>> > > I don't have a specific reason to use 1.7, so I can try with 1.9
>>> > > This week or next I'll have to rebuild the test network, so that
>>> seems
>>> > > like a good time for the upgrade :)
>>> > >
>>> > > I'll keep you up to date!
>>> > >
>>> > > Regards,
>>> > >
>>> > > Tim
>>> > >
>>> > >
>>> > > 2013/5/2 Ben Pfaff <blp at nicira.com>
>>> > >
>>> > >> That helps narrow down the possible problems.
>>> > >>
>>> > >> Do you have to use 1.7?  It would be helpful to know if you see the
>>> > >> same problem with 1.9, which is a series that we're maintaining
>>> > >> long-term.
>>> > >>
>>> > >> On Wed, May 01, 2013 at 11:05:06AM +0200, Tmusic wrote:
>>> > >> > Hi,
>>> > >> >
>>> > >> > First to make sure there are no misunderstandings: the entries in
>>> the
>>> > >> > switch are installed by the POX controller (as you have probably
>>> already
>>> > >> > noticed).
>>> > >> >
>>> > >> > For the test below (what you proposed) I added the /31 entry by
>>> hand to
>>> > >> > make sure the issue is not due to some controller logic issue.
>>> And just
>>> > >> a
>>> > >> > remark: traffic is same as in the previous mail but at 1000
>>> packet/s to
>>> > >> > make it easier to interpret the values.
>>> > >> >
>>> > >> > So starting traffic, let controller install entries and dump
>>> after a
>>> > >> some
>>> > >> > time:
>>> > >> >
>>> > >> > NXST_FLOW reply (xid=0x4):
>>> > >> >  cookie=0x3e8, duration=23.611s, table=0, n_packets=28,
>>> n_bytes=16520,
>>> > >> > idle_age=0, icmp,nw_src=10.1.6.0/30,nw_dst=10.1.4.0/30actions=output:1
>>> > >> >  cookie=0x0, duration=52.033s, table=0, n_packets=31,
>>> n_bytes=1860,
>>> > >> > idle_age=0, priority=65000,dl_dst=01:23:20:00:00:01,dl_type=0x88cc
>>> > >> > actions=CONTROLLER:65535
>>> > >> >  cookie=0x3eb, duration=18.558s, table=0, n_packets=0, n_bytes=0,
>>> > >> > idle_age=18, arp,dl_src=00:25:90:64:f9:3e,dl_dst=90:e2:ba:00:9f:86
>>> > >> > actions=output:2
>>> > >> >  cookie=0x3ea, duration=18.598s, table=0, n_packets=1, n_bytes=60,
>>> > >> > idle_age=18, arp,dl_src=90:e2:ba:00:9f:86,dl_dst=00:25:90:64:f9:3e
>>> > >> > actions=output:1
>>> > >> >  cookie=0x3e9, duration=23.606s, table=0, n_packets=23544,
>>> > >> > n_bytes=25097904, idle_age=0, udp,nw_src=
>>> > >> > 10.1.4.0/30,nw_dst=10.1.6.0/30,tp_src=20,tp_dst=1000actions=output:2
>>> > >> >
>>> > >> >
>>> > >> > Kill traffic generation and dump:
>>> > >> >
>>> > >> > NXST_FLOW reply (xid=0x4):
>>> > >> >  cookie=0x3e8, duration=40.183s, table=0, n_packets=30,
>>> n_bytes=17700,
>>> > >> > idle_age=15, icmp,nw_src=
>>> 10.1.6.0/30,nw_dst=10.1.4.0/30actions=output:1
>>> > >> >  cookie=0x0, duration=68.605s, table=0, n_packets=41,
>>> n_bytes=2460,
>>> > >> > idle_age=0, priority=65000,dl_dst=01:23:20:00:00:01,dl_type=0x88cc
>>> > >> > actions=CONTROLLER:65535
>>> > >> >  cookie=0x3eb, duration=35.13s, table=0, n_packets=1, n_bytes=60,
>>> > >> > idle_age=10, arp,dl_src=00:25:90:64:f9:3e,dl_dst=90:e2:ba:00:9f:86
>>> > >> > actions=output:2
>>> > >> >  cookie=0x3ea, duration=35.17s, table=0, n_packets=2, n_bytes=120,
>>> > >> > idle_age=10, arp,dl_src=90:e2:ba:00:9f:86,dl_dst=00:25:90:64:f9:3e
>>> > >> > actions=output:1
>>> > >> >  cookie=0x3e9, duration=40.178s, table=0, n_packets=*25049,
>>> > >> n_bytes=26702234
>>> > >> > *, idle_age=15, udp,nw_src=
>>> > >> > 10.1.4.0/30,nw_dst=10.1.6.0/30,tp_src=20,tp_dst=1000actions=output:2
>>> > >> >
>>> > >> > Starting traffic again and dump:
>>> > >> >
>>> > >> >  cookie=0x3e8, duration=64.755s, table=0, n_packets=55,
>>> n_bytes=32450,
>>> > >> > idle_age=0, icmp,nw_src=10.1.6.0/30,nw_dst=10.1.4.0/30actions=output:1
>>> > >> >  cookie=0x0, duration=93.177s, table=0, n_packets=54,
>>> n_bytes=3240,
>>> > >> > idle_age=3, priority=65000,dl_dst=01:23:20:00:00:01,dl_type=0x88cc
>>> > >> > actions=CONTROLLER:65535
>>> > >> >  cookie=0x3eb, duration=59.702s, table=0, n_packets=3,
>>> n_bytes=180,
>>> > >> > idle_age=9, arp,dl_src=00:25:90:64:f9:3e,dl_dst=90:e2:ba:00:9f:86
>>> > >> > actions=output:2
>>> > >> >  cookie=0x3ea, duration=59.742s, table=0, n_packets=4,
>>> n_bytes=240,
>>> > >> > idle_age=9, arp,dl_src=90:e2:ba:00:9f:86,dl_dst=00:25:90:64:f9:3e
>>> > >> > actions=output:1
>>> > >> >  cookie=0x3e9, duration=64.75s, table=0, n_packets=44305,
>>> > >> n_bytes=47229130,
>>> > >> > idle_age=0, udp,nw_src=
>>> > >>
>>> 10.1.4.0/30,nw_dst=10.1.6.0/30,tp_src=20,tp_dst=1000actions=output:2
>>> > >> >
>>> > >> >
>>> > >> > Adding entry by hand (sudo ovs-ofctl add-flow br0
>>> > >> > cookie=0x3e8,table=0,udp,nw_src=
>>> > >> >
>>> > >>
>>> 10.1.4.0/31,nw_dst=10.1.6.2/31,tp_src=20,tp_dst=1000,priority=65100,actions=output:2
>>> > >> )
>>> > >> > and dump:
>>> > >> >
>>> > >> > NXST_FLOW reply (xid=0x4):
>>> > >> >  cookie=0x3e8, duration=1.584s, table=0, n_packets=38256,
>>> > >> n_bytes=40780896,
>>> > >> > idle_age=0, priority=65100,udp,nw_src=
>>> > >> > 10.1.4.0/31,nw_dst=10.1.6.2/31,tp_src=20,tp_dst=1000actions=output:2
>>> > >> >  cookie=0x3e8, duration=83.559s, table=0, n_packets=74,
>>> n_bytes=43660,
>>> > >> > idle_age=0, icmp,nw_src=10.1.6.0/30,nw_dst=10.1.4.0/30actions=output:1
>>> > >> >  cookie=0x0, duration=111.981s, table=0, n_packets=67,
>>> n_bytes=4020,
>>> > >> > idle_age=0, priority=65000,dl_dst=01:23:20:00:00:01,dl_type=0x88cc
>>> > >> > actions=CONTROLLER:65535
>>> > >> >  cookie=0x3eb, duration=78.506s, table=0, n_packets=4,
>>> n_bytes=240,
>>> > >> > idle_age=3, arp,dl_src=00:25:90:64:f9:3e,dl_dst=90:e2:ba:00:9f:86
>>> > >> > actions=output:2
>>> > >> >  cookie=0x3ea, duration=78.546s, table=0, n_packets=5,
>>> n_bytes=300,
>>> > >> > idle_age=3, arp,dl_src=90:e2:ba:00:9f:86,dl_dst=00:25:90:64:f9:3e
>>> > >> > actions=output:1
>>> > >> >  cookie=0x3e9, duration=83.554s, table=0,* n_packets=25049,
>>> > >> n_bytes=26702234
>>> > >> > *, idle_age=2, udp,nw_src=
>>> > >> > 10.1.4.0/30,nw_dst=10.1.6.0/30,tp_src=20,tp_dst=1000actions=output:2
>>> > >> >
>>> > >> > So indeed, it seems to return to the values when the flow was
>>> idle.
>>> > >> >
>>> > >> > Does this help?
>>> > >> >
>>> > >> > Kind regards,
>>> > >> >
>>> > >> > Tim
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> > 2013/5/1 Ben Pfaff <blp at nicira.com>
>>> > >> >
>>> > >> > > On Tue, Apr 30, 2013 at 12:49:26PM +0200, Tmusic wrote:
>>> > >> > > > Let me post some more debug information then:
>>> > >> > >
>>> > >> > > [...]
>>> > >> > >
>>> > >> > > > Does this provides more useful information?
>>> > >> > >
>>> > >> > > It gets me past the "I don't really believe this, it must be
>>> some
>>> > >> > > misunderstanding" hurdle ;-)
>>> > >> > >
>>> > >> > > Are you willing to do a few experiments?  Here is one idea:
>>> > >> > >
>>> > >> > > 1. Start your stream and add the initial flow to the flow table
>>> (in
>>> > >> > >    whatever order you like).  Let it run for a while, a few
>>> seconds at
>>> > >> > >    least.
>>> > >> > >
>>> > >> > > 2. Dump stats with "ovs-ofctl dump-flows".
>>> > >> > >
>>> > >> > > 3. Stop your stream and "sleep 5" (or just wait 5 or more
>>> seconds
>>> > >> > >    patiently).
>>> > >> > >
>>> > >> > > 4. Dump stats with "ovs-ofctl dump-flows".
>>> > >> > >
>>> > >> > > 5. Restart your stream.  Let it run for a while, a few seconds
>>> at
>>> > >> least.
>>> > >> > >
>>> > >> > > 6. Add your higher-priority flow to the flow table.  Let the
>>> stream
>>> > >> run
>>> > >> > >    for a while, a few seconds at least.
>>> > >> > >
>>> > >> > > 7. Dump stats with "ovs-ofctl dump-flows".
>>> > >> > >
>>> > >> > > The question I'm trying to answer is whether the low-priority
>>> flow's
>>> > >> > > stats drop to zero in step 7, or to the values seen in step 2,
>>> or
>>> > >> > > something else entirely.
>>> > >> > >
>>> > >> > > Thanks,
>>> > >> > >
>>> > >> > > Ben.
>>> > >> > >
>>> > >>
>>> > >
>>> > >
>>>
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130729/e065ae8c/attachment.html>