https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-711 OpenFlowPlugin <p>I observed that some flow entries in config DS were not installed to switch by flow reconciliation occasionally.</p> <p> 1. Start controller and install He plugin, and start OF13 switch.<br/> 2. Put some groups into config DS.<br/> 3. Put some flows that contain group-action that references to the group configured by step 2.<br/> 4. Restart OF13 switch.</p> <p>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.</p> <p>That is why FRM needs to wait for completion of group reconciliation before flow reconciliation.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-711

He plugin: Flow reconciliation failed due to OFPBAC_BAD_OUT_GROUP.

Bug Resolved Done Unassigned Shigeru Yasuda Thu, 16 Jun 2016 08:48:19 +0000 Mon, 27 Sep 2021 09:01:50 +0000 Sun, 24 Jul 2016 07:42:32 +0000 General 0 5 <p><a href="https://git.opendaylight.org/gerrit/40429" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/40429</a> (master)</p> <p>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.</p> <p>Adding also Shuva as this is reconciliation related issue.</p> <p>Just FYI, <br/> there is (not currently default) application forwardingrules-sync a.k.a new FRM in OFP project. It was written from scratch and fixes some FRM issues.</p> <p>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).</p> <p>In FRS batches are assembled in order:</p> <ul> <li>AddOrUpdateGroups</li> <li>AddOrUpdateMeters</li> <li>AddOrUpdateFlows</li> <li>RemoveFlows</li> <li>RemoveMeters</li> <li>RemoveGroups</li> </ul> <p>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).</p> <p>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).</p> <p>You can find the stuff here:<br/> org.opendaylight.openflowplugin.applications.frsync<br/> org.opendaylight.openflowplugin.impl.services.SalFlatBatchService<br/> I am preparing also wiki page for the comparison:<br/> <a href="https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Applications_FRM_vs_FRS" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Applications_FRM_vs_FRS</a></p> <p><a href="https://git.opendaylight.org/gerrit/42213" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/42213</a> (stable/beryllium)</p> Development External issue ID 6073 External issue URL Rank 0|i032u7: