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-293 OpenFlowPlugin <p>odl: distribution-karaf-0.2.0-Helium-RC1-6-v201409220013</p> <p>env: mininet 2.1.0, ovs 2.0.0</p> <p>flow: integration.git /test/csit/variables/xmls/f32.xml</p> <p>steps to reproduce:</p> <p>1) add flow:<br/> PUT request sent to url <a href="http://pce-guest37.cisco.com:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155" class="external-link" target="_blank" rel="nofollow noopener">http://pce-guest37.cisco.com:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155</a><br/> with f32.xml as a content</p> <p>2) check operational ds<br/> GEThttp://pce-guest37.cisco.com:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155</p> <p>GEThttp://pce-guest37.cisco.com:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2</p> <p>returned 200 OK with flow details</p> <p>OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> cookie=0xa, duration=8.969s, table=2, n_packets=0, n_bytes=0, idle_timeout=300, hard_timeout=600, send_flow_rem priority=32,ip,nw_dst=10.0.0.0/24 actions=set_mpls_ttl(1)</p> <p>3) delete <br/> DEL request sent to url <a href="http://pce-guest37.cisco.com:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155" class="external-link" target="_blank" rel="nofollow noopener">http://pce-guest37.cisco.com:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155</a><br/> DEL Response 200</p> <p>4) check: <br/> present on device<br/> OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> cookie=0xa, duration=39.373s, table=2, n_packets=0, n_bytes=0, idle_timeout=300, hard_timeout=600, send_flow_rem priority=32,ip,nw_dst=10.0.0.0/24 actions=set_mpls_ttl(1)</p> <p>not present in "flow"<br/> GET request sent to url <a href="http://pce-guest37.cisco.com:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155" class="external-link" target="_blank" rel="nofollow noopener">http://pce-guest37.cisco.com:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/155</a><br/> GET response 404</p> <p>but present in "table"<br/> GET request sent to url <a href="http://pce-guest37.cisco.com:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2" class="external-link" target="_blank" rel="nofollow noopener">http://pce-guest37.cisco.com:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2</a><br/> GET response 200<br/> Response content: &lt;table xmlns="urn:opendaylight:flow:inventory"&gt;&lt;id&gt;2&lt;/id&gt;&lt;flow-table-statistics xmlns="urn:opendaylight:flow:table:statistics"&gt;&lt;packets-looked-up&gt;0&lt;/packets-looked-up&gt;&lt;active-flows&gt;1&lt;/active-flows&gt;&lt;packets-matched&gt;0&lt;/packets-matched&gt;&lt;/flow-table-statistics&gt;&lt;flow-cookie-map&gt;&lt;cookie&gt;10&lt;/cookie&gt;&lt;flow-ids&gt;#UF$TABLE*2-1&lt;/flow-ids&gt;&lt;flow-ids&gt;155&lt;/flow-ids&gt;&lt;/flow-cookie-map&gt;&lt;flow&gt;&lt;id&gt;#UF$TABLE*2-1&lt;/id&gt;&lt;flags&gt;SEND_FLOW_REM&lt;/flags&gt;&lt;match&gt;&lt;ipv4-destination&gt;10.0.0.0/24&lt;/ipv4-destination&gt;&lt;ethernet-match&gt;&lt;ethernet-type&gt;&lt;type&gt;2048&lt;/type&gt;&lt;/ethernet-type&gt;&lt;/ethernet-match&gt;&lt;/match&gt;&lt;priority&gt;32&lt;/priority&gt;&lt;idle-timeout&gt;300&lt;/idle-timeout&gt;&lt;instructions&gt;&lt;instruction&gt;&lt;order&gt;0&lt;/order&gt;&lt;apply-actions&gt;&lt;action&gt;&lt;order&gt;0&lt;/order&gt;&lt;set-mpls-ttl-action&gt;&lt;mpls-ttl&gt;1&lt;/mpls-ttl&gt;&lt;/set-mpls-ttl-action&gt;&lt;/action&gt;&lt;/apply-actions&gt;&lt;/instruction&gt;&lt;/instructions&gt;&lt;flow-statistics xmlns="urn:opendaylight:flow:statistics"&gt;&lt;duration&gt;&lt;nanosecond&gt;234000000&lt;/nanosecond&gt;&lt;second&gt;49&lt;/second&gt;&lt;/duration&gt;&lt;byte-count&gt;0&lt;/byte-count&gt;&lt;packet-count&gt;0&lt;/packet-count&gt;&lt;/flow-statistics&gt;&lt;table_id&gt;2&lt;/table_id&gt;&lt;hard-timeout&gt;600&lt;/hard-timeout&gt;&lt;cookie&gt;10&lt;/cookie&gt;&lt;/flow&gt;&lt;/table&gt;</p> <p>expected: to be deleted from everywhere</p> <p>Operating System: Linux<br/> Platform: PC</p> OPNFLWPLUG-293

of-flow: flow not deleted from device not operational table (but deleted from operational flow)

Bug Resolved Cannot Reproduce Anil Vishnoi Peter Gubka Mon, 22 Sep 2014 16:36:17 +0000 Mon, 27 Sep 2021 09:01:21 +0000 Wed, 27 May 2015 13:10:04 +0000 General 0 3 <p>Attachment karaf.log has been added with description: log file</p> <p>Hi Peter,</p> <p>In the reported scenario, statistics manager is working as expected. Statistics manage to their respective flow/group/meter etc. In this scenario, when user installs the flow, it augment the flow statistics to flow/155 in operational data store. Then when you remove the flow (flow/155) from config data store, statistics manager also remove the respective flow statistics from operational data store. <br/> BUT because this flow was not removed from the switch, in the next cycle of statistics data, it receives the statistics of the that flow. Now statistics manager try to search the respective flow in config data store to augment its statistics data, but it won't find it because it was already removed from the config data store. So it augment this flow as a alien flow using the alien ID (#UF$TABLE*2-1).</p> <p>So the main issue here is why flow was not removed from the switch when user deleted the flow from config data store. Because if it would have been removed from switch, statistics manager should not have received any flow statistics update from switch and therefore you should not have seen any statistics augmented against the alien id.</p> <p>Can you please update the bug with the details of the features you installed in karaf for testing this scenario?.If someone won't be able to look at it by tomorrow morning my time, i will have a look at it.</p> <p>Thanks<br/> Anil</p> <p>I use:<br/> feature:install odl-mdsal-broker odl-restconf odl-bgpcep-all odl-netconf-all odl-netconf-connector-all odl-openflowplugin-all odl-openflowplugin-drop-test odl-sfcofl2 odl-sfc-test-consumer</p> <p>Hi Peter,</p> <p>I tried to recreate this issue in my local setup. My local setup is running mininet (2.0.0) and ovs (2.1.2). I used the same karaf RC build which you mentioned for the testing. In my setup when i tried to install the flow (f32.xml), i get following error message from switch </p> <p>Type: Error in action description - OFPET_BAD_ACTION (2)<br/> Code: Action can’t apply for this match or Set-Field missing prerequisite - OFPBAC_MATCH_INCONSISTENT (0x000a)</p> <p>As per specs this is valid error message.</p> <p>Although this flow didn't get installed in switch, but it was augmented in the config data store, so i sent DELETE REST call to delete it, and i can see that flow_mod (for delete) also reaches to the switch. But this flow mod for delete also results in error from switch side. I get following error message from switch (which is obvious because we are trying to delete the flow which doesn't exist in the switch):</p> <p>Type: Problem modifying flow entry - OFPET_FLOW_MOD_FAILED (5)<br/> Code: Unspecified error - OFPFMFC_UNKNOWN (0x0000)</p> <p>From controller perspective, i can see that its sending flow mod for both installing and removing the flow as expected. That make me believe that its an issue from switch side. It seems to be a bug in OVS 2.0.0 version.</p> <p>In my environment i don't have OVS version==2.0.0, can you please favor me and capture the wireshark dump (.pcap file) in your environment and attach to the bug report. You just have to start the wireshark, send the flow add request, confirm that flow got installed on switch and then immediately delete the from using restconf. Through this pcap file, i want to confirm two things, </p> <p>1) That switch is receiving both the flow mod (for installing and removing the flow) <br/> 2) If switch throws any error for the flow_mod for flow delete. </p> <p>1st observation will confirm that controller is indeed sending appropriate flow mods to add/remove flow. Secondly, if we see error for flow delete flow mod, it can give us further pointer on why it's not deleting the flow. There can be two possible reasons, 1)controller is not sending appropriate flow_mod for flow deletion (very unlikely because its not putting any extra intelligence for flow deletion compared to flow add) OR 2) there is some issue from switch side.</p> <p>Please let me know if you need any help in capturing the wireshark dump.</p> <p>Thanks<br/> Anil</p> <p>please filter ports 6633 and 8181 for the traffic you are interested in</p> <p>Attachment f32.pcap has been added with description: pcap file</p> <p>So this pcap file shows that there was no error while installing the flow, but it throws error for the flow mod that deletes the flow. Error thrown is same as i get in my environment. Flow mode sent by controller also looks fine to me. So i believe OVS== 2.0.0 is buggy for mpls related flows. Initial implementation of mpls related actions (set and decrement) was introduced in 1.11.0 version of OVS, so its highly likely that its not fully bug free. As per specs OVS should not allow this flow to be installed and that's what we see in ovs==2.1.2 version.</p> <p>This is not a blocking bug for Helium (Peter agrees).</p> <p>Peter,</p> <p>Can you retest and update this old bug? Also check the priority of the bug - should it be critical or major?</p> <p>Abhijit</p> <p>i updated the importance to "normal" as it is very odl, i'll recheck it on monday, had different task today</p> <p>tested with lithium odl and ovs 2.3.0<br/> you were right, the flow is not correct. ovs rejected the flow</p> <p>closing bug as invalid</p> Development External issue ID 2028 External issue URL ODL SR Target Milestone Rank 0|i0309b: