Did you pull the latest code, or that commit (May 9th)?
I couldn't build packages from that May 9th snapshot. I was getting a
failed test:
561: ofproto - flow monitoring pause and resume FAILED (ofproto.at:1721
)
ofproto-dpif
which might be related, and a configure error.
--
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
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 overlapp
Not yet...
I'm quite busy now, but I'll try as soon as possible
Regards,
Tim
2013/5/12 Ben Pfaff
> 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 wit
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=eafed69b66fa5b7b69035fe5aa2ae
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
> I don't
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
> That helps narrow down the possible problems.
>
> Do you hav
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 misunders
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 j
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? He
Let me post some more debug information then:
so the traffic is a udp stream from 10.1.4.1 port 20 to 10.1.6.2 port 1000
(3000 packet/s with 1024 bytes packet size)
Original situation (last line is the relevant flow):
NXST_FLOW reply (xid=0x4):
cookie=0x3ea, duration=10.568s, table=0, n_packets=
On Mon, Apr 29, 2013 at 08:08:12PM +0200, Tmusic wrote:
> I'm experiencing some unexpected behavior from the flow counters when using
> wildcarded flow entries (with OpenFlow).
>
>
> Steps to reproduce:
> - Start a udp flow ex. 10.1.4.1=>10.1.6.1
> - Install wildcarded entry 10.1.4.0/30 => 10.1.6
Hi,
I'm experiencing some unexpected behavior from the flow counters when using
wildcarded flow entries (with OpenFlow).
Steps to reproduce:
- Start a udp flow ex. 10.1.4.1=>10.1.6.1
- Install wildcarded entry 10.1.4.0/30 => 10.1.6.0/30
==>After some time counters (ovs-ofctl dump-flows) indicate
13 matches
Mail list logo
