Operating System: Linux
Platform: PC

I am not hitting the issue with Ovs and latest controller code
Input:

Rest Url : http://169.144.112.36:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/248

Put Input :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<strict>false</strict>
<flow-name>FooXf248</flow-name>
<id>248</id>
<cookie_mask>255</cookie_mask>
<cookie>889</cookie>
<table_id>2</table_id>
<priority>8</priority>
<hard-timeout>1200</hard-timeout>
<idle-timeout>3400</idle-timeout>
<installHw>false</installHw>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<push-mpls-action>
<ethernet-type>34888</ethernet-type>
</push-mpls-action>
</action>
</apply-actions>
</instruction>
</instructions>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
<ethernet-destination>
<address>20:14:29:01:19:61</address>
</ethernet-destination>
<ethernet-source>
<address>00:00:00:11:23:ae</address>
</ethernet-source>
</ethernet-match>
<ipv4-source>19.1.2.3/10</ipv4-source>
<ipv4-destination>172.168.5.6/18</ipv4-destination>
<ip-match>
<ip-protocol>17</ip-protocol>
<ip-dscp>8</ip-dscp>
<ip-ecn>3</ip-ecn>
</ip-match>
<udp-source-port>25364</udp-source-port>
<udp-destination-port>8080</udp-destination-port>
<in-port>0</in-port>
</match>
</flow>

Status : 200 Ok

On Ovs Switch :

mininet@mininet-vm:~$ sudo ovs-ofctl -O openflow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):

cookie=0x379, duration=10.587s, table=2, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, send_flow_rem priority=8,udp,in_port=0,dl_src=00:00:00:11:23:ae,dl_dst=20:14:29:01:19:61,nw_src=19.0.0.0/10,nw_dst=172.168.0.0/18,nw_tos=32,nw_ecn=3,tp_src=25364,tp_dst=8080 actions=push_mpls:0x8848

On Cpqd Switch :

root@ubuntu:/cpqd/ofsoftswitch13# sudo dpctl tcp:127.0.0.1:6681 stats-flow

SENDING:
stat_req{type="flow", flags="0x0", table="all", oport="any", ogrp="any", cookie=0x0", mask=0x0", match=oxm{all match}}

RECEIVED:
stat_repl{type="flow", flags="0x0", stats=[{table="2", match="oxm

", dur_s="12", dur_ns="893000", prio="8", idle_to="3400", hard_to="1200", cookie="0x379", pkt_cnt="0", byte_cnt="0", insts=[apply{acts=[mpls_psh

]}]}

Gaurav, we are blocked with testing Actions, set-field because of flow entries not being pushed to OVSK switch. We are using following versions
Mininet 2.0.0
OVS 1.10.0
Openflowplugin and mininet are running on 2 different Ubuntu 12.04 machines.

Is it possible to fix the issue for Mininet 2.0.0 with OVS 1.10.0 as we are facing lots of issues installing/configuring Mininet 2.1.0 with OVS 2.0.0.

Attachment f113.xml has been added with description: set-nw-ttl test-case

Attachment f120.xml has been added with description: set-field-tcp-source-port test-case

Version Info:
=============
This is the "newer mininet-2.1.0 with OVS-2.0" VM given @OpenDaylight OpenFlow Plugin::End to End Inventory wiki.
The .vmdk image is corrupt, I guess it was not detached cleanly and it refused to load on VirtualBox.
Workaround: Install VMware Player, load the .vmdk, it should import without failures, and then create a new VM in VirtualBox by pointing it to this imported .vmdk. I can upload this vmdk to SkyDrive if you want (~6GB).

krish@krish-Ubuntu32:~$ ssh mininet@192.168.56.105 -X
mininet@192.168.56.105's password:
Welcome to Ubuntu Trusty Tahr (development branch) (GNU/Linux 3.12.0-4-generic x86_64)

• Documentation: https://help.ubuntu.com/
  Last login: Wed Jan 22 08:57:49 2014 from 192.168.56.101

mininet@mininet-vm:~$ mn --version
2.1.0

mininet@mininet-vm:~$ ovs-ofctl -V
ovs-ofctl (Open vSwitch) 2.0.0
Compiled Nov 11 2013 12:25:52
OpenFlow versions 0x1:0x4

mininet@mininet-vm:~$ uname -a
Linux mininet-vm 3.12.0-4-generic #12-Ubuntu SMP Tue Nov 26 22:38:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
=============

Initially, we thought it was an environment issue when you mentioned that it worked for you.
Attaching some of the XMLs that failed the test cases.
Please comment with the version, the output of the test-cases, and workarounds, if any.

Scenario:
1. Run mininet: sudo mn --controller=remote,ip=192.168.56.101:6653 --topo=tree,1 --switch=ovsk,protocols=OpenFlow13
2. Do a POST & then GET with the attached XMLs. Both succeed.
3. Without deleting the flow, query the ovsk switch using: sudo ovs-ofctl -O OpenFlow13 dump-flows s1

URL: 192.168.56.101:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/256

The flows and table IDs change as per the XMLs.

Plugin Version:
krish@krish-Ubuntu32:~/Desktop/my-projects/openflowplugin$ git log
commit f915ce0b7a97e1be1eb64210b8a72b3c1b9b3693
Author: Juraj Sebin <jsebin@cisco.com>
Date: Tue Jan 21 15:28:19 2014 +0100

updates in test scripts
-tests scripts are running in sequence
-new validation method
-structure of xml is validated before test

Change-Id: I6931f6449370f65df9a081e3089f9f8d0c0e20e8
Signed-off-by: Juraj Sebin <jsebin@cisco.com>

I have the following observation on that :

1) I tested with the xml provided in the bug, on the OVS Switch, it throws bad action error from switch

Input:
set-nw-ttl test case

Error :

2014-01-23 16:49:02.268 IST [pool-29-thread-3] ERROR o.o.o.o.m.c.t.ErrorTranslator - Error Message received: type=2[BADACTION], code=0[

H♦░ ☻ ☺ ☺ yÇ 09[04 0e 00 c0 00 00 03 69 00 00 00 00 00 00 00 65 00 00 00 00 00 00 00 ff 02 00 0d 48 04 b0 00 02 ff ff

ff ff ff ff ff ff ff ff ff ff 00 01 00 00 00 01 00 79 80 00 04 08 00 00 00 00 00 00 30 39 ]

2014-01-23 16:49:02.273 IST [md-sal-binding-notification-2] INFO o.o.c.sal.binding.impl.NotifyTask -

2) I tried pushing flows through OpenflowpluginTestCommandProvider available at plugin , it has f37 as testcase for set_nwttl

Input :

addMDFlow openflow: <dpid> f37

Error :
2014-01-23 16:49:02.268 IST [pool-29-thread-3] ERROR o.o.o.o.m.c.t.ErrorTranslator - Error Message received: type=2[BADACTION], code=0[

H♦░ ☻ ☺ ☺ yÇ 09[04 0e 00 c0 00 00 03 69 00 00 00 00 00 00 00 65 00 00 00 00 00 00 00 ff 02 00 0d 48 04 b0 00 02 ff ff

ff ff ff ff ff ff ff ff ff ff 00 01 00 00 00 01 00 79 80 00 04 08 00 00 00 00 00 00 30 39 ]

2014-01-23 16:49:02.273 IST [md-sal-binding-notification-2] INFO o.o.c.sal.binding.impl.NotifyTask -

3) I tried both the above senerio on cpqd and it works fine

Input1:

<above xml>

Input2:

addMDFlow openflow:1 f37

Output1:

stat_repl{type="flow", flags="0x0", stats=[{table="2", match="oxm

", dur_s="6", dur_ns="275000", prio="2", idle_to="3400", hard_to="1200", cookie="0x65", pkt_cnt="0", byte_cnt="0", insts=[apply{acts=[nw_ttl

]}]}]}

4) I also tried from Ovs command line giving below command, but it gives Unknown action : nw_ttl

mininet@mininet-vm:~$ sudo ovs-ofctl -O Openflow13 add-flow s1 in_port=1,actions=nw_ttl:2,output:2
ovs-ofctl: Unknown action: nw_ttl
mininet@mininet-vm:~$ sudo ovs-ofctl -O Openflow13 add-flow s1 in_port=1,actions=nw_ttl=2,output:2
ovs-ofctl: Unknown action: nw_ttl

With the above observation seems like Ovs has the issue with the particular action

I was able to run

GET http://localhost:18080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/248

with body

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<strict>false</strict>
<flow-name>FooXf248</flow-name>
<id>248</id>
<cookie_mask>255</cookie_mask>
<cookie>889</cookie>
<table_id>2</table_id>
<priority>8</priority>
<hard-timeout>1200</hard-timeout>
<idle-timeout>3400</idle-timeout>
<installHw>false</installHw>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<push-mpls-action>
<ethernet-type>34888</ethernet-type>
</push-mpls-action>
</action>
</apply-actions>
</instruction>
</instructions>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
<ethernet-destination>
<address>20:14:29:01:19:61</address>
</ethernet-destination>
<ethernet-source>
<address>00:00:00:11:23:ae</address>
</ethernet-source>
</ethernet-match>
<ipv4-source>19.1.2.3/10</ipv4-source>
<ipv4-destination>172.168.5.6/18</ipv4-destination>
<ip-match>
<ip-protocol>17</ip-protocol>
<ip-dscp>8</ip-dscp>
<ip-ecn>3</ip-ecn>
</ip-match>
<udp-source-port>25364</udp-source-port>
<udp-destination-port>8080</udp-destination-port>
<in-port>0</in-port>
</match>
</flow>

and got the flow on the switch below (this is using OVS2 and mininet2.1)

vagrant@vagrant-ubuntu-trusty-64:~/git/controller$ sudo ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x379, duration=22.243s, table=2, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, send_flow_rem priority=8,udp,in_port=0,dl_src=00:00:00:11:23:ae,dl_dst=20:14:29:01:19:61,nw_src=19.0.0.0/10,nw_dst=172.168.0.0/18,nw_tos=32,nw_ecn=3,tp_src=25364,tp_dst=8080 actions=push_mpls:0x8848

HI Ed,

We were also able to run push-mpls-action successfully but other actions like set-nw-ttl fails.

Best Regards,
Praveen Darshanam

Ed/Prasanna,
Push mpls works with OVS 2.0.0.
I have attached set-nw-ttl XML to the bug. Please check with that. Thanks.

Regarding testing setField - tcp source , It works fine for me on the Ovs -switch

Input :
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<strict>false</strict>
<flow-name>set-field-tcp-src</flow-name>
<id>256</id>
<cookie_mask>255</cookie_mask>
<cookie>101</cookie>
<table_id>2</table_id>
<priority>2</priority>
<hard-timeout>1200</hard-timeout>
<idle-timeout>3400</idle-timeout>
<installHw>false</installHw>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<set-field>
<tcp-source-port>2059</tcp-source-port>
</set-field>
</action>
</apply-actions>
</instruction>
</instructions>
<match>
<ethernet-match>
<ethernet-type>
<type>34525</type>
</ethernet-type>
</ethernet-match>
<ipv6-source>1234:5678:9ABC:DEF0:FDCD:A987:6543:210F/76</ipv6-source>
<ipv6-destination>fe80:2acf:e9ff:fe21::6431/94</ipv6-destination>
<metadata>
<metadata>12345</metadata>
</metadata>
<ip-match>
<ip-protocol>6</ip-protocol>
<ip-ecn>3</ip-ecn>
</ip-match>
<tcp-source-port>183</tcp-source-port>
<tcp-destination-port>8080</tcp-destination-port>
</match>
</flow>

Output on switch :

mininet@mininet-vm:~$ sudo ovs-ofctl -O Openflow13 dump-flows s1

OFPST_FLOW reply (OF1.3) (xid=0x2):

cookie=0x65, duration=5.158s, table=2, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, send_flow_rem priority=2,tcp6,metadata=0x3039,ipv6_src=1234:5678:9abc:def0:fdc0::/76,ipv6_dst=fe80:2acf:e9ff:fe21::/94,nw_ecn=3,tp_src=183,tp_dst=8080 actions=set_field:2059->tcp_src

Hi Gaurav,
1. TCP (set src and dst port), MPLS (push and pop) works after upgrading to OVS 2.0.0.
2. We are testing the issues here and creating a list of all actions that fail.
All ARP SET_FIELD operations fail. OVS CLI states that those are read only fields.

Gaurav,
Also all actions (or set fields) fails when there are multiple actions.
We are changing the XMLS and CLI commands to take only 1 action for now

Gaurav,

Any update?

Thanks,
Abhijit

Hi Abhijit,

I have updated above my observations on the particular bug

This was fixed in the Hydrogen release itself.

There are couple of fields which which working fine and most of the fields don't work.
As per our knowledge the bug was not fixed yet, will verify the same with LATEST git clone of openflowplugin.