[OPNFLWPLUG-355] Handshake Exception connecting an open flow switch in mininet Created: 03/Feb/15  Updated: 27/Sep/21  Resolved: 19/Oct/16

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

Type: Bug
Reporter: Brady Johnson Assignee: Michal Rehak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other

External issue ID: 2668
Priority: Normal

 Description   

Hello,

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.

I start mininet like this:

sudo mn --topo single,2 --mac --switch ovsk,protocols=OpenFlow13 --controller remote,ip=192.168.56.101

This is the error I get in the SFC logs:

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
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
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.
2015-02-03 15:35:35,034 | WARN | OFHandshake-0-0 | ErrorHandlerSimpleImpl | 245 - org.opendaylight.openflowplugin - 0.1.0.SNAPSHOT | exception -> FIRST HELLO sending failed because of connection issue., session -> null
org.opendaylight.openflowplugin.ConnectionException: FIRST HELLO sending failed because of connection issue.
at org.opendaylight.openflowplugin.openflow.md.core.HandshakeManagerImpl.sendHelloMessage(HandshakeManagerImpl.java:299)[245:org.opendaylight.openflowplugin:0.1.0.SNAPSHOT]
at org.opendaylight.openflowplugin.openflow.md.core.HandshakeManagerImpl.shake(HandshakeManagerImpl.java:98)[245:org.opendaylight.openflowplugin:0.1.0.SNAPSHOT]
at org.opendaylight.openflowplugin.openflow.md.core.HandshakeStepWrapper.run(HandshakeStepWrapper.java:47)[245:org.opendaylight.openflowplugin:0.1.0.SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)[:1.7.0_09]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)[:1.7.0_09]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_09]

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.

curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin http://localhost:${PORT}/restconf/operational/opendaylight-inventory:nodes/

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.

Brady

 Comments   
Comment by Brady Johnson [ 05/Feb/15 ]

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.

So I'll lower the priority/importance of the Bug.

Brady

Comment by Icaro Camelo [ 05/May/15 ]

Could you please give me more details about what you discovered?

Comment by Michal Rehak [ 06/May/15 ]

Hi,
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.

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.

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.

Anyway there should not be any side effects - all devices should be connected once the reconnection dance finishes.

Comment by Brady Johnson [ 07/May/15 ]

I havent seen this exception in a while, at least 2 weeks now.

Brady

Comment by Michal Rehak [ 02/Jun/15 ]

We have similar issue which manifests through this exception:
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[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at org.opendaylight.openflowplugin.openflow.md.core.ConnectionConductorImpl.onConnectionReady(ConnectionConductorImpl.java:417)
at org.opendaylight.openflowjava.protocol.impl.connection.ConnectionAdapterImpl$3.run(ConnectionAdapterImpl.java:463)
at java.lang.Thread.run(Thread.java:745)

Common reason is talking to device when connection down.

Comment by Michal Rehak [ 02/Jun/15 ]

stable/lithium:
https://git.opendaylight.org/gerrit/21648

Comment by Michal Rehak [ 05/Jun/15 ]

merged

Comment by yunyunhan [ 19/Oct/16 ]

(In reply to michal rehak from comment #7)
> merged

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.

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