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/OVSDB-412 ovsdb <p>I'm able to configure a logical switch on a HWVTEP, but ODL seems unable to correlate the configured and operational topology entries for the HWVTEP. So the logical switch is "created" rather than "updated", and the operational topology is unchanged.</p> <p>so then when I create the termination point for the port/VLAN mapping to the logical switch ODL sends "named-uuid","LogicalSwitch_ls0" instead of "uuid","c0d53932-dd4b-46b3-8d7f-b3bbceacdf05" as expected by the switch.</p> <p>I'm seeing this both with Boron-SR3 and with Carbon snapshot (with Carbon I also get an NPE).</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-412

OVSDB HWVTEP unable to find logical switch in operational datastore

Bug Resolved Cannot Reproduce Vishal Thapar Giles Heron Tue, 2 May 2017 13:49:59 +0000 Mon, 30 Oct 2017 19:50:56 +0000 Sat, 6 May 2017 18:49:21 +0000 unspecified Southbound.hw_vtep 0 3 <p>Attachment karaf.zip has been added with description: zipped logs</p> <p>example config/operational topologies (from another run trying - unsuccessfully - to make this work with Beryllium)</p> <p>config:</p> <p>{<br/> "topology": [<br/> {<br/> "topology-id": "hwvtep:1",<br/> "node": [<br/> {<br/> "node-id": "hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98",<br/> "hwvtep:logical-switches": [</p> { "hwvtep-node-name": "ls0", "hwvtep-node-description": "", "tunnel-key": "10000" } <p> ]<br/> },<br/> {<br/> "node-id": "hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98/physicalswitch/SB-DEV-NODE2",<br/> "termination-point": [<br/> {<br/> "tp-id": "eth1/12",<br/> "hwvtep:hwvtep-node-name": "eth1/12",<br/> "hwvtep:hwvtep-node-description": "",<br/> "hwvtep:vlan-bindings": [</p> { "vlan-id-key": 100, "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']" } <p> ]<br/> }<br/> ]<br/> }<br/> ]<br/> }<br/> ]<br/> }</p> <p>operational:</p> <p>{<br/> "topology": [<br/> {<br/> "topology-id": "hwvtep:1",<br/> "node": [<br/> {<br/> "node-id": "hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98",<br/> "hwvtep:connection-info": </p> { "local-ip": "10.195.94.43", "local-port": 6640, "remote-port": 52544, "remote-ip": "10.23.237.112" } <p>,<br/> "hwvtep:managers": [</p> { "target": "tcp:10.195.94.43:6640", "manager-uuid": "bc9a45d0-4dab-4a8a-ac6b-5791d4654c35", "is-connected": true } <p> ],<br/> "hwvtep:switches": [</p> { "switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98/physicalswitch/SB-DEV-NODE2']" } <p> ]<br/> },<br/> {<br/> "node-id": "hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98/physicalswitch/SB-DEV-NODE2",<br/> "hwvtep:hwvtep-node-description": "",<br/> "hwvtep:managed-by": "/network-topology:network-topology/network-topology:topology<span class="error">&#91;network-topology:topology-id=&#39;hwvtep:1&#39;&#93;</span>/network-topology:node<span class="error">&#91;network-topology:node-id=&#39;hwvtep://uuid/b4872522-2fc5-42c9-a9fd-441bb5dfef98&#39;&#93;</span>",<br/> "hwvtep:hwvtep-node-name": "SB-DEV-NODE2",<br/> "hwvtep:tunnel-ips": [</p> { "tunnel-ips-key": "50.50.50.1" } <p> ],<br/> "hwvtep:physical-switch-uuid": "030f5109-0f32-431f-aed5-778cc108b7e9",<br/> "hwvtep:management-ips": [</p> { "management-ips-key": "10.23.237.112" } <p> ],<br/> "termination-point": [<br/> </p> { "tp-id": "eth1/11", "hwvtep:hwvtep-node-name": "eth1/11", "hwvtep:hwvtep-node-description": "", "hwvtep:physical-port-uuid": "ae4fb25e-19cd-4597-a604-d5708f039d41" } <p>,<br/> </p> { "tp-id": "eth1/10", "hwvtep:hwvtep-node-name": "eth1/10", "hwvtep:hwvtep-node-description": "", "hwvtep:physical-port-uuid": "91ca60d3-a6a0-4431-b8b1-ef4fec999820" } <p>,</p> { "tp-id": "eth1/12", "hwvtep:hwvtep-node-name": "eth1/12", "hwvtep:hwvtep-node-description": "", "hwvtep:physical-port-uuid": "31d7390c-c3d2-4f20-8794-3813500e3564" } <p> ]<br/> }<br/> ]<br/> }<br/> ]<br/> }</p> <p>is there any update on this?</p> <p>or any more info you need from me?</p> <p>Can you enable TRACE for the following package aswell.<br/> org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md</p> <p>From the logs it could be seen that logical switch is created in the device.<br/> 2017-05-01 11:09:46,448 | TRACE | entLoopGroup-5-1 | HwvtepMonitorCallback | 191 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.3.3.Boron-SR3 | result: TableUpdates [map={Logical_Switch=TableUpdate [{c0d53932-dd4b-46b3-8d7f-b3bbceacdf05=RowUpdate [uuid=c0d53932-dd4b-46b3-8d7f-b3bbceacdf05, oldRow=null, newRow=Row [columns=</p> {name=[name=ls0], description=[description= ], tunnel_key=[tunnel_key=[10000]]} <p>]]}]}, error=null, details=null, getError()=null, getDetails()=null, getClass()=class org.opendaylight.ovsdb.lib.message.TableUpdates, hashCode()=877596989, toString()=org.opendaylight.ovsdb.lib.message.TableUpdates@344f113d] dbSchema: hardware_vtep</p> <p>But it is not updated in operational datastore.</p> <p>It could be because the previous transaction threw an exception other than <br/> NullPointerException | NoSuchElementException | ClassCastException e<br/> as caught by <a href="https://github.com/opendaylight/ovsdb/blob/stable/boron/hwvtepsouthbound/hwvtepsouthbound-impl/src/main/java/org/opendaylight/ovsdb/hwvtepsouthbound/transactions/md/HwvtepOperationalCommandAggregator.java" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/opendaylight/ovsdb/blob/stable/boron/hwvtepsouthbound/hwvtepsouthbound-impl/src/main/java/org/opendaylight/ovsdb/hwvtepsouthbound/transactions/md/HwvtepOperationalCommandAggregator.java</a></p> <p>That exception would have killed the operational datastore update thread in TransactionInvokerImpl and preventing any further updates to operational datastore.</p> <p>This patch <a href="https://git.opendaylight.org/gerrit/#/c/51517/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/51517/</a> should address such issues.</p> <p>that trace ought to have been there already as I was tracing org.opendaylight.ovsdb?</p> <p>I've tried building carbon/stable with the patch you noted. Still fails <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> This time I get an NPE just after getting the response to my command to create the logical switch:</p> <p>2017-05-04 10:13:51,107 | DEBUG | on-dispatcher-74 | LogicalSwitchUpdateCommand | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Creating logical switch named: HwvtepNodeName <span class="error">&#91;_value=ls0&#93;</span><br/> 2017-05-04 10:13:51,108 | TRACE | on-dispatcher-74 | LogicalSwitchUpdateCommand | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | execute: creating LogicalSwitch entry: Logical_Switch : Row [columns=</p> {name=[name=ls0], description=[description=], tunnel_key=[tunnel_key=[10000]]} <p>]<br/> 2017-05-04 10:13:51,109 | DEBUG | on-dispatcher-74 | HwvtepDeviceInfo | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Marking device data as intransit KeyedInstanceIdentifier</p> {targetType=interface org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.hwvtep.rev150901.hwvtep.global.attributes.LogicalSwitches, path=[org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.NetworkTopology, org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.Topology[key=TopologyKey [_topologyId=Uri [_value=hwvtep:1]]], org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node[key=NodeKey [_nodeId=Uri [_value=hwvtep://uuid/0b197212-3ce8-4ea2-a2f7-3fc455a02485]]], org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.hwvtep.rev150901.HwvtepGlobalAugmentation, org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.hwvtep.rev150901.hwvtep.global.attributes.LogicalSwitches[key=LogicalSwitchesKey [_hwvtepNodeName=HwvtepNodeName [_value=ls0]]]]} <p>2017-05-04 10:13:51,119 | TRACE | on-dispatcher-74 | JsonRpcEndpoint | 212 - org.opendaylight.ovsdb.library - 1.4.0.SNAPSHOT | getClient Request : {"id":"33d58219-fbef-4bee-b819-7ace9e8b151e","method":"transact","params":["hardware_vtep",{"op":"insert","row":</p> {"name":"ls0","description":"","tunnel_key":["set",[10000]]} <p>,"uuid-name":"LogicalSwitch_ls0","table":"Logical_Switch"},</p> {"op":"comment","comment":"Logical Switch: Creating ls0"} <p>]}<br/> 2017-05-04 10:13:51,119 | DEBUG | on-dispatcher-74 | TransactInvokerImpl | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | invoke: command: org.opendaylight.ovsdb.hwvtepsouthbound.transact.TransactCommandAggregator@7f792b56, tb: org.opendaylight.ovsdb.lib.operations.TransactionBuilder@6b795c9f<br/> 2017-05-04 10:13:51,198 | TRACE | entLoopGroup-5-3 | JsonRpcDecoder | 212 - org.opendaylight.ovsdb.library - 1.4.0.SNAPSHOT | readable bytes 200, records read 6, incomplete record bytes 0<br/> 2017-05-04 10:13:51,200 | TRACE | entLoopGroup-5-3 | JsonRpcEndpoint | 212 - org.opendaylight.ovsdb.library - 1.4.0.SNAPSHOT | Request : null "update" <span class="error">&#91;&quot;75384b61-4ea3-4b0c-a75b-38758ceb8c93&quot;,{&quot;Logical_Switch&quot;:{&quot;03611caf-c9af-4600-965f-4e7efaf3640d&quot;:{&quot;new&quot;:{&quot;description&quot;:&quot; &quot;,&quot;name&quot;:&quot;ls0&quot;,&quot;tunnel_key&quot;:10000}}}}&#93;</span><br/> 2017-05-04 10:13:51,251 | TRACE | entLoopGroup-5-3 | HwvtepMonitorCallback | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | result: TableUpdates [map={Logical_Switch=TableUpdate [{03611caf-c9af-4600-965f-4e7efaf3640d=RowUpdate [uuid=03611caf-c9af-4600-965f-4e7efaf3640d, oldRow=null, newRow=Row [columns=</p> {name=[name=ls0], description=[description= ], tunnel_key=[tunnel_key=[10000]]} <p>]]}]}, error=null, details=null, getError()=null, getDetails()=null, getClass()=class org.opendaylight.ovsdb.lib.message.TableUpdates, hashCode()=1025312520, toString()=org.opendaylight.ovsdb.lib.message.TableUpdates@3d1d0708] dbSchema: hardware_vtep<br/> 2017-05-04 10:13:51,251 | TRACE | entLoopGroup-5-3 | HwvtepMonitorCallback | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | update exit<br/> 2017-05-04 10:13:51,251 | TRACE | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Executing command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.GlobalUpdateCommand@63dd3577<br/> 2017-05-04 10:13:51,251 | TRACE | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Executing command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepPhysicalSwitchUpdateCommand@27e1e3d3<br/> 2017-05-04 10:13:51,251 | TRACE | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Executing command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepPhysicalSwitchRemoveCommand@30e8b701<br/> 2017-05-04 10:13:51,251 | TRACE | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Executing command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepManagerUpdateCommand@37182927<br/> 2017-05-04 10:13:51,251 | TRACE | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Executing command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepManagerRemoveCommand@3de4d43e<br/> 2017-05-04 10:13:51,251 | TRACE | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Executing command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepLogicalSwitchUpdateCommand@15b3472a<br/> 2017-05-04 10:13:51,251 | TRACE | entLoopGroup-5-3 | JsonRpcDecoder | 212 - org.opendaylight.ovsdb.library - 1.4.0.SNAPSHOT | readable bytes 132, records read 7, incomplete record bytes 0<br/> 2017-05-04 10:13:51,252 | TRACE | entLoopGroup-5-3 | JsonRpcEndpoint | 212 - org.opendaylight.ovsdb.library - 1.4.0.SNAPSHOT | Response : {"error":null,"id":"33d58219-fbef-4bee-b819-7ace9e8b151e","result":[</p> {"uuid":["uuid","03611caf-c9af-4600-965f-4e7efaf3640d"]} <p>,{}]}<br/> 2017-05-04 10:13:51,252 | ERROR | n-invoker-impl-0 | vtepOperationalCommandAggregator | 220 - org.opendaylight.ovsdb.hwvtepsouthbound-impl - 1.4.0.SNAPSHOT | Execution of command org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepLogicalSwitchUpdateCommand@15b3472a failed with the following exception. Continuing the execution of remaining commands<br/> java.lang.NullPointerException<br/> at org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepLogicalSwitchUpdateCommand.buildConnectionNode(HwvtepLogicalSwitchUpdateCommand.java:76)<span class="error">&#91;220:org.opendaylight.ovsdb.hwvtepsouthbound-impl:1.4.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepLogicalSwitchUpdateCommand.updateLogicalSwitch(HwvtepLogicalSwitchUpdateCommand.java:58)<span class="error">&#91;220:org.opendaylight.ovsdb.hwvtepsouthbound-impl:1.4.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepLogicalSwitchUpdateCommand.execute(HwvtepLogicalSwitchUpdateCommand.java:50)<span class="error">&#91;220:org.opendaylight.ovsdb.hwvtepsouthbound-impl:1.4.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.HwvtepOperationalCommandAggregator.execute(HwvtepOperationalCommandAggregator.java:57)<span class="error">&#91;220:org.opendaylight.ovsdb.hwvtepsouthbound-impl:1.4.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.ovsdb.hwvtepsouthbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:107)<span class="error">&#91;220:org.opendaylight.ovsdb.hwvtepsouthbound-impl:1.4.0.SNAPSHOT&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)<span class="error">&#91;:1.8.0_91&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)<span class="error">&#91;:1.8.0_91&#93;</span><br/> at java.lang.Thread.run(Thread.java:745)<span class="error">&#91;:1.8.0_91&#93;</span></p> <p>I've also just tested using the latest carbon/stable (but without the patch).</p> <p>I get the same NPE (only at line 98 rather than line 107 of TransactionInvokerImpl.java).</p> <p>it's the same line of code (just before/after the patch was applied).</p> <p>any thoughts?</p> <p>The npe is coming from this line<br/> lsBuilder.setLogicalSwitchUuid(new Uuid(lSwitch.getUuid().toString()));</p> <p>which means either lswitch is null or its uuid is null.</p> <p>controller is not able to parse the logical switch update properly and create the lswitch object.</p> <p>What is the version of openvswitch you are using ?</p> <p>I think 1.3 with a plan to use 1.4 - but can check with the developer later on (she's in SJ so won't be in for a while). Both the UUID and logical switch should be there.</p> <p>will see if can make progress on my own for now...</p> <p>so we've made progress - we fixed a bug in our code where we were sending a notification with a missing UUID. So yeah - maybe in future it might be worth programming a little more defensively in ODL and checking whether a value is null before calling "toString()" on it <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/> </p> <p>so now we've got the logical switch in our operational topology <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>as a result we've been able to update the ethernet port mapping also and now we see the local-mcast-macs entry for 00:00:00:00:00:00 and also the termination point for the VXLAN tunnel.</p> <p>our next step is to try and add the remote-mcast-macs entry and the remote termination point for the far end of the tunnel. At that point we should be able to pass traffic (I hope!)</p> <p>all seems to work now - even without the patch.</p> <p>will close the bug</p> Development External issue ID 8353 External issue URL Rank 0|i022kn: