[OPNFLWPLUG-722] Some Flows not found in DeviceFlowRegistry Created: 04/Jul/16 Updated: 27/Sep/21 Resolved: 01/Jun/17 |
|
| Status: | Resolved |
| Project: | OpenFlowPlugin |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Josh Hershberg | Assignee: | Josh Hershberg |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 6146 |
| Description |
|
This was noticed with netvirt's TunnelFloodOut_ flows. 1) Create the flow. It gets written to the DeviceFlowRegistry The following are some stuff I logged and then run through a pretty printer to format the yang nesting for easier reading. What you can see is that the FlowRegistryKey changes because the hash of the Match object changes. The augmentations in the two log lines seem functionally equivalent but very structurally different. I will continue to dig on this and keep you updated but wanted to throw this out in case you have any relevant input already. 1) When the flow is written to config and inserted into the DeviceFlowRegistry the following log statement is issued: LOG.trace("Storing flowDescriptor with table ID : {} and flow ID : {} for flow hash : {} {} {}", Which produces the following output (Pretty printed): 2) When the OFPST_FLOW message comes in the following is logged from the DeviceFlowRegistry: LOG.trace("Created alien flow id {} for flow hash {} {} {}", |
| Comments |
| Comment by Andrej Leitner [ 19/Jul/16 ] |
| Comment by Andrej Leitner [ 04/Aug/16 ] |
|
Hi guys, is this still an issue? |
| Comment by Sam Hague [ 05/Aug/16 ] |
|
(In reply to Andrej Leitner from comment #2) Andrej, we put a workaround in so we need to back that out and check if this patch fixes the issue. |
| Comment by Andrej Leitner [ 05/Aug/16 ] |
|
Ok, will wait for updates from you. |
| Comment by Andrej Leitner [ 15/Aug/16 ] |
|
Hi Sam, |
| Comment by Sam Hague [ 20/Aug/16 ] |
|
Andrej, looks like some of the flows are being found but this one is not: cookie=0x0, duration=33.467s, table=110, n_packets=0, n_bytes=0, priority=8192,tun_id=0x65 actions=drop |
| Comment by Shuva Jyoti Kar [ 20/Aug/16 ] |
|
(In reply to Sam Hague from comment #6) So Sam how do we write this flow, using restconf or install any application that writes this flow? |
| Comment by Sam Hague [ 22/Aug/16 ] |
|
Our netvirt application writes this flow to mdsal in response to OpenStack port updates. In the course of a simple test of creating a single network with two instances, this flows gets written five or 6 times. That seems to be the trigger - writing the same flow to config a few times and eventually end up with an alien flow id. |
| Comment by Shuva Jyoti Kar [ 22/Aug/16 ] |
|
(In reply to Sam Hague from comment #8) So in details, what exactly does the application do – Repeated add of the same flow will result in the alien flow id because adding multiple flows with the same flow-id for the same table is not correct. There has been a patch pushed for updates failing due to BUG6458 last Friday, so it would be great if you could test and let us know if you still see the problem |
| Comment by Shuva Jyoti Kar [ 24/Aug/16 ] |
|
Sam/Josh, Did you get a chance to go through? any updates on it ? |
| Comment by Andrej Leitner [ 25/Aug/16 ] |
|
Since we believe the issue is fixed changing the priority to normal for now. |
| Comment by Jozef Bacigal [ 01/Jun/17 ] |
|
No response long time, assume the issue is already fixed. |