Operating System: Windows
Platform: PC

Note, this is the old API, not the new RESTCONF API.

So this is an issue with the MD-SAL Adaptation.

I tried it today. This works fine for me in the sense I get a 204 - the flow itself does not get removed from the switch which is a separate issue problem on the openflowplugin/openflowjava side.

Please reverify.

Verified. Works fine.
Using the DELETE URL, the flow gets deleted from switch as well but "204 - No Content" in response.

Following is the test procedure followed:

I created a mininet topology with 1 switch and 3 hosts on Mininet OPenflow1.3.
Added 2 flows statically through dashboard.
Can see the flows through URI
GET http://192.168.56.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:1/staticFlow/flow1
GET http://192.168.56.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:1/staticFlow/flow2

Also can see the flows on switch through mininet : dpctl dump-flows

Now if i delete the flows through URL
DELETE http://192.168.56.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:1/staticFlow/flow1
the flow gets deleted from switch but gives "204 - No Content" in response body.

Attachment Screenshots_290.zip has been added with description: Screenshots for test procedure

Attachment FRM_defect_OF10mininet.txt has been added with description: FRM_defect_OF10mininet

Hi,

It worked fine for OF13mininet as seen with the screenshots. Can you try using the same procedure for OF10 mininet? Have elaborated the defect in the attachment "FRM_defect_OF10mininet.txt"

Hi,

To be clear, here is the details for the issue.

After you add the flow (Using OF10 mininet), I get 201 response. But, when I look at the statistics, I could not see the match field for IP address, due to which the flow statistics is failing.

I have the new openflowplugin integrated and used Mininet Openflow1.0.
The GET response shows details of the flow that was previously added.(Very different from what you are getting)

Have created the attachment for detailed explanation.
DELETE also works fine for mininet OF10

Attachment OF1mininet.txt has been added with description: FRM OF10 mininet

Hi,

Can you do the following steps in your setup and confirm back?

For OF13 mininet:

1. Start the controller using -OF13 option
2. Use the command for mininet
sudo mn --controller=remote,ip=127.0.0.1 --topo tree,3 --switch ovsk,protocols=OpenFlow13
3. PUT http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1
Include the below body:
-------------------------------------------------------------------------------
<flowConfig>
<installInHw>true</installInHw>
<name>flow1</name>
<node>
<id>openflow:6</id>
<type>MD_SAL</type>
</node>
<priority>1</priority>
<etherType>0x800</etherType>
<nwDst>10.0.0.1/32</nwDst>
<actions>OUTPUT=openflow:6:1</actions>
</flowConfig>
-------------------------------------------------------------------------------
4. GET http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1

Confirm here whether you get the correct flow

5. GET http://127.0.0.1:8080/controller/nb/v2/statistics/default/flow
You must be able see the flow for the particular node (Node is Openflow:6). Also, Check the match field i.e IP address for the particular node (Openflow:6) in the response
6. DELETE http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1
7. Repeat step 4 and step 5 and check the flow doesn't exists.

For OF13 mininet:

8. Use the command for mininet
sudo mn --controller=remote,ip=127.0.0.1 --topo tree,3
9. Repeat steps 3,4,5
10. Check the match field i.e IP address for the particular node (Openflow:6) in the response
11.Repeat step 6 and 7, check the flows doesn't exists.

It will be good if you could write YES/NO with your findings for every steps to avoid confusion.

Thanks

Please find the correct typo error in my previous comments:

For steps 8 - 11, it is for OF10 mininet.

One more findings:

It is not a problem on stats, the flow is NOT installed correctly in the switch after pushing this:

PUT http://10.125.136.52:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:2/staticFlow/flow1

<flowConfig>
<installInHw>true</installInHw>
<name>flow1</name>
<node>
<id>openflow:2</id>
<type>MD_SAL</type>
</node>
<priority>1</priority>
<etherType>0x800</etherType>
<nwDst>10.0.0.1/32</nwDst>
<actions>OUTPUT=openflow:2:1</actions>
</flowConfig>

mininet@mininet-vm:~\> sudo ovs-ofctl dump-flows s2
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=12.23s, table=0, n_packets=0, n_bytes=0, idle_age=12, priority=1,ip actions=output:1

Note there is no <NwDst> match field in the installed flow!

Hi Madhusudhan,

Your observation is correct.

Please find the comments inline:

For OF13 mininet:

1. Start the controller using -OF13 option
2. Use the command for mininet
sudo mn --controller=remote,ip=127.0.0.1 --topo tree,3 --switch ovsk,protocols=OpenFlow13
3. PUT http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1
Include the below body:
<flowConfig>
<installInHw>true</installInHw>
<name>flow1</name>
<node>
<id>openflow:6</id>
<type>MD_SAL</type>
</node>
<priority>1</priority>
<etherType>0x800</etherType>
<nwDst>10.0.0.1/32</nwDst>
<actions>OUTPUT=openflow:6:1</actions>
</flowConfig>

Yes - The flow gets installed on the switch, although we cant see the nwDst field in mininet.
-------------------------------------------------------------------------------
4. GET http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1

Confirm here whether you get the correct flow - Yes we can see the same flow we installed previously
-------------------------------------------------------------------------------
5. GET http://127.0.0.1:8080/controller/nb/v2/statistics/default/flow
You must be able see the flow for the particular node (Node is Openflow:6). Also, Check the match field i.e IP address for the particular node (Openflow:6) in the response

No, Match field does not show the nwDst
-------------------------------------------------------------------------------
6. DELETE http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1

Yes, the flow gets deleted from the switch
-------------------------------------------------------------------------------

7. Repeat step 4 and step 5 and check the flow doesn't exists.
Repeated step 4: 404 not found
Repeated step 5: Flow does not exist
-------------------------------------------------------------------------------

Also i have attached a detailed report of all the usecases that i tried along with their observations.

Attachment TestCases.ods has been added with description: Test cases

I was trying to find the root cause for the missing ip field (nwSrc / nwDst) in flow statistics. As per my observations whenever any changes corresponding to flow are made, the flowStatistics cache is updated in

StatisticsManager.java:
public void nodeFlowStatisticsUpdated(Node node, List<FlowOnNode> flowStatsList) {
}

So when I do
PUT http://192.168.56.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1

<flowConfig>
<installInHw>true</installInHw>
<name>flow1</name>
<node>
<id>openflow:6</id>
<type>MD_SAL</type>
</node>
<priority>1</priority>
<etherType>0x800</etherType>
<nwDst>10.0.0.1/32</nwDst>
<actions>OUTPUT=openflow:6:1</actions>
</flowConfig>

then, ""nodeFlowStatisticsUpdated(Node node, List<FlowOnNode> flowStatsList) {}"" method is called.

While debugging I observed the flowStatsList passed as an argument to the above method missed the ip fields(nwSrc / nwDst) in match.
But I could see the DL_TYPE field in match, which is retrieved when we hit URI----> GET http://192.168.56.1:8080/controller/nb/v2/statistics/default/flow

So basically whenever the flow is created in a switch,the match fields in flowStatistics cache is not updated properly because of which it is missing in the response. Seems the issue is in Statistics manager.

Hi Madhusudhan/Priyanka,

There are two minor issues that's causing this bug.

1) When user adds flow to the switch, plugin was sending 0 as a mask down to the switch (because it's not getting mask associated with the IP), and that's why you were not seeing ip address when you were dumping flows from switch. So one issue still remains is why plugin is receiving only ip address (10.0.0.1) and not mask(/32) when user is providing both -ip address with mask (10.0.0.1/32). I think somebody who is aware of that part of code should investigate this. Irrespective of this issue, if plugin gets ip address with no mask, its mask should be set to /32 rather then 0. Mask=0 means, it masks the whole IP address and makes it wildcard. Once I changed the mask to /32, I was able to see the ip address in the switch flows.

Deepti/Prasanna-- can you please investigate this issue. You can follow the steps in "Comment 10" above. If you put break point in addFlow() method of ModelDrivenSwitchImpl.java and connect your eclipse to controller jvm in remote debugging mode, this is what you get as AddFlowInput:

AddFlowInput [_flowRef=FlowRef [_value=InstanceIdentifier [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:1]]], 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=677b32e3-bd81-4b06-b081-d63def7286e2]]]]]], _flowTable=FlowTableRef [_value=InstanceIdentifier [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:1]]], 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]]]]], _barrier=null, _bufferId=null, _containerName=null, _cookieMask=null, _flags=null, _flowName=null, _installHw=null, _instructions=Instructions [_instruction=[Instruction [_order=0, _key=InstructionKey [_order=0], _instruction=ApplyActionsCase [_applyActions=ApplyActions [_action=[Action [_order=null, _key=ActionKey [], _action=OutputActionCase [_outputAction=OutputAction [_maxLength=null, _outputNodeConnector=Uri [_value=openflow:1:1], augmentation=[]], augmentation=[]], augmentation=[]]], augmentation=[]], augmentation=[]], augmentation=[]]], augmentation=[]], _match=Match [_ethernetMatch=EthernetMatch [_ethernetDestination=null, _ethernetSource=null, _ethernetType=EthernetType [_type=EtherType [_value=2048], augmentation=[]], augmentation=[]], _icmpv4Match=null, _icmpv6Match=null, _inPhyPort=null, _inPort=null, _ipMatch=null, _layer3Match=Ipv4Match [_ipv4Destination=Ipv4Prefix [_value=10.0.0.1], _ipv4Source=null, augmentation=[]], _layer4Match=null, _metadata=null, _protocolMatchFields=null, _tunnel=null, _vlanMatch=null, augmentation=[]], _outGroup=null, _outPort=null, _strict=null, _cookie=0, _hardTimeout=0, _idleTimeout=0, _priority=1, _tableId=0, _node=NodeRef [_value=InstanceIdentifier [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:1]]]]]], _transactionUri=Uri [_value=BA-3598], augmentation=[]]

So if you notice
_layer3Match=Ipv4Match [_ipv4Destination=Ipv4Prefix [_value=10.0.0.1], _ipv4Source=null, augmentation=[]],

IP String plugin received is 10.0.0.1 and not 10.0.0.1/32 what user entered.

2) Minor issue while decoding IP addresses from statistics response. I was using wrong wild card to make decision to decode the IP addresses.

After fixing both these issues I can see that its working as expected.

I pushed code changes through following gerrit:

https://git.opendaylight.org/gerrit/#/c/4872/

Once it get merged can you please verify it.

Thanks
Anil

Adding Prasanna/Deepti in CC

I still see the same issue after merging into the latest code.

FYI, I have taken the latest code at

wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.0-SNAPSHOT-osgipackage.zip

Please let me know the process/steps that you have tested so far.

Thanks

Tested for OF10 and OF13.
Works fine.
Test Procedure

1.for OF10 : sudo mn --controller=remote,ip=127.0.0.1 --topo tree,3 --switch

Tested for OF10 and OF13.
Works fine.
Test Procedure followed

For OF13 mininet:
1. Start the controller using -OF13 option
2. Use the command for mininet
sudo mn --controller=remote,ip=127.0.0.1 --topo tree,3 --switch ovsk,protocols=OpenFlow13
3. PUT http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1
Include the below body:
-------------------------------------------------------------------------------
<flowConfig>
<installInHw>true</installInHw>
<name>flow1</name>
<node>
<id>openflow:6</id>
<type>MD_SAL</type>
</node>
<priority>1</priority>
<etherType>0x800</etherType>
<nwDst>10.0.0.1/32</nwDst>
<actions>OUTPUT=openflow:6:1</actions>
</flowConfig>
-------------------------------------------------------------------------------

Yes - (201 created)

4. GET http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1

Confirm here whether you get the correct flow

YES-response-body

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<flowConfig>
<installInHw>true</installInHw>
<name>flow1</name>
<node>
<id>openflow:6</id>
<type>MD_SAL</type>
</node>
<priority>1</priority>
<etherType>0x800</etherType>
<nwDst>10.0.0.1/32</nwDst>
<actions>OUTPUT=openflow:6:1</actions>
</flowConfig>

*flow also seen through dpctl dump-flows

5. GET http://127.0.0.1:8080/controller/nb/v2/statistics/default/flow
You must be able see the flow for the particular node (Node is Openflow:6). Also, Check the match field i.e IP address for the particular node (Openflow:6) in the response

YES-response body match field:

<match>
<matchField>
<type>NW_DST</type>
<value>10.0.0.1</value>
</matchField>
<matchField>
<type>DL_TYPE</type>
<value>2048</value>
</matchField>
</match>

6. DELETE http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/MD_SAL/openflow:6/staticFlow/flow1

Yes-(204 No Content)

7. Repeat step 4 and step 5 and check the flow doesn't exists.
Yes- (404 NOt Found)

For OF10 mininet:

8. Use the command for mininet
sudo mn --controller=remote,ip=127.0.0.1 --topo tree,3

9. Repeat steps 3,4,5
Yes - Verified (getting required response)

10. Check the match field i.e IP address for the particular node (Openflow:6) in the response
Yes - Verified(getting correct IP address)

11.Repeat step 6 and 7, check the flows doesn't exists.
Yes - Verified(flow doesn't exist)

Hi Madhusudhan,

Looks like sunny is able to verify that this issue is resolved now.

Sunny, can you please share the details of the build you used for verifying the fix with madhusudhan?

Thanks
Anil

Yes, I agree this issues is fixed now.