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-856 OpenFlowPlugin <p>When resetting the node that has both OpenDaylight controller and OpenStack controller - when the controller is back up an running instance is not getting an IP.</p> <p>Version<br/> ========<br/> OpenDaylight Boron<br/> OpenStack Newton</p> <p>How to reproduce<br/> ================<br/> 1. Launch an instance.<br/> 2. Verify that it gets an IP<br/> 3. Power reset the controller node.<br/> 4. Access the instance using a console and run 'dhclient -r &amp;&amp; dhclient' or reboot the instance.<br/> 5. Verify the instance doesn't get an IP.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-856

An instance can't get an IP when Restarting the controller node

Bug Verified Done Bertrand Low Itzik Brown Mon, 20 Feb 2017 12:32:12 +0000 Mon, 27 Sep 2021 09:02:00 +0000 Tue, 12 Dec 2017 00:25:03 +0000 Nitrogen Oxygen General 0 9 <p>Hi Itzik,</p> <p>I have a couple of questions:</p> <p>1) Do you use packstack or devstack to deploy openstack&amp; ODL?<br/> 2) How do you restart Openstack after server reboot?</p> <p>Thanks, Vinh</p> <p>Devstack is used as development setup and it never recovers completely after node reboot. The issue is invalid if devstack is used. </p> <p>Will try with packstack</p> <p>However, I think it is an Openstack deployment platform issue, not ODL</p> <p>hi,</p> <p> I used the Ocata Official instalaltion guide to install every package required for Openstack and configured them to use ODL. Then restarted the Control node. When the System was up again, I see that the qdhcp NS getting created but the previously created instances in compute node were not reachable. Continuiung to debug further.</p> <p>Can you please mention the steps tried out from your end</p> <p>(In reply to Venkatrangan Govindarajan from comment #3)<br/> &gt; hi,<br/> &gt; <br/> &gt; I used the Ocata Official instalaltion guide to install every package<br/> &gt; required for Openstack and configured them to use ODL. Then restarted the<br/> &gt; Control node. When the System was up again, I see that the qdhcp NS getting<br/> &gt; created but the previously created instances in compute node were not<br/> &gt; reachable. Continuiung to debug further.<br/> &gt; <br/> &gt; <br/> &gt; Can you please mention the steps tried out from your end</p> <p>The steps are in 'How to reproduce' in the bug itself.<br/> I checked it also with Pike.</p> <p>I have reproduced the issue and have observed 2 observation.</p> <p>Setup: </p> <ul class="alternate" type="square"> <li>Control node with ODL</li> <li>Compute node</li> </ul> <p>Topo: </p> <ul class="alternate" type="square"> <li>Create a network</li> <li>Create a VM<br/> DO A REBOOT of control with ODL setup</li> </ul> <p>Observation#1</p> <ul class="alternate" type="square"> <li>DHCP tap intf port number has been changed after the ODL reboot. (port:1 -&gt; port:3)</li> <li>VM tap intf port number has been changed after the ODL reboot. (port:1 -&gt; port:3)</li> <li>In control node, ct_table flows and actions are changed in dump-flows. But while checking DS, the flows are not changed.</li> </ul> <p>In Control node: After ODL reboot</p> <ul class="alternate" type="square"> <li>Table 213 and 243, missing ct_state flows.</li> <li>Table 220, instead of output:3, the action is changed to DROP</li> <li>In most of the tables, the action are changed from resubmit,17 to DROP<br/> In Compute node: After ODL reboot</li> <li>Flows are installed freshly. But, no flows are missing. Neither no actions are changed.</li> <li>1 packet drop has been observed in table 211</li> </ul> <p>In Control node: After VM soft reboot</p> <ul class="alternate" type="square"> <li>Table 0 flow for earlier DHCP port was still present. (port:1)<br/> In Compute node: After VM soft reboot</li> <li>Packet count varies due to newly installed flows.</li> <li>Drop packet count raised in table 211</li> </ul> <p>Observation#2<br/> In dump flows, the actions are updated correctly. But in the control node, output port for network was not updated after reboot.<br/> before reboot : Network port is 1<br/> After reboot : Network port is 3<br/> But in dump flow, output action port is 1<br/> Thus, manually deleted the output action port 1 and added new flow with port 3. Thereafter did a soft reboot to the VM. IP got assigned to the VM.</p> <p>Itzik,<br/> Can you please share your dump-flows, data store info and karaf logs<br/> Thanks in advance!</p> <p>Attachment observation_1.zip has been added with description: Observation_1</p> <p>Attachment observation_2.zip has been added with description: Observation_2</p> <p>Tested below scenarios<br/> Setup:<br/> 1 node ODL<br/> 1 Control Node <br/> 1 Compute Node </p> <p>Topo: </p> <ul class="alternate" type="square"> <li>Create a network</li> <li>Create a VM</li> </ul> <p>Scenario#1 : Reboot only ODL node<br/> -&gt; The issue is NOT reproduced. <br/> -&gt; VM got IP after ODL was rebooted and the respective VM was reachable.</p> <p>Scenario#2 : Reboot Control node<br/> -&gt; Once the control node is rebooted, console was unreachable.<br/> (openstack) console log show VM1<br/> Unexpected API Error. Please report this at <a href="http://bugs.launchpad.net/nova/" class="external-link" target="_blank" rel="nofollow noopener">http://bugs.launchpad.net/nova/</a> and attach the Nova API log if possible.<br/> &lt;class 'oslo_messaging.exceptions.MessagingTimeout'&gt; (HTTP 500) (Request-ID: req-8a6568e0-6676-40ac-a494-23e35739c089)<br/> -&gt; VM reachability was failed too.</p> <p>Itzik,</p> <p>Workaround for this bug: Restart OpenVswitch <br/> <span class="error">&#91;sudo systemctl restart openvswitch&#93;</span><br/> The correct flows are updated in control node as expected.</p> <p>Distro Version: Carbon </p> <p>Observation:<br/> Once we do a reboot, <br/> -&gt; In control node, the resubmit actions are changed to drop. And addition to that, some flow's match conditions are missing (Example: reg6)<br/> REF: Please check control node flows (before and after reboot)</p> <p>Say, we are analysing single flow Table:55, <br/> -&gt; The config datastore for Inventory nodes and network topology are updated.<br/> -&gt; Flows were added from Openflowpluin resubmit action is written in the instruction.<br/> -&gt; In tcpdump, table 55 flows are written twice. and the instruction has action as drop rather than, resubmit.<br/> -&gt; In openvswitch log, the table 55 flows are written twice. And the action is drop too. (REF: openvswitch line#13848, 13849, 13906 and 13907)</p> <p>Attachment ovs.zip has been added with description: OVS_log</p> <p>Attachment DataStrore_tcpdump.zip has been added with description: DataStrore and tcpdump</p> <p>Addition to that, issue occurs in Carbon too.</p> <p>There seems to be some errors in OFPT_GROUP_MOD that needs to be analyzed.</p> <p>Resubmit flow was pushed to the device and once I performed reboot, the same issue occurred in openflowplugin.</p> <p>Setup: </p> <ul class="alternate" type="square"> <li>Control node with ODL</li> </ul> <p>Features to be installed:</p> <ul class="alternate" type="square"> <li>odl-openflowplugin-flow-services</li> <li>odl-openflowplugin-nxm-extensions</li> <li>odl-mdsal-apidocs</li> </ul> <p>Steps:</p> <ul class="alternate" type="square"> <li>Push a resubmit flow using RESTAPI</li> <li>Reboot the control node with ODL.</li> </ul> <p>Observation:</p> <ul class="alternate" type="square"> <li>The flow with action resubmit had been changed to action drop after reboot.</li> <li>In config datastore, the action is not been changed to drop. But in device the action has been changed to drop.</li> </ul> <p>Please ref bug: <a href="https://bugs.opendaylight.org/show_bug.cgi?id=9137" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=9137</a></p> <p>Moved to Bertrand.</p> <p>Hi Itzik and Arthi, this bug appears to be resolved in stable/nitrogen and master branches (see the <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-942" class="external-link" rel="nofollow">https://jira.opendaylight.org/browse/OPNFLWPLUG-942</a> comments). Are you able to test this bug out using the latest nitrogen or master branch build?</p> <p>Any update?</p> <p>No update on this bug for more then 2 months. Closing the bug. Please re-open the bug if it's not resolved and you are planning to work on it.</p> Development External issue ID 7821 External issue URL Rank 0|i033qf: