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-409 OpenFlowPlugin <p>We tried creating flow mods that match on NxmNxTunIpv4Src. The flows show up in config, but not in operational. No log messages in karaf or on the vSwitch. Doing a disconnect and reconnect of the vSwitch didn't restore the flows.</p> <p>Here is what we see in config:</p> <p><a href="http://pastebin.com/QP7VHCT7" class="external-link" target="_blank" rel="nofollow noopener">http://pastebin.com/QP7VHCT7</a></p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-409

Flow distinguishing with NxmNxTunIpv4Src match fails

Bug Resolved Done Michal Rehak Thomas Bachman Tue, 21 Apr 2015 21:59:29 +0000 Mon, 27 Sep 2021 09:01:29 +0000 Fri, 18 Dec 2015 06:51:52 +0000 General 0 4 <p>I tried to PUT your input to URI <br/> <a href="http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/</a></p> <p>but it wasn' successfull<br/> following error was obtained<br/> {"errors":{"error":[</p> {"error-type":"protocol","error-tag":"malformed-message","error-message":"Error parsing input: Content is not allowed in prolog."} <p>]}}</p> <p>But can't see any error.</p> <p>Finally I was able to simulate this problem.<br/> After PUT-ting input which you specified (BTW correct URI is <a href="http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/1" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/1</a>)</p> <p>I got response 500 from server.</p> <p>After debuging I found out that JsonNormalizedNodeBodyReader class returns augmentation normalized node + instance identifier to augmentation. </p> <p>In RestconfImpl method updateConfigurationData() do validation validateTopLevelNodeName() where getNodeType() method of inner class AugmentationIdentifier (belongs to class YangInstanceIdentifier) throw exception UnsupportedOperationException.</p> <p>Therefore I am moving this bug to restconf.</p> <p>Was it possible to put this input as you specified before?</p> <p>I created these flow mods using java code, and not via RESTCONF. The pastebin that I had before was the result of the GET of config, not a PUT.</p> <p>Note that I think this bug has already been fixed by this gerrit:</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/18787/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/18787/</a></p> <p>If you look at the following package:</p> <p>org.opendaylight.openflowplugin.extension.vendor.nicira.converter.match</p> <p>there is a TunIPv4SrcConverter.java.</p> <p>Note that there isn't a corresponding match converter for the tunnel destination &#8211; I'll open a new bug for that.</p> <p>Hi Thomas,<br/> you have right and we have two different bug in one bugzilla ticket. But I haven't found any relevant bug in restconf yet, so here is a quick fix for Jozef's description.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/21847/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/21847/</a></p> <p>After applying Vaso's and Jan's patch I can see some data also in operational.</p> <p>Input data and config DS<br/> "id": "openflow:1:5|tunnel|2|3|4|5",<br/> "id": "openflow:1:5|sfcTunnel|2|3|4|5|Ipv4Address <span class="error">&#91;_value=192.168.194.147&#93;</span>",<br/> "id": "openflow:1:3|00:00:00:00:36:02|2|3|4|5|1",<br/> "id": "openflow:1:1|00:00:00:00:35:02|6|3|7|5|1",<br/> "id": "openflow:1:4|00:00:00:00:36:03|2|3|4|5|1",<br/> "id": "drop|null",<br/> "id": "openflow:1:5|sfcTunnel|6|3|7|5|Ipv4Address <span class="error">&#91;_value=192.168.194.147&#93;</span>",<br/> "id": "openflow:1:2|00:00:00:00:35:03|6|3|7|5|1",<br/> "id": "openflow:1:5|tunnel|6|3|7|5</p> <p>operational DS<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> openflow:1:1|00:00:00:00:35:02|6|3|7|5|1<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> #UF$TABLE*1-6<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> #UF$TABLE*1-7<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> openflow:1:4|00:00:00:00:36:03|2|3|4|5|1<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> #UF$TABLE*1-5<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> openflow:1:2|00:00:00:00:35:03|6|3|7|5|1<br/> FLOW.ID<span class="error">&#91;openflow:1/1&#93;</span> openflow:1:3|00:00:00:00:36:02|2|3|4|5|1</p> <p>It looks like:</p> <ul class="alternate" type="square"> <li>2 flows containing Ipv4Address<span class="error">&#91;...&#93;</span> weren't recorded to operational DS.</li> <li>3 other flows containing also text are probably stored as aliens.</li> </ul> <p>It requires more investigation why some of flows aren't stored to operational DS and some are stored as aliens.</p> <p>Problem with aliens is wiht openflowplugin in Li and in He version.</p> <p>I tried to store flow which contained<br/> "match": {<br/> "openflowplugin-extension-general:extension-list": [<br/> {<br/> "extension-key": "openflowplugin-extension-nicira-match:nxm-nx-tun-id-key",<br/> "extension": {<br/> "openflowplugin-extension-nicira-match:nxm-nx-tun-id": </p> { "value": 2 } <p> }<br/> }<br/> ],<br/> "in-port": "openflow:1:5"<br/> },SERIALIZER_KEY</p> <p>I found out that in NiciraExtensionProvider is converter for TUN_ID created with key (Nxm1Class.class, NxmNxTunId.class) but when this converter is searched in MatchExtensionHelper then values (OpenflowBasicClass, TunnelId) are used. It cause that conveter isn't found and therefore match is incorretly translated to SAL format which causes that match isn't found in flow registry which causes that new flow with alien ID is created in operational datastore.</p> <p>I wasn't able to find root cause of this problem. Michal Rehak adviced me that problem should be in converting from byte stream to openflowjava. I tried to debug in artifact openflowjava-extension-nicira class TunIdCodec method deserialize(), but this method isn't called.</p> <p>Hi,<br/> I tried with those 9 flows in json form. First I ended up with 7 flows in device and 7 in DS/operational with 3 aliens. Then I did following:</p> <ul class="alternate" type="square"> <li>changed 2 tunnel-ids to openflow standard tunnel-id matches and got still 7 flows but only 1 alien.</li> </ul> <ul class="alternate" type="square"> <li>added empty match to the drop|null flow -&gt; got 8 flows, 1 alien</li> </ul> <ul class="alternate" type="square"> <li>changed tunnel-ipv4-src so that they differ (otherwise 2 flows based on tunnel-ipv4-src match were equal) and got finally 9 flows with 2 aliens.</li> </ul> <p>This is the input:<br/> <a href="http://pastebin.com/62f6nx72" class="external-link" target="_blank" rel="nofollow noopener">http://pastebin.com/62f6nx72</a></p> <p>Now we have the alien issue - is it ok to deal with in in Beryllium?</p> <p>Lowering the priority to normal - so it does not come in the major &amp; above bug query. Assigning to Michal for his thoughts on this.</p> <p>Michal - can you do one of these two alternatives:</p> <p>1. open a new bug with the appropriate title and close this one<br/> 2. Change the title to reflect the actual bug</p> Development External issue ID 3039 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i030z3: