Operating System: All
Platform: All

Attachment Snapshot(2).png has been added with description: WireShark Trace Capture Showing Only One Action Sent from Controller To Switch

I did talk with Michal, Just adding these comments also
<knanda> I am still facing the issue. You may have got my email
<oflibMichal> I wanted to try it myself, but I don't have working karaf distribution at the moment
<knanda> I have mininet s1 switch on protocol OpenFlow13, mininet version 2.2.0 and ovs-vsctl version 2.1.3
<knanda>
<knanda> Well, I do have couple of other similar bugs
<oflibMichal> can you try one more change ?
<knanda> sure
<knanda> I have the setup and ready to go
<oflibMichal> instead of using hexa number ... please use decimal
<oflibMichal> here >>> <ethernet-type>0x88A8</ethernet-type>
<knanda> okay
<knanda> see, <ethernet-type>34984</ethernet-type> ?
<oflibMichal> right
<knanda> again says the same thing
<knanda> Schema node \"ethernet-type\" not found
<knanda> in the module.
<knanda> if you see my mail, and I send it using the original flow1.xml (meaning before this change)
<oflibMichal> yes, i have seen it
<knanda> I see the flow getting installed on the Controller
<knanda> However it does not get installed on the switch
<knanda> the reason is if you look at the wireshark trace
<knanda> only one action is being sent
<oflibMichal> agree
<knanda> do you want me to open a bug on this ?
<oflibMichal> not yet
<oflibMichal> another solution comes to my mind
<oflibMichal> just give me a sec
<knanda> sure
<knanda> sure
<oflibMichal> please try using "wrapped" tag
<oflibMichal> like this >>> <ethernet-match>
<oflibMichal> <ethernet-type>
<oflibMichal> <type>34525</type>
<oflibMichal> </ethernet-type>
<oflibMichal> </ethernet-match>
<oflibMichal> just add opening and closing <ethernet-match> tags before and after <ethernet-type>
<knanda> ok, doing it now
<knanda> the ethernet type is 34525 or 34984 (in hex 34984 is 0x88A8)
<oflibMichal> in your case it should be 34984
<knanda> btw, I get this error
<oflibMichal> i copied this part from one test script
<knanda> error-type: "protocol"
<knanda> error-tag : "invalid-value"
<knanda> error-message : "unhandled parameter types [container ethernet-type]"
<knanda>
<oflibMichal> ok, so please file new bug for openflowplugin

Hi Kuldip,

I have investigated your issue more and finally I am able to push your flow to switch. The flow should look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<priority>2</priority>
<flow-name>FooBar</flow-name>
<id>4</id>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
<ethernet-source>
<address>6A:DC:0A:EF:2E:DC</address>
</ethernet-source>
</ethernet-match>
</match>
<table_id>10</table_id>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<output-action>
<output-node-connector>openflow:1:2</output-node-connector>
</output-action>
</action>
<action>
<order>1</order>
<set-field>
<ethernet-match>
<ethernet-type>
<type>34984</type>
</ethernet-type>
</ethernet-match>
</set-field>
</action>
</apply-actions>
</instruction>
</instructions>
</flow>

My OVS switch replies with error message - BAD ACTION - OFPBAC_BAD_SET_ARGUMENT = 15, /* Bad argument in SET_FIELD action. */
This seems like the switch can't handle the ethernet-type argument inside set-field action. I am using OVS 2.1.3 - maybe newer version fixed this issue.

thanks for the help Michal. The latest version of OVS-SWITCH is 2.3.1. I have not tried with it. This however does narrow the scope of the bug somewhat

Closely tied to this is also another issue with DLUX/YNAG-UI Model. Where the original UI produces the original JSON and gives the error.

As you suggested is this the correct JSON/REST API for setting the dl-type. Should this defect then be changed to YANG-UI.

Yes, this is corrrect XML. So it is probably a good question for YANG-UI developers. I don't know the answer.

I see the same issue with opendaylight not sending an action of setting the ethernet-type if the "apply-actions-case_set-dl-type-action-case" field is used in the YangUI for flow installation. The same is true if I use JSON for this.

As pointed to by Michal, it seems to be working with new JSON as the action is being sent, but the DLUX YANG-UI is generating wrong JSON as well does not send the complete action sequence. I have bunch of bugs opened which all are of similar type.

Here is the complete list
1. OpenDaylight will not send an action of loopback (looping the traffic back out the input port) if the "apply-actions-case_loopback-action-case" field is used in the YangUI or JSON/CURL for flow installation.
2. OpenDaylight will not send all fields (tag, pcp, cfi, and vlan-id are missing but ethtype shows up) from the push-vlan-action if the "apply-actions-case_push-vlan-action-case" field is used in the YangUI for flow installation.
3. OpenDaylight will not send an action of flood if the "apply-actions-case_flood-action-case" field is used in the YangUI or JSON/CURL for flow installation.
4. OpenDaylight will not send an action of software-path if the "apply-actions-case_sw-path-action-case" field is used in the YangUI or JSON/CURL for flow installation.
5. OpenDaylight will not send an action of hardware-path if the "apply-actions-case_hw-path-action-case" field is used in the YangUI or JSON/CURL for flow installation.

Any advice on this will be great.

In all these cases we have missing action field

Should be taken care of by model cleanup in lithium

Attachment flow_mod_with_buffer_id_0.pcap has been added with description: flow mod using buffer_id == 0

(In reply to Jamo Luhrsen from comment #8)
> Created attachment 386 [details]
> flow mod using buffer_id == 0

this comment/attachment was made in error. please ignore

this could be duplicate modeled action due to intersection of OF 1.0 & 1.3

No activity on the bug for over an year, so closing the bug. Please feel free to re-open the bug if you see the issue with carbon/nitrogen/oxygen branch.