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-896 OpenFlowPlugin <p>Steps:</p> <p>1. Create 2 Security Groups( sg1 and sg2) and apply Remote CIDR rule to the groups. </p> <p>openstack security group rule create --ingress --protocol 1 --dst-port 1:65535 --remote-ip 30.0.0.4/24 sg1<br/> openstack security group rule create --egress --protocol 1 --dst-port 1:65535 --remote-ip 30.0.0.4/24 sg1</p> <p>openstack security group rule create --ingress --protocol 1 --dst-port 1:65535 --remote-ip 30.0.0.3/24 sg2<br/> openstack security group rule create --egress --protocol 1 --dst-port 1:65535 --remote-ip 30.0.0.3/24 sg2</p> <p>2. Create 2 VMs. <br/> VM1: 30.0.0.3 and apply sg1 <br/> VM1: 30.0.0.4 and apply sg2</p> <p>Expected:<br/> Ping should be possible from VM2 to VM1 on both sides</p> <p>Observed:<br/> Ping fails and flows are not updated in table 243</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-896

Flows are not updated when Remote CIDR rules are applied to the VM(openstack version:ocata)

Bug Resolved Done Arthi Bhattacharjee Arthi Bhattacharjee Mon, 29 May 2017 11:40:40 +0000 Mon, 27 Sep 2021 09:02:03 +0000 Tue, 4 Jul 2017 12:58:46 +0000 General 0 14 <p>Attachment remote-cidr.txt has been added with description: Dump-flows</p> <p>Attachment log.zip has been added with description: Karaf logs</p> <p>Remote CIDR rule are properly created when we mention the IP prefix as "/32"<br/> and the behavior also working as expected. </p> <p>sample:<br/> openstack security group rule create --egress --protocol icmp --dst-port 1:65535 --remote-ip 30.0.0.10/32 sg2<br/> openstack security group rule create --ingress --protocol icmp --dst-port 1:65535 --remote-ip 30.0.0.10/32 sg2</p> <p>flows updated in ingress/egress tables in pipeline.<br/> cookie=0x6900000, duration=2.137s, table=243, n_packets=0, n_bytes=0, priority=1001,ct_state=+new+trk,icmp,reg6=0x200/0xfffff00,nw_src=30.0.0.10 actions=ct(commit,zone=5002),resubmit(,220)</p> <p> cookie=0x6900000, duration=1.825s, table=213, n_packets=0, n_bytes=0, priority=1002,ct_state=+new+trk,icmp,metadata=0x20000000000/0xfffff0000000000,nw_dst=30.0.0.10 actions=ct(commit,zone=5002),resubmit(,17)</p> <p>if we create CIDR with IP prefix "/24" there is no flows updated in ingress/egress tables.</p> <p>compared the same behavior in pure openstack.<br/> created two SG(sg1,sg2) mentioned in the steps<br/> and applied to the VM's <br/> observation:<br/> ping to all VM's with in the network is working.<br/> i think pure openstack treating "30.0.0.4/24" as "30.0.0.0/24"<br/> so ping to all VM's create within the network is working.<br/> where as in ODL ping doesn't work.</p> <p>Attachment OFplugin_karaf.log has been added with description: OF_plugin logs</p> <p>Analysed the Bug when we create a rule with "30.0.0.4/24" netvirt added the flow to config datastore the same is not reflected in OVS.</p> <p>To confirm the behavior used openflowplugin alone to reproduce the Bug.<br/> through REST added the flow and verified.<br/> observation:<br/> if we add the flow with prefix "30.0.0.4/32" flow was added to config data store and the same was reflected in OVS.</p> <p>if we add the flow with prefix "30.0.0.4/24" flow was added to config data store and the same was not reflected in OVS.</p> <p>steps to reproduce the Bug:<br/> ODL : carbon version.</p> <p>1.start ODL and install features "feature:install odl-openflowplugin-flow-services-rest, odl-restconf,odl-mdsal-apidocs"<br/> 2.in OVS create bridge and set ODL as controller.<br/> a.sudo ovs-vsctl add-br br-int<br/> b.sudo ovs-vsctl set-controller br-int tcp:&lt;controller IP&gt;:6653<br/> 3.push the flow using REST.<br/> flow:1_1 (IP prefix "10.0.10.2/24"<br/> URL:<br/> http://&lt;controller IP&gt;:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1_1</p> <p>request body:<br/> &lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;<br/> &lt;flow xmlns="urn:opendaylight:flow:inventory"&gt;<br/> &lt;priority&gt;2&lt;/priority&gt;<br/> &lt;flow-name&gt;Foo&lt;/flow-name&gt;<br/> &lt;match&gt;<br/> &lt;ethernet-match&gt;<br/> &lt;ethernet-type&gt;<br/> &lt;type&gt;2048&lt;/type&gt;<br/> &lt;/ethernet-type&gt;<br/> &lt;/ethernet-match&gt;<br/> &lt;ipv4-destination&gt;10.0.10.2/24&lt;/ipv4-destination&gt;<br/> &lt;/match&gt;<br/> &lt;id&gt;1_1&lt;/id&gt;<br/> &lt;table_id&gt;0&lt;/table_id&gt;<br/> &lt;instructions&gt;<br/> &lt;instruction&gt;<br/> &lt;order&gt;0&lt;/order&gt;<br/> &lt;apply-actions&gt;<br/> &lt;action&gt;<br/> &lt;order&gt;0&lt;/order&gt;<br/> &lt;dec-nw-ttl/&gt;<br/> &lt;/action&gt;<br/> &lt;/apply-actions&gt;<br/> &lt;/instruction&gt;<br/> &lt;/instructions&gt;<br/> &lt;/flow&gt;</p> <p>flow:1_2 (IP prefix "10.0.10.2/32"<br/> URL:<br/> http://&lt;controller IP&gt;:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1_2</p> <p>request body:<br/> &lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;<br/> &lt;flow xmlns="urn:opendaylight:flow:inventory"&gt;<br/> &lt;priority&gt;2&lt;/priority&gt;<br/> &lt;flow-name&gt;Foo&lt;/flow-name&gt;<br/> &lt;match&gt;<br/> &lt;ethernet-match&gt;<br/> &lt;ethernet-type&gt;<br/> &lt;type&gt;2048&lt;/type&gt;<br/> &lt;/ethernet-type&gt;<br/> &lt;/ethernet-match&gt;<br/> &lt;ipv4-destination&gt;10.0.10.2/32&lt;/ipv4-destination&gt;<br/> &lt;/match&gt;<br/> &lt;id&gt;1_2&lt;/id&gt;<br/> &lt;table_id&gt;0&lt;/table_id&gt;<br/> &lt;instructions&gt;<br/> &lt;instruction&gt;<br/> &lt;order&gt;0&lt;/order&gt;<br/> &lt;apply-actions&gt;<br/> &lt;action&gt;<br/> &lt;order&gt;0&lt;/order&gt;<br/> &lt;dec-nw-ttl/&gt;<br/> &lt;/action&gt;<br/> &lt;/apply-actions&gt;<br/> &lt;/instruction&gt;<br/> &lt;/instructions&gt;<br/> &lt;/flow&gt;</p> <p>Note: the sample taken from openflowplugin user guide.<br/> <a href="http://docs.opendaylight.org/en/stable-carbon/user-guide/openflow-plugin-project-user-guide.html#end-to-end-flows" class="external-link" target="_blank" rel="nofollow noopener">http://docs.opendaylight.org/en/stable-carbon/user-guide/openflow-plugin-project-user-guide.html#end-to-end-flows</a></p> <p>config data store:<br/> <a href="http://10.106.138.138:8181/restconf/config/opendaylight-inventory:nodes" class="external-link" target="_blank" rel="nofollow noopener">http://10.106.138.138:8181/restconf/config/opendaylight-inventory:nodes</a></p> <p>{<br/> "nodes": {<br/> "node": [<br/> {<br/> "id": "openflow:117063448964943",<br/> "flow-node-inventory:table": [<br/> {<br/> "id": 0,<br/> "flow": [<br/> {<br/> "id": "1_2",<br/> "instructions": {<br/> "instruction": [<br/> {<br/> "order": 0,<br/> "apply-actions": {<br/> "action": [<br/> {<br/> "order": 0,<br/> "dec-nw-ttl": {}<br/> }<br/> ]<br/> }<br/> }<br/> ]<br/> },<br/> "match": {<br/> "ethernet-match": {<br/> "ethernet-type": </p> { "type": 2048 } <p> },<br/> "ipv4-destination": "10.0.10.2/32"<br/> },<br/> "priority": 2,<br/> "table_id": 0,<br/> "flow-name": "Foo"<br/> },<br/> {<br/> "id": "1_1",<br/> "instructions": {<br/> "instruction": [<br/> {<br/> "order": 0,<br/> "apply-actions": {<br/> "action": [<br/> {<br/> "order": 0,<br/> "dec-nw-ttl": {}<br/> }<br/> ]<br/> }<br/> }<br/> ]<br/> },<br/> "match": {<br/> "ethernet-match": {<br/> "ethernet-type": </p> { "type": 2048 } <p> },<br/> "ipv4-destination": "10.0.10.2/24"<br/> },<br/> "priority": 3,<br/> "table_id": 0,<br/> "flow-name": "Foo"<br/> }</p> <p> ]<br/> }<br/> ]<br/> }<br/> ]<br/> }<br/> }</p> <p><span class="error">&#91;root@nic-centos ~&#93;</span># sudo ovs-ofctl dump-flows br-int<br/> NXST_FLOW reply (xid=0x4):<br/> cookie=0x0, duration=2271.583s, table=0, n_packets=0, n_bytes=0, idle_age=2271, priority=2,ip,nw_dst=10.0.10.2 actions=dec_ttl</p> <p>Two flows added in config data store only one flow is refelcted.<br/> when the flow "1_1" was added there is no output in OVS.<br/> then added flow "1_2" OVS shows the above flow.</p> <p>Problem is that on newer OVS you need to normalize IP adress based on mask, so OVS will reject 10.0.10.2/24, but will accept 10.0.10.0/24. So I think that OpenFlowPlugin behaves correctly in this case.</p> <p>(In reply to Tomas Slusny from comment #5)<br/> &gt; Problem is that on newer OVS you need to normalize IP adress based on mask,<br/> &gt; so OVS will reject 10.0.10.2/24, but will accept 10.0.10.0/24. So I think<br/> &gt; that OpenFlowPlugin behaves correctly in this case.</p> <p>Hi Tomas,<br/> i am using OVS 2.6.1</p> <p>added flows manually using below commands flow was created.<br/> I think OVS has the intelligence to convert the prefix into respective network address.<br/> when i try the same using OpenflowPlugin flow was not created.</p> <p>Flows created in OVS: </p> <p>sudo ovs-ofctl add-flow -O OpenFlow13 br-int "cookie=0x6900000, table=243, n_packets=0, n_bytes=0,<br/> priority=50,ip,metadata=0x1773000000/0xffff000000,nw_src=30.0.0.10/24 actions=resubmit(,220)"</p> <p>flow create in OVS:<br/> cookie=0x6900000, duration=3.494s, table=243, n_packets=0, n_bytes=0, priority=50,ip,metadata=0x1773000000/0xffff000000,nw_src=30.0.0.0/24 actions=resubmit(,220)</p> <p>Maybe it works only from CLI, because I am sure we was experiencing very similar issues like this when we tested plugin with newer OVS, and OVS returned error BADMATCH and BADMASK or something like that. Can you test the flow with that wrong IP address and mask again from OpenFlowPlugin and enable DEBUG logs on org.opendaylight.openflowplugin.impl? There should be message 'Flow add failed for flow=' with error why it happened.</p> <p>(In reply to Tomas Slusny from comment #7)<br/> &gt; Maybe it works only from CLI, because I am sure we was experiencing very<br/> &gt; similar issues like this when we tested plugin with newer OVS, and OVS<br/> &gt; returned error BADMATCH and BADMASK or something like that. Can you test the<br/> &gt; flow with that wrong IP address and mask again from OpenFlowPlugin and<br/> &gt; enable DEBUG logs on org.opendaylight.openflowplugin.impl? There should be<br/> &gt; message 'Flow add failed for flow=' with error why it happened.</p> <p>Tomas,<br/> I enabled DEBUG log and pushed the flow.<br/> as you said i can see the the below error in log.<br/> why the flow was added in config data store because device returned error.<br/> also the logging is not "ERROR" it is in "DEBUG".</p> <p>2017-06-23 15:53:57,431 | WARN | ssionScavenger-3 | teInvalidatingHashSessionManager | 247 - org.ops4j.pax.web.pax-web-jetty - 3.2.9 | Timing out for 1 session(s) with id dehtngq76x2c5ct8yted9tw2<br/> 2017-06-23 15:53:57,928 | DEBUG | entLoopGroup-5-2 | SalFlowServiceImpl | 220 - org.opendaylight.openflowplugin.impl - 0.4.0.Carbon | Flow add failed for flow=AddFlowInput [_flowName=Foo, _flowRef=FlowRef [_value=KeyedInstanceIdentifier</p> {targetType=interface org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.tables.table.Flow, path=[org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.Nodes, org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node[key=NodeKey [_id=Uri [_value=openflow:69225723496521]]], org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNode, org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.tables.Table[key=TableKey [_id=0]], org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.tables.table.Flow[key=FlowKey [_id=Uri [_value=1_2]]]]} <p>], _flowTable=FlowTableRef [_value=KeyedInstanceIdentifier</p> {targetType=interface org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.tables.Table, path=[org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.Nodes, org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node[key=NodeKey [_id=Uri [_value=openflow:69225723496521]]], org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNode, org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.tables.Table[key=TableKey [_id=0]]]} <p>], _instructions=Instructions{getInstruction=[Instruction{getInstruction=ApplyActionsCase{getApplyActions=ApplyActions{getAction=<span class="error">&#91;Action{getAction=DecNwTtlCase{getDecNwTtl=DecNwTtl{augmentations={}}, augmentations={}}, getOrder=0, augmentations={}}&#93;</span>, augmentations={}}, augmentations={}}, getOrder=0, augmentations={}}], augmentations={}}, _match=Match{getEthernetMatch=EthernetMatch{getEthernetType=EthernetType{getType=EtherType <span class="error">&#91;_value=2048&#93;</span>, augmentations={}}, augmentations={}}, getLayer3Match=Ipv4Match{getIpv4Destination=Ipv4Prefix <span class="error">&#91;_value=10.0.10.2/24&#93;</span>, augmentations={}}, augmentations={}}, _node=NodeRef [_value=KeyedInstanceIdentifier</p> {targetType=interface org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node, path=[org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.Nodes, org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node[key=NodeKey [_id=Uri [_value=openflow:69225723496521]]]]} <p>], _priority=2, _tableId=0, _transactionUri=Uri <span class="error">&#91;_value=DOM-1&#93;</span>, _strict=false, augmentation=[]], errors=Device reported error type BADMATCH code BADWILDCARDS</p> <p>So this then looks like it is working as intended, closing.</p> Development External issue ID 8561 External issue URL Rank 0|i033zb: