https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-355 OpenFlowPlugin <p>Hello,</p> <p>Im using the openflowplugin version 0.1.0-SNAPSHOT in the SFC ODL project, and see a strange exception and error when an open flow switch started in mininet tries to connect.</p> <p>I start mininet like this:</p> <p>sudo mn --topo single,2 --mac --switch ovsk,protocols=OpenFlow13 --controller remote,ip=192.168.56.101</p> <p>This is the error I get in the SFC logs:</p> <p>2015-02-03 15:35:33,030 | WARN | entLoopGroup-6-1 | SessionManagerOFImpl | 245 - org.opendaylight.openflowplugin - 0.1.0.SNAPSHOT | context for invalidation not found<br/> 2015-02-03 15:35:33,405 | INFO | entLoopGroup-6-2 | ConnectionAdapterImpl | 243 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.6.0.SNAPSHOT | Hello received / branch<br/> 2015-02-03 15:35:34,032 | INFO | OFHandshake-0-0 | ConnectionConductorImpl | 245 - org.opendaylight.openflowplugin - 0.1.0.SNAPSHOT | OF handshake failed, doing cleanup.<br/> 2015-02-03 15:35:35,034 | WARN | OFHandshake-0-0 | ErrorHandlerSimpleImpl | 245 - org.opendaylight.openflowplugin - 0.1.0.SNAPSHOT | exception -&gt; FIRST HELLO sending failed because of connection issue., session -&gt; null<br/> org.opendaylight.openflowplugin.ConnectionException: FIRST HELLO sending failed because of connection issue.<br/> at org.opendaylight.openflowplugin.openflow.md.core.HandshakeManagerImpl.sendHelloMessage(HandshakeManagerImpl.java:299)<span class="error">&#91;245:org.opendaylight.openflowplugin:0.1.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.openflowplugin.openflow.md.core.HandshakeManagerImpl.shake(HandshakeManagerImpl.java:98)<span class="error">&#91;245:org.opendaylight.openflowplugin:0.1.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.openflowplugin.openflow.md.core.HandshakeStepWrapper.run(HandshakeStepWrapper.java:47)<span class="error">&#91;245:org.opendaylight.openflowplugin:0.1.0.SNAPSHOT&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)<span class="error">&#91;:1.7.0_09&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)<span class="error">&#91;:1.7.0_09&#93;</span><br/> at java.lang.Thread.run(Thread.java:722)<span class="error">&#91;:1.7.0_09&#93;</span></p> <p>When I send this REST message with curl, I get a (huge) response, so it appears that it connects, but when I try to program flows, nothing appears in the switch.</p> <p>curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin <a href="http://localhost:$" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:$</a>{PORT}/restconf/operational/opendaylight-inventory:nodes/</p> <p>The HW Im using is the Ubuntu VM provided by ODL running in VirtualBox, where I execute mininet, and SFC running in a separate Ubuntu 14.04 VirtualBox VM.</p> <p>Brady</p> <p>Operating System: Linux<br/> Platform: Other</p> OPNFLWPLUG-355

Handshake Exception connecting an open flow switch in mininet

Bug Resolved Done Michal Rehak Brady Johnson Tue, 3 Feb 2015 18:36:12 +0000 Mon, 27 Sep 2021 09:01:25 +0000 Wed, 19 Oct 2016 02:33:53 +0000 General 0 3 <p>I figured out why the flows were not being sent to the Open Flow switch, and it had nothing to do with the handshaking exception.</p> <p>So I'll lower the priority/importance of the Bug.</p> <p>Brady</p> <p>Could you please give me more details about what you discovered?</p> <p>Hi,<br/> the disconnection occurs pretty often. According to my observations we have tcp packet with reset flag at the beginning of connection. It is sent by switch. And almost every time it occurs right after first helloMessage sent from controller to switch. </p> <p>So if there is topology of 3 nodes then only the first node disconnects and reconnects immediately. Consequence of this is that there is new socket opened and new handshake process started. And of course the old handshake process must be stopped and cleaned and here the exception is raised.</p> <p>I am not sure why do we have this behavior - It occurs by floodlight controller too. I guess that the first hello message from controller is sent prematurely when the socket is not ready on switch side.. But so requires the OF-specification - to send helloMessage upon connection established.</p> <p>Anyway there should not be any side effects - all devices should be connected once the reconnection dance finishes.</p> <p>I havent seen this exception in a while, at least 2 weeks now.</p> <p>Brady</p> <p>We have similar issue which manifests through this exception:<br/> Exception in thread "Thread-105" java.util.concurrent.RejectedExecutionException: Task org.opendaylight.openflowplugin.openflow.md.core.HandshakeStepWrapper@60ee157a rejected from org.opendaylight.openflowplugin.openflow.md.core.ThreadPoolLoggingExecutor@2ec42e4d<span class="error">&#91;Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)<br/> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)<br/> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)<br/> at org.opendaylight.openflowplugin.openflow.md.core.ConnectionConductorImpl.onConnectionReady(ConnectionConductorImpl.java:417)<br/> at org.opendaylight.openflowjava.protocol.impl.connection.ConnectionAdapterImpl$3.run(ConnectionAdapterImpl.java:463)<br/> at java.lang.Thread.run(Thread.java:745)</p> <p>Common reason is talking to device when connection down.</p> <p>stable/lithium:<br/> <a href="https://git.opendaylight.org/gerrit/21648" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/21648</a></p> <p>merged</p> <p>(In reply to michal rehak from comment #7)<br/> &gt; merged</p> <p>I think that this modification only reduces the probability of RejectedExecutionException, but does not solve the fundamental problem.Firstly, RejectedExecutionException still appeared when I used redist/beryllium-sr3 version. Secondly, this modification would lead to new IllegalStateException.</p> Development External issue ID 2668 External issue URL Priority Rank 0|i030n3: