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/GENIUS-28 genius <p>In an openstack-odl setup with one openstack/odl controller and two computes, compute-A is properly connected to the controller but B is not. The tunnel between the computes is also missing.<br/> As a result instances deployed on A can get an IP but instances on B cannot, even though they are in the same network.<br/> Sometimes on redeployment A and B are connected both with each other and the controller and everything works, but some other times either one of them or both are not.</p> <p>Operating System: All<br/> Platform: All</p> GENIUS-28

VxLAN Tunnel endpoints sometimes missing

Bug Resolved Done Hema Gopalakrishnan Romanos Skiadas Mon, 17 Oct 2016 12:02:03 +0000 Mon, 30 Oct 2017 19:52:46 +0000 Mon, 5 Dec 2016 16:04:34 +0000 (unspecified) General 0 9 <p>This happens using Boron 0.5.1-20161017.001225-477</p> <p>Attachment compute1.txt has been added with description: Compute 1 (working) flows, ovs show</p> <p>Attachment compute2.txt has been added with description: Compute 2 (not working) ovs show, flows</p> <p>Attachment controller.txt has been added with description: Controller ovs show, flows, groups</p> <p>Attachment karaf.log has been added with description: Karaf log</p> <p>This is either a problem on the opnfv side or a misunderstanding of mine about some things. Either way, I'd like to mark is as INVALID but can't</p> <p>Disregard the previous comment, I'll add more logs from a deployment with SR1, one OpenStack controller and two computes</p> <p>Attachment karaf_logaa has been added with description: Karaf log with genius set to trace, 2nd set of logs, 1/3</p> <p>Attachment karaf_logab has been added with description: Karaf log 2/3</p> <p>Attachment karaf_logac has been added with description: Karaf log 3/3</p> <p>Attachment ovs_logs has been added with description: ovs-vsctl show for controller and computes</p> <p>Attachment itm-transport-zones_after.xml has been added with description: restconf/config/itm:transport-zones before modifying environment</p> <p>Attachment itm-transport-zones_before.xml has been added with description: restconf/config/itm:transport-zones after modifying environment</p> <p><a href="https://gerrit.opnfv.org/gerrit/#/c/23971/3/test/functest/testcase_6.py" class="external-link" target="_blank" rel="nofollow noopener">https://gerrit.opnfv.org/gerrit/#/c/23971/3/test/functest/testcase_6.py</a><br/> This is what was being run when the DHCP failures occurred. Instances 'sdnvpn-6-5' and 'sdnvpn-6-3' failed to get an IP.</p> <p>This happens with odl-netvirt-openstack, I am not using the old vpnservice features.</p> <p>It seems this bug stems from the usage of the same TEP in multiple Genius' ITM transport zones.<br/> According to Genius this is a missing functionality and will be corrected to support all use cases.</p> <p>Hema G will update accordingly.</p> <p>Attachment autotunnels.zip has been added with description: Tunnels not created</p> <p>Issue is with dpnendpoints. <a href="http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints" class="external-link" target="_blank" rel="nofollow noopener">http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints</a></p> <p>It assumes DPN is member of single TZ so unable to create mesh if a DPN ends up memeber of multiple TZs. transport-zone field in dpn-endpoints should be a list and should form mesh with all tunnels in all those transportzones.</p> <p>(In reply to Vishal Thapar from comment #18)<br/> &gt; Issue is with dpnendpoints.<br/> &gt; <a href="http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints" class="external-link" target="_blank" rel="nofollow noopener">http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints</a><br/> &gt; <br/> &gt; It assumes DPN is member of single TZ so unable to create mesh if a DPN ends<br/> &gt; up memeber of multiple TZs. transport-zone field in dpn-endpoints should be<br/> &gt; a list and should form mesh with all tunnels in all those transportzones.</p> <p>What are our thoughts on fixing this by SR2?<br/> Would it be possible to fix in Genius by that timeline?</p> <p>The alternative seems to be avoiding multiple TEP in TZ usage.<br/> netvirt can be modified to always use the same TZ when add TEPs, which would kill the minimized mesh optimization but should keep automatic tunnels possible without hitting the Genius bug.</p> <p>Please keep us posted, it is preferable to fix in Genius and maintain current netvirt behavior if possible.</p> <p>(In reply to Alon Kochba from comment #19)<br/> &gt; (In reply to Vishal Thapar from comment #18)<br/> &gt; &gt; Issue is with dpnendpoints.<br/> &gt; &gt; <a href="http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints" class="external-link" target="_blank" rel="nofollow noopener">http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints</a><br/> &gt; &gt; <br/> &gt; &gt; It assumes DPN is member of single TZ so unable to create mesh if a DPN ends<br/> &gt; &gt; up memeber of multiple TZs. transport-zone field in dpn-endpoints should be<br/> &gt; &gt; a list and should form mesh with all tunnels in all those transportzones.<br/> &gt; <br/> &gt; What are our thoughts on fixing this by SR2?<br/> &gt; Would it be possible to fix in Genius by that timeline?<br/> &gt; <br/> &gt; The alternative seems to be avoiding multiple TEP in TZ usage.<br/> &gt; netvirt can be modified to always use the same TZ when add TEPs, which would<br/> &gt; kill the minimized mesh optimization but should keep automatic tunnels<br/> &gt; possible without hitting the Genius bug.<br/> &gt; <br/> &gt; Please keep us posted, it is preferable to fix in Genius and maintain<br/> &gt; current netvirt behavior if possible.</p> <p>Yep, plan is to fix by SR2 timeframe. Hema is working on a fix though it is bit tricky. However, I ended up coming up with a patch when trying to test my OFTunnel changes.</p> <p><a href="https://git.opendaylight.org/gerrit/48716" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/48716</a></p> <p>It is not done <span class="error">&#91;haven&#39;t touched deletion code at all&#93;</span> but add code works and seems to be enough to fix the issue. If you can test this patch and confirm/deny it fixes the create part, then we can at least try and get this in for SR2.</p> <p>(In reply to Vishal Thapar from comment #20)<br/> &gt; (In reply to Alon Kochba from comment #19)<br/> &gt; &gt; (In reply to Vishal Thapar from comment #18)<br/> &gt; &gt; &gt; Issue is with dpnendpoints.<br/> &gt; &gt; &gt; <a href="http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints" class="external-link" target="_blank" rel="nofollow noopener">http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints</a><br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; It assumes DPN is member of single TZ so unable to create mesh if a DPN ends<br/> &gt; &gt; &gt; up memeber of multiple TZs. transport-zone field in dpn-endpoints should be<br/> &gt; &gt; &gt; a list and should form mesh with all tunnels in all those transportzones.<br/> &gt; &gt; <br/> &gt; &gt; What are our thoughts on fixing this by SR2?<br/> &gt; &gt; Would it be possible to fix in Genius by that timeline?<br/> &gt; &gt; <br/> &gt; &gt; The alternative seems to be avoiding multiple TEP in TZ usage.<br/> &gt; &gt; netvirt can be modified to always use the same TZ when add TEPs, which would<br/> &gt; &gt; kill the minimized mesh optimization but should keep automatic tunnels<br/> &gt; &gt; possible without hitting the Genius bug.<br/> &gt; &gt; <br/> &gt; &gt; Please keep us posted, it is preferable to fix in Genius and maintain<br/> &gt; &gt; current netvirt behavior if possible.<br/> &gt; <br/> &gt; Yep, plan is to fix by SR2 timeframe. Hema is working on a fix though it is<br/> &gt; bit tricky. However, I ended up coming up with a patch when trying to test<br/> &gt; my OFTunnel changes.<br/> &gt; <br/> &gt; <a href="https://git.opendaylight.org/gerrit/48716" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/48716</a><br/> &gt; <br/> &gt; It is not done <span class="error">&#91;haven&#39;t touched deletion code at all&#93;</span> but add code works and<br/> &gt; seems to be enough to fix the issue. If you can test this patch and<br/> &gt; confirm/deny it fixes the create part, then we can at least try and get this<br/> &gt; in for SR2.</p> <p>Thanks a lot for this Vishal.<br/> Confirmed that this fixes the issue, added a comment to the gerrit.</p> <p>First patch fixing add use cases:</p> <p>Master: <a href="https://git.opendaylight.org/gerrit/48716" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/48716</a><br/> stable/boron: <a href="https://git.opendaylight.org/gerrit/#/c/48817/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/48817/</a></p> <p>Closing, as this bug was resolved.</p> <p>Deletion of TEPs will be implemented in <a href="https://git.opendaylight.org/gerrit/#/c/48952" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/48952</a> and usage of it by netvirt should be done in <a href="https://bugs.opendaylight.org/show_bug.cgi?id=6560" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=6560</a></p> Duplicate GENIUS-30 Development External issue ID 6952 External issue URL Rank 0|i01oen: