[OPNFLWPLUG-711] He plugin: Flow reconciliation failed due to OFPBAC_BAD_OUT_GROUP. Created: 16/Jun/16 Updated: 27/Sep/21 Resolved: 24/Jul/16 |
|
| Status: | Resolved |
| Project: | OpenFlowPlugin |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Shigeru Yasuda | Assignee: | Unassigned |
| 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: | 6073 |
| Description |
|
I observed that some flow entries in config DS were not installed to switch by flow reconciliation occasionally. 1. Start controller and install He plugin, and start OF13 switch. Step 4 triggers flow/group reconciliation. FlowNodeReconciliationImpl invokes add-group RPC to install all the groups in config DS, and then invokes add-flow RPC to install all the flows in config DS. But those RPC invocations may be reordered because He plugin executes RPCs in parallel using multiple threads. If a FLOW_MOD message is sent to OF13 switch before a GROUP_MOD message that installs group referenced by that flow, OF13 switch will reject that flow and return OFPBAC_BAD_OUT_GROUP error. That is why FRM needs to wait for completion of group reconciliation before flow reconciliation. |
| Comments |
| Comment by Shigeru Yasuda [ 16/Jun/16 ] |
| Comment by Luis Gomez [ 21/Jun/16 ] |
|
Right, the multiple threads is well known issue in He-plugin and has been fixed in Li-plugin. Hopefully your fix here helps with reconciliation. |
| Comment by Luis Gomez [ 21/Jun/16 ] |
|
Adding also Shuva as this is reconciliation related issue. |
| Comment by Andrej Leitner [ 14/Jul/16 ] |
|
Just FYI, FRS uses new SalFlatBatchService in OFP where the input is whole bulk of changes (separated into batches of F/G/M objects by related add/update/remove action). This service prepare action plan of batches+actions and mark barriers where needed (between dependent actions, e.g. case mentioned by Shigeru). In FRS batches are assembled in order:
and sent to SalFlatBatchService. The service will prepare plan and then go - run all independent actions simultaneously until it comes to action that has to wait for barrier, then wait for it (as the confirmation that all necessary things were successfully pushed to device) and continue (in the same way). In addition, there is also retry mechanism implemented. When you get error from a device, retry is started and reconciliation is done (sync config/operational). You can find the stuff here: |
| Comment by Shigeru Yasuda [ 21/Jul/16 ] |
|
https://git.opendaylight.org/gerrit/42213 (stable/beryllium) |