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-518 OpenFlowPlugin <p>Description - </p> <p>1- After creating the test setup, Connected 2 swithes to the controller. <br/> 2- Pushed 100 flows each to both the switches and the switches show the flows correctly.<br/> 3- Sever the tcp connection between the switch and the controller- ( remove LAN ).<br/> 4- Perform config_cleanup and clear all the config. The config DS is empty. Operation DS was also empty.<br/> 5- Establish the tcp connection between the switch and the controller. <br/> 6- Check the config DS and operation DS. config DS is empty but operational still has the old flows.<br/> 7- Even the switch still has the flows.</p> <p>Controller Test setup - Single-node testing</p> <p>Switch connected - 2 - OVS<br/> ODL controller - stable/lithium</p> <p>Operating System: Linux<br/> Platform: Other</p> OPNFLWPLUG-518

Flow Reconciliator does not account for flow-deletions when the switch connection is disrupted

Bug Resolved Done Muthukumaran Kothandaraman Pompina Singh Wed, 29 Jul 2015 11:53:38 +0000 Mon, 27 Sep 2021 09:01:36 +0000 Mon, 25 Jan 2016 05:40:57 +0000 General 0 3 <p>Right - this is currently the default behavior. If there are already some flows/meters/groups on device when connection established then controller will just reflect those in DS/operational (flows will get an alien id - e.g. "#UF$TABLE*0-1") without touching them. This is especially useful in case of frequent controller restarts or device reconnections.</p> <p>There was plan for implementing feature of clean-up upon connection established but that should be active based on parameter. Unfortunately this was never implemented.</p> <p>Thanks Michal for the response.But what if when the tcp connection between the controller and the switch gets severed, the existing flows on the controller are modified or deleted as per business logic of the application.</p> <p>Now when the switch connects back , we have additional/conflicting flows that might lead to traffic being black-holed or dropped.This might not be the desired scenario.</p> <p>Is there a plan for cleanup upon establishment feature, anytime in the future ?</p> <p>I see.<br/> Regarding roadplan - please have a look at these:</p> <p><a href="https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Backlog" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Backlog</a><br/> <a href="https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Potential_Beryllium_Items" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Potential_Beryllium_Items</a></p> <p>I guess there is currently no plan for that. This shall be discussed on ofPlugin weekly meeting.</p> <p>added to Beryllium potential items wiki</p> <p>Muthu has picked this up.</p> <p>Gerrit - <a href="https://git.opendaylight.org/gerrit/#/c/27382/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/27382/</a> - to be reviewed</p> <p>Changed to waiting for review</p> <p>Hi, in comment #2 there is also modification mentioned. I guess this is not covered in the proposal.</p> <p>What is the difference in result when comparing this strategy and simple device cleanup upon connected?</p> <p>Hi Michal,</p> <p>This is mainly to accommodate the case where we do not want to disturb the data-path of already installed flows. If we do a full clean-up, it can result in traffic-drop</p> <p>Ok,<br/> can this feature be turned on/off for session?<br/> Is there any specific reason why is this incorporated in FRM?</p> <p>Hi Michal, </p> <p>&gt;&gt; can this feature be turned on/off for session?<br/> Currently not. I see your point in having this switch. I will work on introducing the same .</p> <p>&gt;&gt; Is there any specific reason why is this incorporated in FRM?<br/> There are two key aspects </p> <ul class="alternate" type="square"> <li>detecting if a flow/meter/table provisioning attempt is being made when switch is in disconnected-state is realized with minimal changes in FRM</li> <li>Checking if there are any flows/meters/groups in stale-state and sending corresponding delete messages is logically part of reconciliation function. Since FRM currently performs major part of provisioning function, it would be a more appropriate module to have these changes.</li> </ul> <p>Hope we are in sync</p> <ul class="alternate" type="square"> <li>Muthu</li> </ul> <p>Adding gerrit link for ready-reference</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/27382/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/27382/</a></p> <p>Uploaded patch-set addressing Michal's comment of making the "stale-marking" function configurable via Config Subsystem</p> <p>Michal - can you review?</p> <p>Michal has reviewed this - it is good to merge (either Abhijit or Anil can merge).</p> <p>Marked as fixed as the code change is merged.</p> Development External issue ID 4062 External issue URL Priority Rank 0|i031nb: