Operating System: Windows
Platform: PC

Hi Madhusudhan,
the of10 part looks like you managed to send some error messages during handshake - this is solid bug.

The of13 part looks like you are pushing flows into disconnected device. Could you provide more details about you setup - which build are you using, OS?

Thank you,
Michal

For OF13 part, I used the build from integration repo.

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

After running the controller using -of13 option, I started mininet, however it found to be working fine but I could see those errors in OSGi logs.

Regarding OS, I used CentOS.

Thanks,
Madhusudhan

regarding mininet(of10):
https://git.opendaylight.org/gerrit/#/c/6513/

regarding mininet(of13):

How many exceptions of this type are you getting? There should be none or only a few (sometimes the switch disconnects right after connecting - but happens only at the beginning). Also could you check if all expected switches are registered?

http://localhost:8080/restconf/operational/opendaylight-inventory:nodes/

Thank you.

Attachment OSGi_Errors.txt has been added with description: OSGi errors

Hi Michel,

I just picked the latest build from integration repo. The things are encountered during the testing and have attached the document(OSGi_Errors) for clear information.

Please let me know if you need any additional information.

Thanks,
Madhusudhan

java.lang.InterruptedException are kind of new issue - will be solved separately

ERROR o.o.o.protocol.impl.core.OFEncoder - Serializer for key: msgVersion: 1 msgType: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.actions.grouping.Action msgType2: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.DecNwTtl was not found

This shows, that you are trying to use OF-1.3 feature on OF-1.0 device.

java.lang.IllegalArgumentException: Session for the cookie is invalid. Reason: the switch has been recently disconnected OR inventory provides outdated information.

This comes after devices disconnected and probably ad-sal apps are still trying to add/remove flows on devices. Those will be covered by sal-compatibility bugs.

Could you please retest with either using OF-1.0 features in flow or with OF-1.3 device?

Hi Michal,

I tested the following using the latest controller. I still facing the same issues when I try to add a flow using mininet 0f10 simulation running with of13 option in controller. The issue is only using mininet of10 simulation with of13 option controller

1. wget 'https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/org.opendaylight.integration$distributions-base/artifact/org.opendaylight.integration/distributions-base/0.1.2-SNAPSHOT/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip'
-2014-04-29 16:50:37- https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/org.opendaylight.integration$distributions-base/artifact/org.opendaylight.integration/distributions-base/0.1.2-SNAPSHOT/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip

2. Start the controller using ./run.sh -of13 -Xmx1G -start
3. Start the mininet: sudo mn --controller 'remote,ip=127.0.0.1,port=6633' --topo tree,2
4. Add a flow: PUT http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/152

Body: https://wiki.opendaylight.org/view/Flow_body
5. FLows are getting installed in config: http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/152
6. But not the same in operational : GET http://localhost:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/152

7. At the switch, I could not see the flows as well when dumping the flows at the switch:
mininet@mininet-vm:~\> sudo ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):

8. I get this error in OSGi after adding a flow:

2014-04-29 16:59:01.751 PDT [nioEventLoopGroup-10-1] ERROR o.o.o.protocol.impl.core.OFEncoder - Message serialization failed
2014-04-29 16:59:01.751 PDT [nioEventLoopGroup-10-1] ERROR o.o.o.protocol.impl.core.OFEncoder - Serializer for key: msgVersion: 1 msgType: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.actions.grouping.Action msgType2: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.DecNwTtl was not found
java.lang.NullPointerException: Serializer for key: msgVersion: 1 msgType: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.actions.grouping.Action msgType2: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.DecNwTtl was not found
at org.opendaylight.openflowjava.protocol.impl.serialization.SerializerRegistryImpl.getSerializer(SerializerRegistryImpl.java:68) ~[bundlefile:na]
at org.opendaylight.openflowjava.protocol.impl.util.CodingUtils.serializeActions(CodingUtils.java:52) ~[bundlefile:na]
at org.opendaylight.openflowjava.protocol.impl.serialization.factories.OF10FlowModInputMessageFactory.serialize(OF10FlowModInputMessageFactory.java:50) ~[bundlefile:na]
at org.opendaylight.openflowjava.protocol.impl.serialization.factories.OF10FlowModInputMessageFactory.serialize(OF10FlowModInputMessageFactory.java:31) ~[bundlefile:na]
at org.opendaylight.openflowjava.protocol.impl.serialization.SerializationFactory.messageToBuffer(SerializationFactory.java:36) ~[bundlefile:na]
at org.opendaylight.openflowjava.protocol.impl.core.OFEncoder.encode(OFEncoder.java:40) [bundlefile:na]
at org.opendaylight.openflowjava.protocol.impl.core.OFEncoder.encode(OFEncoder.java:25) [bundlefile:na]
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:111) [bundlefile:4.0.17.Final]
at io.netty.channel.DefaultChannelHandlerContext.invokeWrite(DefaultChannelHandlerContext.java:647) [bundlefile:4.0.17.Final]
at io.netty.channel.DefaultChannelHandlerContext.access$2000(DefaultChannelHandlerContext.java:29) [bundlefile:4.0.17.Final]
at io.netty.channel.DefaultChannelHandlerContext$AbstractWriteTask.write(DefaultChannelHandlerContext.java:914) [bundlefile:4.0.17.Final]
at io.netty.channel.DefaultChannelHandlerContext$WriteAndFlushTask.write(DefaultChannelHandlerContext.java:968) [bundlefile:4.0.17.Final]
at io.netty.channel.DefaultChannelHandlerContext$AbstractWriteTask.run(DefaultChannelHandlerContext.java:903) [bundlefile:4.0.17.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) [bundlefile:4.0.17.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353) [bundlefile:4.0.17.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [bundlefile:4.0.17.Final]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]

I could see the same issue happening at jenkins as well:

https://jenkins.opendaylight.org/integration/job/integration-csit-base-of13/805/robot/report/log.html - Please check "Restconf Flows" after "restart mininet OF10" testcase.

Please note: Issue is happening at FRM (after adding a flow) and Host Tracker (After adding a flow) as well. I can raise it separately to avoid confusion with this one.

Please let me know if there is something wrong with my testing.

Thanks,
Madhusudhan

https://git.opendaylight.org/gerrit/#/c/6660/
(unregistering of provided node services)

Madhusudhan,
regarding your testing there is one problem: when you start integration build with -of13 parameter then you get running controller with support for OF-1.0 and OF-1.3. But then you start mininet (a assume you are using ovs backend). And ovs uses by default OF-1.0. You need to pass 'protocols' parameter' in order to use OF-1.3 by ovs.

https://wiki.opendaylight.org/view/Openflow_Protocol_Library:OpenVirtualSwitch

Hi Michal,

Yes. Thats right.

1. If I want to use of13 mininet to the controller running of13 option, I should specify the protocols=OpenFlow13 i.e.,

sudo mn --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6633' --switch ovsk,protocols=OpenFlow13

2. If I want to use of10 mininet to the controller running of13 option, I should specify the protocols=OpenFlow10 i.e.,

(a)sudo mn --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6633' --switch ovsk,protocols=OpenFlow10

OR

(b) sudo mn --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6633'

--------------------------------------------------------------------------------

A quick question: What is the correct way for invoking mininet(of10)?

Should it (a) or (b). I get different behaviors when I chose two of them.

Different responses can be seen at OPNFLWPLUG-148

Thanks,
Madhusudhan

Hi Madhusudhan,
it does not matter, id you explicitly specify OF10 protocol parameter for ovs (via mininet) because OF-1.0is the default.

Regarding different behavior - those are effects of 2 issues:

• ovs currently does not support groups - so by polling group stats device will always respond with errorMessage
• by processing of error messages (multiple of the same type) controller sometimes hit interrupted exception deep in classLoader.

Regarding your testing scenario:
DecNwTtl action is supported for OF-1.3 only. That is why you are getting the exception:
Serializer for key: msgVersion: 1 msgType: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.actions.grouping.Action msgType2: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev130731.DecNwTtl was not found

In order not to get this exception you should use some of actions supported by OF-1.0. Otherwise there is no way for OFJava/OFPlugin to recover from the state.

Sorry Michal for creating inconvenience and for the wrong body - Actually I was bit confused with the body (The link: https://wiki.opendaylight.org/view/CrossProject:Integration_Group:CSIT_Test_Plan_Base_of13 is updated with the correct response body now to avoid this type of silly mistakes in the future)

Anyways, using of10 mininet simulation, when I try to push a flow with an action <output-node-connector>openflow:1:1</output-node-connector>, I could not see the change reflected in operational datastore.

Steps to reproduce:

1. Start the mininet OF10 simulation
2. Push a flow : PUT http://10.125.136.52:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/152 and body: https://wiki.opendaylight.org/view/Flow_body – look for of10 simulation
3. Verify the flows at operational: http://10.125.136.52:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2 – I could not see the flow gets updated.

So I did some experimenting and:

• OF-10 supports only one table (table_id = 0) so pushing flow in table 0 works better - it appears in 20 secs in operational and after deleting from config it disappears from operational immediately.

• pushing flow into table 2 works too, but it will appear in operational under table 0 (as OF-10 uses no table_id in add flow message)
• and removing such a flow from config wont affect operational immediately. Statistics update will flush operational in 40-100 secs. But operational will get damaged and no more flows will appear there until switch is reconnected.

Could you please try with table_id set to 0 (in xml), so that controller will be less confused?

Anyway the behavior after flow removal resulting into cleaned operational part is not expected.

Hi Michal, Madhusudhan left the OpenDaylight project for a while to finish his college. I do not think this is a bug so you can close it.

BR/Luis

ok