Cool, glad to hear that,
On Mon, Oct 27, 2014 at 8:56 AM, Andrey Korolyov wrote:
> On Wed, Oct 15, 2014 at 8:20 PM, Alex Wang wrote:
> > Hey Andrey,
> >
> > On Wed, Oct 15, 2014 at 7:51 AM, Andrey Korolyov wrote:
> >>
> >> Hi Alex,
> >>
> >> during transition from 2.1.3 to the 2.3.1 (both user
On Wed, Oct 15, 2014 at 8:20 PM, Alex Wang wrote:
> Hey Andrey,
>
> On Wed, Oct 15, 2014 at 7:51 AM, Andrey Korolyov wrote:
>>
>> Hi Alex,
>>
>> during transition from 2.1.3 to the 2.3.1 (both userspace and kernel
>> module) the 'first ping lost' appeared with completely static reactive
>> flows,
Hey Andrey,
On Wed, Oct 15, 2014 at 7:51 AM, Andrey Korolyov wrote:
> Hi Alex,
>
> during transition from 2.1.3 to the 2.3.1 (both userspace and kernel
> module) the 'first ping lost' appeared with completely static reactive
> flows, so I am still investigating it,
Could you provide more info
Hi Alex,
during transition from 2.1.3 to the 2.3.1 (both userspace and kernel
module) the 'first ping lost' appeared with completely static reactive
flows, so I am still investigating it, because this behavior can
affect flow lifecycle with mixed proactive+reactive scheme. If anyone
is interested
Thanks Alex,
On Sat, Oct 4, 2014 at 5:39 AM, Alex Wang wrote:
> Hey Andrey,
>
> Thanks for reporting the issue, Please see my reply below,
>
>> Hello,
>>
>> getting the lookalike message on 2.1.3 where the problem described in
>> the conversation should not take a place:
>
>
> Yes, v2.1.3 contai
Hey Andrey,
Thanks for reporting the issue, Please see my reply below,
Hello,
>
> getting the lookalike message on 2.1.3 where the problem described in
> the conversation should not take a place:
>
Yes, v2.1.3 contains the fix commit 3601bd879 (datapath: Use exact lookup
for flow_get and flow_d
On Thu, Jul 3, 2014 at 7:42 PM, Alex Wang wrote:
> I'm not exactly sure about the dp flow you have... but yes, del-flows
> will purge all flows.
>
> Also, if you stop to traffic that hitting the 'more inclusive' flow, then,
> both flows ('inclusive' and 'phantom') should be deleted.
>
> Thanks,
>
I'm not exactly sure about the dp flow you have... but yes, del-flows
will purge all flows.
Also, if you stop to traffic that hitting the 'more inclusive' flow, then,
both flows ('inclusive' and 'phantom') should be deleted.
Thanks,
Alex Wang,
On Thu, Jul 3, 2014 at 12:53 AM, Han Zhou wrote:
That's helpful. But after deleting the more inclusive flow I still
cannot delete the "zombie" flow. It might be there are still more
overlapping flows.
So, I tried ovs-dpctl del-flows, and all the "zombie" flows are gone :)
On Wed, Jul 2, 2014 at 10:28 PM, Alex Wang wrote:
> The tcp field is miss
The tcp field is missing, could you try 'ovs-dpctl dump-flow -m' to get
all fields. And use it as input to 'ovsdpctl flow-del'
Thanks,
Alex Wang,
On Wed, Jul 2, 2014 at 1:22 AM, Han Zhou wrote:
> Hi Alex,
>
> On Wed, Jul 2, 2014 at 2:30 PM, Alex Wang wrote:
> >
> >
> >
> > On Tue, Jul 1, 201
Hi Alex,
On Wed, Jul 2, 2014 at 2:30 PM, Alex Wang wrote:
>
>
>
> On Tue, Jul 1, 2014 at 7:38 PM, Han Zhou wrote:
>>
>> Hi Alex,
>>
>> That's cool!
>> Just one more question.
>> >Due to the race condition in userspace, there is chance that two
>> >overlapping megaflows could be installed
On Tue, Jul 1, 2014 at 7:38 PM, Han Zhou wrote:
> Hi Alex,
>
> That's cool!
> Just one more question.
> >Due to the race condition in userspace, there is chance that two
> >overlapping megaflows could be installed in datapath. And this
> >causes userspace unable to delete the less in
Hi Alex,
That's cool!
Just one more question.
>Due to the race condition in userspace, there is chance that two
>overlapping megaflows could be installed in datapath. And this
>causes userspace unable to delete the less inclusive megaflow flow
>even after it timeout, since the flo
Hey Han,
We found the issue, fix has been sent here:
http://openvswitch.org/pipermail/dev/2014-June/042333.html
Thanks again for reporting,
Alex Wang,
On Wed, Jun 11, 2014 at 3:54 AM, Han Zhou wrote:
> Hello folks,
>
> We encountered a problem on a hypervisor with OVS2.0, that there are
> war
Hi Alex,
Sure, for the boxes using OVS2.1, there is no such issue.
Thanks for your help.
Best regards,
Han
On Tue, Jun 17, 2014 at 8:50 AM, Alex Wang wrote:
> Sorry for using the wrong term (LTS, not LTE) and misclaiming it (branch-2.1
> is not a LTS branch).
>
> We just recommend you to use br
Sorry for using the wrong term (LTS, not LTE) and misclaiming it
(branch-2.1
is not a LTS branch).
We just recommend you to use branch-2.1, that branch should work fine.
There is no new LTS branch for ovs.
Thanks,
Alex Wang,
On Mon, Jun 16, 2014 at 5:10 PM, Alex Wang wrote:
> Sorry for this
Sorry for this very delayed reply,
After talking within ovs-team, we think it is best to use branch-2.1
which is LTE branch of OVS. If you still observe the issue, we will
work on a fix.
Thanks,
Alex Wang,
___
discuss mailing list
discuss@openvswitch.o
Thanks Alex! Please see inlined:
On Thu, Jun 12, 2014 at 1:30 PM, Alex Wang wrote:
>
>
> For OVS-2.0, we still use facet and subfacet in ofproto-dpif to keeps record
> of the flows. And the flow revalidation logic is quite different from later
> branches. So, the fix in later branches does not
Hey Han,
Thanks for pointing this out,
Please see my reply inline,
On Wed, Jun 11, 2014 at 9:40 PM, Han Zhou wrote:
> Hi Alex,
>
> I see that you encountered this error log before in your tests. Is
> this a bug that's already fixed? Could you help explain and give
> advice how to clean up (th
Hi Alex,
I see that you encountered this error log before in your tests. Is
this a bug that's already fixed? Could you help explain and give
advice how to clean up (this is a production hypervisor and no plan to
upgrade at this moment)?
Note: this is OVS2.0. It seems OVS is retrying deleting 1 en
Hello folks,
We encountered a problem on a hypervisor with OVS2.0, that there are
warning logs flooding in ovs-vswitchd.log:
2014-06-10T13:25:11.761Z|15084062|dpif|WARN|Dropped 67 log messages in
last 1 seconds (most recently, 1 seconds ago) due to excessive rate
2014-06-10T13:25:11.761Z|15084063
21 matches
Mail list logo