Operating System: All
Platform: All

Attachment remote-cidr.txt has been added with description: Dump-flows

Attachment log.zip has been added with description: Karaf logs

Remote CIDR rule are properly created when we mention the IP prefix as "/32"
and the behavior also working as expected.

sample:
openstack security group rule create --egress --protocol icmp --dst-port 1:65535 --remote-ip 30.0.0.10/32 sg2
openstack security group rule create --ingress --protocol icmp --dst-port 1:65535 --remote-ip 30.0.0.10/32 sg2

flows updated in ingress/egress tables in pipeline.
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)

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)

if we create CIDR with IP prefix "/24" there is no flows updated in ingress/egress tables.

compared the same behavior in pure openstack.
created two SG(sg1,sg2) mentioned in the steps
and applied to the VM's
observation:
ping to all VM's with in the network is working.
i think pure openstack treating "30.0.0.4/24" as "30.0.0.0/24"
so ping to all VM's create within the network is working.
where as in ODL ping doesn't work.

Attachment OFplugin_karaf.log has been added with description: OF_plugin logs

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.

To confirm the behavior used openflowplugin alone to reproduce the Bug.
through REST added the flow and verified.
observation:
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.

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.

steps to reproduce the Bug:
ODL : carbon version.

1.start ODL and install features "feature:install odl-openflowplugin-flow-services-rest, odl-restconf,odl-mdsal-apidocs"
2.in OVS create bridge and set ODL as controller.
a.sudo ovs-vsctl add-br br-int
b.sudo ovs-vsctl set-controller br-int tcp:<controller IP>:6653
3.push the flow using REST.
flow:1_1 (IP prefix "10.0.10.2/24"
URL:
http://<controller IP>:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1_1

request body:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<priority>2</priority>
<flow-name>Foo</flow-name>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.10.2/24</ipv4-destination>
</match>
<id>1_1</id>
<table_id>0</table_id>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<dec-nw-ttl/>
</action>
</apply-actions>
</instruction>
</instructions>
</flow>

flow:1_2 (IP prefix "10.0.10.2/32"
URL:
http://<controller IP>:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1_2

request body:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<priority>2</priority>
<flow-name>Foo</flow-name>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.10.2/32</ipv4-destination>
</match>
<id>1_2</id>
<table_id>0</table_id>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<dec-nw-ttl/>
</action>
</apply-actions>
</instruction>
</instructions>
</flow>

Note: the sample taken from openflowplugin user guide.
http://docs.opendaylight.org/en/stable-carbon/user-guide/openflow-plugin-project-user-guide.html#end-to-end-flows

config data store:
http://10.106.138.138:8181/restconf/config/opendaylight-inventory:nodes

{
"nodes": {
"node": [
{
"id": "openflow:117063448964943",
"flow-node-inventory:table": [
{
"id": 0,
"flow": [
{
"id": "1_2",
"instructions": {
"instruction": [
{
"order": 0,
"apply-actions": {
"action": [
{
"order": 0,
"dec-nw-ttl": {}
}
]
}
}
]
},
"match": {
"ethernet-match": {
"ethernet-type":

},
"ipv4-destination": "10.0.10.2/32"
},
"priority": 2,
"table_id": 0,
"flow-name": "Foo"
},
{
"id": "1_1",
"instructions": {
"instruction": [
{
"order": 0,
"apply-actions": {
"action": [
{
"order": 0,
"dec-nw-ttl": {}
}
]
}
}
]
},
"match": {
"ethernet-match": {
"ethernet-type":

},
"ipv4-destination": "10.0.10.2/24"
},
"priority": 3,
"table_id": 0,
"flow-name": "Foo"
}

]
}
]
}
]
}
}

[root@nic-centos ~]# sudo ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
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

Two flows added in config data store only one flow is refelcted.
when the flow "1_1" was added there is no output in OVS.
then added flow "1_2" OVS shows the above flow.

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.

(In reply to Tomas Slusny from comment #5)
> 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.

Hi Tomas,
i am using OVS 2.6.1

added flows manually using below commands flow was created.
I think OVS has the intelligence to convert the prefix into respective network address.
when i try the same using OpenflowPlugin flow was not created.

Flows created in OVS:

sudo ovs-ofctl add-flow -O OpenFlow13 br-int "cookie=0x6900000, table=243, n_packets=0, n_bytes=0,
priority=50,ip,metadata=0x1773000000/0xffff000000,nw_src=30.0.0.10/24 actions=resubmit(,220)"

flow create in OVS:
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)

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.

(In reply to Tomas Slusny from comment #7)
> 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.

Tomas,
I enabled DEBUG log and pushed the flow.
as you said i can see the the below error in log.
why the flow was added in config data store because device returned error.
also the logging is not "ERROR" it is in "DEBUG".

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
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

], _flowTable=FlowTableRef [_value=KeyedInstanceIdentifier

], _instructions=Instructions{getInstruction=[Instruction{getInstruction=ApplyActionsCase{getApplyActions=ApplyActions{getAction=[Action{getAction=DecNwTtlCase{getDecNwTtl=DecNwTtl{augmentations={}}, augmentations={}}, getOrder=0, augmentations={}}], augmentations={}}, augmentations={}}, getOrder=0, augmentations={}}], augmentations={}}, _match=Match{getEthernetMatch=EthernetMatch{getEthernetType=EthernetType{getType=EtherType [_value=2048], augmentations={}}, augmentations={}}, getLayer3Match=Ipv4Match{getIpv4Destination=Ipv4Prefix [_value=10.0.10.2/24], augmentations={}}, augmentations={}}, _node=NodeRef [_value=KeyedInstanceIdentifier

], _priority=2, _tableId=0, _transactionUri=Uri [_value=DOM-1], _strict=false, augmentation=[]], errors=Device reported error type BADMATCH code BADWILDCARDS

So this then looks like it is working as intended, closing.