Latest on this.

The bug description changed a bit over the weekend.
the issue was seen  with big flows (lot of matches) just adding (no deleting) 
different big flows every 8 secs. I tried it around 13 times today back-to-back 
with 8 secs gap in between , but was not able to hit the issue.
I tried by changing the ipv6-destination-address for each of the flows.


From: Shuva Jyoti Kar
Sent: Saturday, October 15, 2016 12:08 PM
To: 'Abhijit Kumbhare'; Luis Gomez
Cc: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
Subject: RE: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis

About 6917, I have updated the bug with my observations.

Tried it about 23 times(add/get/del) in successions of 5 secs(used a stopwatch) 
but could see the alien flow id in oper DS only once, and that too the moment I 
tried a re-get it vanished.

I did use a different flow object, but I donot think that should cause any 

In any case I will retry with the one mentioned in the original problem 
description and then revert back


 [] On Behalf Of 
Abhijit Kumbhare
Sent: Friday, October 14, 2016 10:24 PM
To: Luis Gomez
Cc: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
Subject: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis

About the first one -

Tomas has said in yesterday's meeting that this was dependent on And that it was fixed. Can 
we retest? Also a question for Tomas: 6710 is cluster related - while 6575 is 
not clear if it is cluster or single node. Are we sure 6575 is fixed?

The second one: - Shuva will 
respond about that some time.

On Thu, Oct 13, 2016 at 9:50 PM, Luis Gomez 
<<>> wrote:
Hi all,

We are getting close to Boron SR1 so I think it makes sense to review the 2 
blocking issues we have:



l2switch does not work well when mininet is disconnected and connected with no 
time in-between.


This is kind of old issue, since the He->Li migration the l2switch has 
experienced random issues in the system test:

Same test passes fine in Beryllium as you can see below:

The last discovery (just before Boron release) was that giving more time 
between stop mininet and start mininet made the suite pass.


Although this was a clear regression in l2switch test (Be->B), this bug was not 
initially marked as blocker because it was not trivial to reproduce (e.g. 
switch connection flap).

Risk of not fixing:

l2switch and other similar applications relying on ofplugin may not work well 
when switch connection flaps.



Flow matching function (operational flow reconciliation) is not stable.


I discovered this issue doing some random flow push test in my laptop using 
POSTMAN: adding and deleting the same flow few times produced an alien ID in 
the operational flow.
After that I have created a test that does exactly that: add flow, verify 
operational ID, delete flow, sleep 5s, repeat. With these simple steps the 
issue shows consistently for Boron (new test):

But not in Beryllium:


Besides the test regression, I think there are applications in ODL relying on 
operational flow ID that would be negatively impacted by this bug.

Risk of not fixing:

OF applications relying on operational flow ID (e.g. to confirm flows) can 
sporadically fail.

L2switch-dev mailing list<>

openflowplugin-dev mailing list

Reply via email to