[OPNFLWPLUG-11] set-vlan-action does not work Created: 04/Jan/14  Updated: 27/Sep/21  Resolved: 24/Jan/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Jan Medved Assignee: Gaurav Bhagwani
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: Macintosh


External issue ID: 268

 Description   

when set-vlan-action is used in a flow-add operation from restconf, no flow-mod message is sent to the switch. All other parameters of the flow with a different action.

The following xml can be used to reproduce the problem:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<strict>false</strict>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<set-vlan-id-action>
<vlan-id>4000</vlan-id>
</set-vlan-id-action>
</action>
</apply-actions>
</instruction>
</instructions>
<table_id>0</table_id>
<id>138</id>
<cookie_mask>10</cookie_mask>
<installHw>false</installHw>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.0.1/24</ipv4-destination>
</match>
<hard-timeout>12</hard-timeout>
<flags>FlowModFlags [_cHECKOVERLAP=false, _rESETCOUNTS=false, _nOPKTCOUNTS=false, _nOBYTCOUNTS=false, _sENDFLOWREM=false]</flags>
<cookie>10</cookie>
<idle-timeout>34</idle-timeout>
<flow-name>FooXf14</flow-name>
<priority>2</priority>
<barrier>false</barrier>
</flow>

use the following URL:

http://192.168.4.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/138



 Comments   
Comment by Martin Sunal [ 10/Jan/14 ]

All values are put into a transaction correctly. It seems that bug is in another component - moved to md-sal

Comment by Tony Tkacik [ 21/Jan/14 ]

Run this test against testProvider node foo:node:1, the data went through MD-SAL unchanged. Bug is probably somewhere down in the pipeline.

PUT URI:

http://127.0.0.1:8080/restconf/config/opendaylight-inventory:nodes/node/foo:node:1/table/0/flow/138

XML:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<strict>false</strict>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<set-vlan-id-action>
<vlan-id>4000</vlan-id>
</set-vlan-id-action>
</action>
</apply-actions>
</instruction>
</instructions>
<table_id>0</table_id>
<id>138</id>
<cookie_mask>10</cookie_mask>
<installHw>false</installHw>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.0.1/24</ipv4-destination>
</match>
<hard-timeout>12</hard-timeout>
<flags></flags>
<cookie>10</cookie>
<idle-timeout>34</idle-timeout>
<flow-name>FooXf14</flow-name>
<priority>2</priority>
<barrier>false</barrier>
</flow>

Log Output:

2014-01-21 11:14:55.197 CET [md-sal-binding-commit-1] INFO o.o.o.t.OpenflowpluginTestServiceProvider - addFlow - 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=foo:node: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=138]]]]]], _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=foo:node: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=false, _bufferId=null, _containerName=null, _cookieMask=10, _flags=FlowModFlags [_cHECKOVERLAP=false, _rESETCOUNTS=false, _nOPKTCOUNTS=false, _nOBYTCOUNTS=false, _sENDFLOWREM=false], _flowName=FooXf14, _installHw=false, _instructions=Instructions [_instruction=[Instruction [_order=0, _key=InstructionKey [_order=0], _instruction=ApplyActionsCase [_applyActions=ApplyActions [_action=[Action [_order=0, _key=ActionKey [_order=0], _action=SetVlanIdActionCase [_setVlanIdAction=SetVlanIdAction [_vlanId=VlanId [_value=4000], augmentation=[]], augmentation=[]], augmentation=[]]], augmentation=[]], augmentation=[]], augmentation=[]]], augmentation=[]], _match=Match [_ethernetMatch=EthernetMatch [_ethernetDestination=null, _ethernetSource=null, _ethernetType=EthernetType [_mask=null, _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/24], _ipv4Source=null, augmentation=[]], _layer4Match=null, _metadata=null, _protocolMatchFields=null, _tunnel=null, _vlanMatch=null, augmentation=[]], _outGroup=null, _outPort=null, _strict=false, _cookie=10, _hardTimeout=12, _idleTimeout=34, _priority=2, _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=foo:node:1]]]]]], _transactionUri=Uri [_value=BA-2], augmentation=[]]

2014-01-21 11:14:55.197 CET [md-sal-binding-commit-1] INFO o.o.c.m.s.c.i.service.TwoPhaseCommit - Transaction: BA-2 Finished successfully.

From log you could see that VlanAction was sent out of MD-SAL.

SetVlanIdActionCase [_setVlanIdAction=SetVlanIdAction [_vlanId=VlanId [_value=4000]]

Comment by Gaurav Bhagwani [ 22/Jan/14 ]

Can it be confirmed please that are we testing this particular action on 1.0 switch or 1.3 switch since SetVlanIdAction is 1.0 specific

Comment by Michal Polkorab [ 22/Jan/14 ]

I have debugged the serialization and found out that the problem is in the OF Plugin.

Logs when debugging openflowjava:
2014-01-22 14:45:48.787 CET [nioEventLoopGroup-8-2] WARN o.o.o.p.i.u.InstructionsSerializer - ACTIONS IN APPLY INSTRUCTIONS NOT NULL
2014-01-22 14:45:48.787 CET [nioEventLoopGroup-8-2] WARN o.o.o.p.impl.util.ActionsSerializer - COMPUTE LENGTH IN ACTIONS
2014-01-22 14:45:48.787 CET [nioEventLoopGroup-8-2] WARN o.o.o.p.impl.util.ActionsSerializer - ACTIONSLIST NOT NULL
2014-01-22 14:45:48.787 CET [nioEventLoopGroup-8-2] WARN o.o.o.p.impl.util.ActionsSerializer - ACTIONSLIST IS EMPTY
2014-01-22 14:45:48.787 CET [nioEventLoopGroup-8-2] WARN o.o.o.p.i.u.InstructionsSerializer - ACTIONS IN APPLY INSTRUCTIONS NOT NULL - LENGTH: 0

Problem is in the ActionConvertor, where the received action was SetVlanIdActionCase [_setVlanIdAction=SetVlanIdAction [_vlanId=VlanId [_value=4000]]

  • this action is used in the OF 1.0, and in the OF 1.3 causes following exception:

2014-01-22 14:45:48.779 CET [md-sal-binding-commit-16] ERROR o.o.o.o.m.c.s.c.ActionConvertor - Unknown Action Type for the Version

I am not familiar with the md-sal's models, but it is probably needed to choose the correct action depending on the version first, and then finding the corresponding action. (In this case I believe it should have been SetField action with VlanId oxm-field)

NOTE:
Looking into FlowConvertor.java:

if (flow.getInstructions() != null)

{ flowMod.setInstructions(toInstructions(flow.getInstructions(), version,datapathid)); flowMod.setActionsList(getActionsList(flow.getInstructions(), version,datapathid)); }

actions should be filled only in case of OF 1.0, instructions in case of OF 1.3.

Comment by Michal Polkorab [ 22/Jan/14 ]
  • this happens when using CpQd OF 1.3 switch
Comment by Gaurav Bhagwani [ 22/Jan/14 ]

With Cpqd 1.3 , action set-vlan-id wont work , since set-vlan-id is 1.0 application , Hence plugin throws exception ERROR o.o.o.o.m.c.s.c.ActionConvertor - Unknown Action Type for the Version

Comment by Michal Polkorab [ 22/Jan/14 ]

But MD-sal models are protocol agnostic - so they can't model all openflow specific action types. That's why it should be translated / converted depending on the version.

Because Vlan field makes sense in the OF 1.3 either, so message like this will be used.

Michal

Comment by Gaurav Bhagwani [ 24/Jan/14 ]

raised review for the bug :
https://git.opendaylight.org/gerrit/#/c/4697/

Generated at Wed Feb 07 20:31:20 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.