Hi Luis, I’m happy to report that the bug seems to be fixed in the Carbon snapshot.
Best regards, Thomas FERRANDIZ De : Luis Gomez [mailto:[email protected]] Envoyé : mercredi 17 mai 2017 16:50 À : Thomas FERRANDIZ <[email protected]> Cc : Anil Vishnoi <[email protected]>; openflowplugin-dev <[email protected]> Objet : Re: [openflowplugin-dev] Fwd: [openflowjava-dev] ODL disconnects from switch during performance tests Can you please try same test with latest carbon: https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.6.0-SNAPSHOT/ BR/Luis On May 17, 2017, at 5:41 AM, Thomas FERRANDIZ <[email protected]<mailto:[email protected]>> wrote: Hello all, I opened this bug https://bugs.opendaylight.org/show_bug.cgi?id=8458 to track the issue. Best regards, Thomas Ferrandiz {P} R&D Engineer Network Architecture & Security <image001.gif><http://www.b-com.com/> 1219 AVENUE CHAMPS BLANCS 35510 CESSON-SÉVIGNÉ (FR) De : [email protected]<mailto:[email protected]> [mailto:[email protected]] De la part de Thomas FERRANDIZ Envoyé : jeudi 11 mai 2017 17:21 À : Anil Vishnoi <[email protected]<mailto:[email protected]>>; Luis Gomez <[email protected]<mailto:[email protected]>> Cc : openflowplugin-dev <[email protected]<mailto:[email protected]>> Objet : Re: [openflowplugin-dev] Fwd: [openflowjava-dev] ODL disconnects from switch during performance tests Hi Anil Thanks for the reply. Indeed this bug looks similar but in my case I don’t restart Karaf and OVS manually. Something causes the controller to disconnect from the switch. Regarding the instructions used, I ran a simpler test today which consists in installing 10000 flows on the switch as soon as the switch is recognized ( as detected by use a DataTreeChangeListener). The flows are all of the following types: cookie=0x0, duration=6.411s, table=0, n_packets=0, n_bytes=0, idle_age=6, priority=0, tcp, nw_src=10.0.0.1, nw_dst=10.0.0.2, tp_src=1346, tp_dst=80 actions=CONTROLLER:65535,output:1 and I increment the tp_src field for each flow. This test triggers the same unwanted disconnection between the controller and the switch. Should I open anew bug report or add it to the one you mentioned? Best regards, Thomas Ferrandiz {P} R&D Engineer Network Architecture & Security <image001.gif><http://www.b-com.com/> 1219 AVENUE CHAMPS BLANCS 35510 CESSON-SÉVIGNÉ (FR) De : Anil Vishnoi [mailto:[email protected]] Envoyé : mercredi 10 mai 2017 19:01 À : Luis Gomez <[email protected]<mailto:[email protected]>> Cc : openflowplugin-dev <[email protected]<mailto:[email protected]>>; Thomas FERRANDIZ <[email protected]<mailto:[email protected]>> Objet : Re: [openflowplugin-dev] Fwd: [openflowjava-dev] ODL disconnects from switch during performance tests https://bugs.opendaylight.org/show_bug.cgi?id=8401 I believe you are hitting the same issue reported in above bug. On Wed, May 10, 2017 at 9:55 AM, Anil Vishnoi <[email protected]<mailto:[email protected]>> wrote: Hi Thomas, Can you please open a bug against openflowplugin project here https://bugs.opendaylight.org/enter_bug.cgi?product=openflowplugin Please upload the wireshark capture (with 50 connection + 200 connection) and karaf log. can you provide the instruction to recreate the issue locally? Also please provide the flow dump from the ovs. Thanks Anil On Wed, May 10, 2017 at 9:13 AM, Luis Gomez <[email protected]<mailto:[email protected]>> wrote: cc-ing openflowplugin too. Begin forwarded message: From: Thomas FERRANDIZ <[email protected]<mailto:[email protected]>> Subject: [openflowjava-dev] ODL disconnects from switch during performance tests Date: May 10, 2017 at 8:36:11 AM PDT To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Hello all, I am currently developing a stateful firewall application for SDN using ODL as the controller. The application uses the TCP flags OpenFlow extension to match the successive states when establishing a connection. This means that a large amount of packets–in is sent to the controller and that in turn the controller adds and deletes many flows from the switches. I use the MD-SAL API to add and remove flows from the switches without going through the datastore. The version of ODL used is Boron-SR3. At the moment, I am writing a POC firewall with only one switch and I run into the following problem. I run a stress test that involves creating TCP connection from a client machine to a server machine (running Apache). The 2 machines are connected by an OVS switch connected to ODL. When the stress test is run with a low number of connections/second (~50) everything works fine. When using ~200 TCP connections/second, the firewall seems to work fine for a few seconds. Then the duration of the TCP connections start to increase and the controller ends up disconnection from the OVS. The following errors appear in the log: 2017-04-07 09:42:34,419 | ERROR | pool-15-thread-1 | OutboundQueueProviderImpl | 192 - org.opendaylight.openflowplugin.impl - 0.3.2.Boron-SR2 | No queue present, failing request And the future returned by salFlowService.addFlow show the following error message: Error: [operation-failed]: Device disconnected The following exception also occurs: org.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.dom.api.DOMRpcImplementationNotAvailableException: No implementation of RPC AbsoluteSchemaPath{path=[(urn:opendaylight:flow:service?revision=2013-08-19)add-flow]} available atorg.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:173)[154:org.opendaylight.controller.sal-broker-impl:1.4.3.Boron-SR3] atorg.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)[154:org.opendaylight.controller.sal-broker-impl:1.4.3.Boron-SR3] at Proxy1d02b267_bf62_4c92_a739_263c328d7038.invokeRpc(Unknown Source)[:] atorg.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.binding.impl.RpcServiceAdapter.invoke0(RpcServiceAdapter.java:65)[156:org.opendaylight.controller.sal-binding-broker-impl:1.4.3.Boron-SR3] atorg.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.binding.impl.RpcServiceAdapter.access$000(RpcServiceAdapter.java:43)[156:org.opendaylight.controller.sal-binding-broker-impl:1.4.3.Boron-SR3] atorg.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.binding.impl.RpcServiceAdapter$RpcInvocationStrategy.invoke(RpcServiceAdapter.java:159)[156:org.opendaylight.controller.sal-binding-broker-impl:1.4.3.Boron-SR3] atorg.opendaylight.controller.md<http://org.opendaylight.controller.md/>.sal.binding.impl.RpcServiceAdapter.invoke(RpcServiceAdapter.java:96)[156:org.opendaylight.controller.sal-binding-broker-impl:1.4.3.Boron-SR3] at com.sun.proxy.$Proxy54.addFlow(Unknown Source)[120:org.opendaylight.openflowplugin.model.flow-service:0.3.3.Boron-SR3] The OVS logs also shows that it’s the controller that breaks the connection. The JVM has 8GB of memory allocated and uses at most 3 so it’s not a memory issue. The machine running ODL has 8 logical cores, of which only one is used. CPU and memory usage is also pretty low on the machine running OVS. So my question would be whether you have an idea of what I could do to solve this issue or a direction in which to investigate? Thanks in advance, Thomas Ferrandiz {P} R&D Engineer Network Architecture & Security <image001.gif><http://www.b-com.com/> 1219 AVENUE CHAMPS BLANCS 35510 CESSON-SÉVIGNÉ (FR) _______________________________________________ openflowjava-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev _______________________________________________ openflowplugin-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev -- Thanks Anil -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
