|
回复： [openflowplugin-dev] [All channel inactive]Switch concurrencyconnect to odl and all others switch disconnected problem
"陈卓文
Hi Luis Gomez: Thanks for your remind. You are right. After setting OVS inactivity_probe parameter to 0, the problem relief. This is not openflowjava or openflowplugin bug. ------------------ 原始邮件 ------------------ 发件人: "Luis Gomez"<ecelgp@...>; 发送时间: 2018年8月1日(星期三) 凌晨2:51 收件人: "陈卓文"<chenzhuowen.simon@...>; 抄送: "openflowjava-dev"<openflowjava-dev@...>; "openflowplugin-dev"<openflowplugin-dev@...>; 主题: Re: [openflowplugin-dev] [All channel inactive]Switch concurrencyconnect to odl and all others switch disconnected problem > On Jul 30, 2018, at 6:42 AM, 陈卓文 <chenzhuowen.simon@...> wrote: > > 2018-07-24T20:55:00,333 | INFO | epollEventLoopGroup-9-42 | SystemNotificationsListenerImpl | 326 - org.opendaylight.openflowplugin.impl - 0.6.2.netease1 | ConnectionEvent: Connection closed by device, Device:/xxxx:35922, NodeId:openflow:xxx |
|
|
|
Re: [openflowplugin-dev] [All channel inactive]Switch concurrency connect to odl and all others switch disconnected problem
Luis Gomez <ecelgp@...>
The message below indicates the switch disconnects, since this is OVS, can you check in the OVS log (e.g. ovs-vswitchd.log) the reason for the disconnect? If the reason is timeout receiving echo response from controller, this means controller is too busy to respond to switch echos in which case switch disconnects and reconnects back making things worse. If that is the problem can you try the same scenario after setting the OVS inactivity_probe parameter to 0?
toggle quoted message
Show quoted text
On Jul 30, 2018, at 6:42 AM, 陈卓文 <chenzhuowen.simon@...> wrote: |
|
|
|
[All channel inactive]Switch concurrency connect to odl and all others switch disconnected problem
"陈卓文
Hi Openflowjava/Openflowplugin Developer: I meet a concurrency problem in odl openflowplugin. I create ovs as switch using script and it connected to my controller one by one: ```python for ovs_id in range (OVS_START_NUM,OVS_NUM): subprocess.call('ovs-vsctl add-br bridge%d' % ovs_id, shell=True) subprocess.call('ovs-vsctl set-controller bridge%d tcp:%s:6633' % ovs_id, controller, shell=True) ``` And I can see: all connected switch disconnected in a time suddenly. I can see the log: ``` 2018-07-24T20:55:00,333 | INFO | epollEventLoopGroup-9-42 | SystemNotificationsListenerImpl | 326 - org.opendaylight.openflowplugin.impl - 0.6.2.netease1 | ConnectionEvent: Connection closed by device, Device:/xxxx:35922, NodeId:openflow:xxx ``` I find the openflowjava code in `DelegatingInboundHandler.java`，it mean "the channel between controller and switch inactive." ``` @Override public void channelInactive(final ChannelHandlerContext ctx) { LOG.debug("Channel inactive"); if (!inactiveMessageSent) { DisconnectEventBuilder builder = new DisconnectEventBuilder(); builder.setInfo("Channel inactive"); consumer.consume(builder.build()); inactiveMessageSent = true; } } ``` But I am very sure all switch and controller network link no problem. I had test many time, this issue will happen again. And I found the special log: ``` 2018-07-27T19:07:37,499 | WARN | opendaylight-cluster-data-akka.actor.default-dispatcher-28 | ContextChainImpl | 326 - org.opendaylight.openflowplugin.impl - 0.6.2.netease1 | Not able to start clustering services for node openflow:86750152275523
2018-07-27T19:07:37,500 | WARN | ofppool-358 | ContextChainHolderImpl | 326 - org.opendaylight.openflowplugin.impl | Not able to set MASTER role on device openflow:86750152275523, reason: java.lang.RuntimeException: Failed to initialize device openflow:86750152275523 in 9s: java.util.concurrent.TimeoutException: Waited 9000 milliseconds for com.google.common.util.concurrent.AbstractTransformFuture$AsyncTransformFuture@7ae82a2[status=PENDING] ``` Before this log, the controller everything well. And After this log, I can see many `Connection closed by device` log. This log show concurrent timeout and thread status PENDING. I find the Exception code in `DeviceContextImpl.java`： ``` final Future<Void> initialize = initializer .get() .initialize(this, switchFeaturesMandatory, skipTableFeatures, writerProvider, convertorExecutor); try { initialize.get(DEVICE_INIT_TIMEOUT, TimeUnit.MILLISECONDS); } catch (TimeoutException ex) { initialize.cancel(true); throw new RuntimeException(String.format("Failed to initialize device %s in %ss: %s", deviceInfo.toString(), String.valueOf(DEVICE_INIT_TIMEOUT / 1000), ex.toString()), ex); } catch (ExecutionException | InterruptedException ex) { throw new RuntimeException( String.format("Device %s cannot be initialized: %s", deviceInfo.toString(), ex.toString()), ex); } ``` The device initialize process for get OFPMPDESC/OFPMPMETERFEATURES/OFPMPGROUPFEATURES... from switch. And it request isn't exceute by channel's Eventloop? I think this is a concurrency problem in openflowplugin / openflowjava / netty ? For more, I alse test switch connect to 6633 and 6653 port in same controller. And I saw when all switch disconnect in 6633 port, but all switch connect to 6653 port no problem. I know 6653 and 6633 port is different netty EventLoopGroup. Is a channel in one EventLoopGroup(6633), it device initialize failed and make all EventLoopGroup channel inactive? And another EventLoopGroup(6653) isn't affected. I had read openflowjava and openflowplugin code very detail, but i cannot find the problem in source code. Is it a concurrency bug in ofp using netty way? or something others? Hope get your help. Thanks. ----------- SimonCZW |
|
|
|
Eclipse Opendaylight
Faisal amin <faisalamin32@...>
Hi All, I am trying to import Opendaylight source to eclipse.I have tried to import code from the git root directory but there were a lot of errors. I have followed some video tutorial on youtube to import the code but nothing worked out. I Have followed the link bellow for Eclipse: https://github.com/vorburger/o Does anyone provide me some suggestion to import the code successfully to eclipse? Regards Faisal Amin |
|
|
|
[Openflow] TLS - No cipher suites in common issue
A Vamsikrishna
Hi All,
I am using java1.8 & following below wiki :
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:_TLS_Support
Does below commands from above wiki make use of RSA as a default algorithm ?
sudo ovs-pki req+sign sc switch sudo ovs-pki req+sign ctl controller
Is it causing the problem ?
And I using below cipher which is based on ECDSA :
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
If yes, how to create certificates that makes use of ECDSA algorithm ?
Thanks, Vamsi
From: A Vamsikrishna
Sent: Monday, December 18, 2017 4:05 PM To: 'openflowjava-dev@...' <openflowjava-dev@...> Subject: [Openflow] TLS cipher suite cannot support exception
Hi All,
All below scenarios looks fine
with no ciphers (or) <cipher-suites>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</cipher-suites> (or) <cipher-suites>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</cipher-suites> <cipher-suites>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</cipher-suites (or) <cipher-suites>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</cipher-suites> <cipher-suites>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</cipher-suites>
stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$ sudo tail -5 /var/log/openvswitch/ovs-vswitchd.log 2017-11-21T15:17:16.417Z|02158|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Connection refused) 2017-11-21T15:17:24.437Z|02159|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Connection refused) 2017-11-21T15:17:32.383Z|02160|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Connection refused) 2017-11-21T15:17:40.915Z|02161|rconn|INFO|br-int<->ssl:192.168.56.1:6653: connected 2017-11-21T15:17:54.279Z|02162|connmgr|INFO|br-int<->ssl:192.168.56.1:6653: 38 flow_mods 10 s ago (38 adds) stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$
stack@devcontrol:~/devstack$ sudo ovs-vsctl show 9191393d-55e3-49c8-82e0-ea597b611ec0 Manager "tcp:192.168.56.1:6640" is_connected: true Bridge br-int Controller "ssl:192.168.56.1:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Bridge br-ext Port br-ext Interface br-ext type: internal ovs_version: "2.6.1" stack@devcontrol:~/devstack$
only with below cipher suite alone it's not working
<cipher-suites>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</cipher-suites>
stack@devcontrol:~/devstack$ sudo tail -5 /var/log/openvswitch/ovs-vswitchd.log 2017-11-21T15:10:28.370Z|02089|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Protocol error) 2017-11-21T15:10:36.343Z|02090|stream_ssl|WARN|SSL_connect: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 2017-11-21T15:10:36.344Z|02091|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Protocol error) 2017-11-21T15:10:44.343Z|02092|stream_ssl|WARN|SSL_connect: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 2017-11-21T15:10:44.343Z|02093|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Protocol error) stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$ sudo ovs-vsctl show 9191393d-55e3-49c8-82e0-ea597b611ec0 Manager "tcp:192.168.56.1:6640" is_connected: true Bridge br-int Controller "ssl:192.168.56.1:6653" fail_mode: secure Port br-int Interface br-int type: internal Bridge br-ext Port br-ext
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)[:1.8.0_131] at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)[:1.8.0_131] at io.netty.handler.ssl.SslHandler$SslEngineType$2.unwrap(SslHandler.java:223)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1117)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1039)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)[94:io.netty.codec:4.1.8.Final] ... 25 more Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)[:1.8.0_131] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)[:1.8.0_131] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)[:1.8.0_131] at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1045)[:1.8.0_131] at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:741)[:1.8.0_131] at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:224)[:1.8.0_131] at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)[:1.8.0_131] at sun.security.ssl.Handshaker$1.run(Handshaker.java:966)[:1.8.0_131] at sun.security.ssl.Handshaker$1.run(Handshaker.java:963)[:1.8.0_131] at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_131] at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416)[:1.8.0_131] at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1256)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1169)[97:io.netty.handler:4.1.8.Final] ... 27 more
Any thoughts on this ?
Thanks, Vamsi
From: A Vamsikrishna
Hi All,
I am working on OFJ to allow users to configure cipher-suites to use with
SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).
I am trying to test it by configuring the cipher suites supported by
SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
).
However, I see an IllegalArgumentException exception indicating that the
cipher suite is not supported.
Can you please help me with this issue ?
Here is the stacktrace -->
2016-02-23 12:16:34,802 | WARN | entLoopGroup-9-2 | TcpChannelInitializer
| 262 - org.opendaylight.openflowjava.openflow-protocol-impl -
0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at
sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at
sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at
org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at
org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at
io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
I have tried to update the JCE policy files to include jars that provide unlimited
cryptographic strength:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
But it did not work out even after my ODL restart (System:shutdown)
Any thoughts ?
Thanks, Vamsi
|
|
|
|
[Openflow] TLS cipher suite cannot support exception
A Vamsikrishna
Hi All,
All below scenarios looks fine
with no ciphers (or) <cipher-suites>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</cipher-suites> (or) <cipher-suites>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</cipher-suites> <cipher-suites>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</cipher-suites (or) <cipher-suites>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</cipher-suites> <cipher-suites>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</cipher-suites>
stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$ sudo tail -5 /var/log/openvswitch/ovs-vswitchd.log 2017-11-21T15:17:16.417Z|02158|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Connection refused) 2017-11-21T15:17:24.437Z|02159|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Connection refused) 2017-11-21T15:17:32.383Z|02160|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Connection refused) 2017-11-21T15:17:40.915Z|02161|rconn|INFO|br-int<->ssl:192.168.56.1:6653: connected 2017-11-21T15:17:54.279Z|02162|connmgr|INFO|br-int<->ssl:192.168.56.1:6653: 38 flow_mods 10 s ago (38 adds) stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$
stack@devcontrol:~/devstack$ sudo ovs-vsctl show 9191393d-55e3-49c8-82e0-ea597b611ec0 Manager "tcp:192.168.56.1:6640" is_connected: true Bridge br-int Controller "ssl:192.168.56.1:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Bridge br-ext Port br-ext Interface br-ext type: internal ovs_version: "2.6.1" stack@devcontrol:~/devstack$
only with below cipher suite alone it's not working
<cipher-suites>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</cipher-suites>
stack@devcontrol:~/devstack$ sudo tail -5 /var/log/openvswitch/ovs-vswitchd.log 2017-11-21T15:10:28.370Z|02089|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Protocol error) 2017-11-21T15:10:36.343Z|02090|stream_ssl|WARN|SSL_connect: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 2017-11-21T15:10:36.344Z|02091|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Protocol error) 2017-11-21T15:10:44.343Z|02092|stream_ssl|WARN|SSL_connect: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 2017-11-21T15:10:44.343Z|02093|rconn|WARN|br-int<->ssl:192.168.56.1:6653: connection dropped (Protocol error) stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$ stack@devcontrol:~/devstack$ sudo ovs-vsctl show 9191393d-55e3-49c8-82e0-ea597b611ec0 Manager "tcp:192.168.56.1:6640" is_connected: true Bridge br-int Controller "ssl:192.168.56.1:6653" fail_mode: secure Port br-int Interface br-int type: internal Bridge br-ext Port br-ext
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)[:1.8.0_131] at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)[:1.8.0_131] at io.netty.handler.ssl.SslHandler$SslEngineType$2.unwrap(SslHandler.java:223)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1117)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1039)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)[94:io.netty.codec:4.1.8.Final] ... 25 more Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)[:1.8.0_131] at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)[:1.8.0_131] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)[:1.8.0_131] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)[:1.8.0_131] at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1045)[:1.8.0_131] at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:741)[:1.8.0_131] at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:224)[:1.8.0_131] at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)[:1.8.0_131] at sun.security.ssl.Handshaker$1.run(Handshaker.java:966)[:1.8.0_131] at sun.security.ssl.Handshaker$1.run(Handshaker.java:963)[:1.8.0_131] at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_131] at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416)[:1.8.0_131] at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1256)[97:io.netty.handler:4.1.8.Final] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1169)[97:io.netty.handler:4.1.8.Final] ... 27 more
Any thoughts on this ?
Thanks, Vamsi
From: A Vamsikrishna
Sent: Thursday, December 14, 2017 7:21 PM To: 'openflowjava-dev@...' <openflowjava-dev@...> Subject: [Openflow] TLS cipher suite cannot support exception
Hi All,
I am working on OFJ to allow users to configure cipher-suites to use with
SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).
I am trying to test it by configuring the cipher suites supported by
SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
).
However, I see an IllegalArgumentException exception indicating that the
cipher suite is not supported.
Can you please help me with this issue ?
Here is the stacktrace -->
2016-02-23 12:16:34,802 | WARN | entLoopGroup-9-2 | TcpChannelInitializer
| 262 - org.opendaylight.openflowjava.openflow-protocol-impl -
0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at
sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at
sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at
org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at
org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at
io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
I have tried to update the JCE policy files to include jars that provide unlimited
cryptographic strength:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
But it did not work out even after my ODL restart (System:shutdown)
Any thoughts ?
Thanks, Vamsi
|
|
|
|
Re: [Openflow] TLS cipher suite cannot support exception
Mohamed ElSerngawy
Hi Vamsikrishna, keep in mind it is mutual communication, what openflow switch u use ? is it ovs bridge ? BR On Thu, Dec 14, 2017 at 8:51 AM, A Vamsikrishna <a.vamsikrishna@...> wrote:
|
|
|
|
[Openflow] TLS cipher suite cannot support exception
A Vamsikrishna
Hi All,
I am working on OFJ to allow users to configure cipher-suites to use with
SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).
I am trying to test it by configuring the cipher suites supported by
SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
).
However, I see an IllegalArgumentException exception indicating that the
cipher suite is not supported.
Can you please help me with this issue ?
Here is the stacktrace -->
2016-02-23 12:16:34,802 | WARN | entLoopGroup-9-2 | TcpChannelInitializer
| 262 - org.opendaylight.openflowjava.openflow-protocol-impl -
0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at
sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at
sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at
org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at
org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at
io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
I have tried to update the JCE policy files to include jars that provide unlimited
cryptographic strength:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
But it did not work out even after my ODL restart (System:shutdown)
Any thoughts ?
Thanks, Vamsi
|
|
|
|
Re: [release] [OpenDaylight TSC] OpenFlow Plugin and OpenFlow Java Library merge status
Abhijit Kumbhare
Great, thanks! On Mon, Jul 31, 2017 at 9:10 AM Thanh Ha <thanh.ha@...> wrote:
|
|
|
|
Re: [release] [OpenDaylight TSC] OpenFlow Plugin and OpenFlow Java Library merge status
Thanh Ha <thanh.ha@...>
On Mon, Jul 31, 2017 at 12:04 PM, Abhijit Kumbhare <abhijitkoss@...> wrote: (Removing infrastructure mailing list, please only use that for actual infra related topics)
I've submitted this patch to remove openflowjava. It will be active in tonight's build. Regards, Thanh |
|
|
|
Re: [OpenDaylight TSC] OpenFlow Plugin and OpenFlow Java Library merge status
Abhijit Kumbhare
Yes - it should be fine to remove OpenFlow Java from Nitrogen Autorelease. On Wed, Jul 26, 2017 at 11:54 PM, Anil Vishnoi <vishnoianil@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] OpenFlow Plugin and OpenFlow Java Library merge status
Anil Vishnoi
Yeah, i think it should be fine, until and unless someone directly consuming the openflowjava libraries ( i am not aware of, atleast in upstream). On Wed, Jul 26, 2017 at 11:31 PM, An Ho <An.Ho@...> wrote:
--
Thanks Anil |
|
|
|
Re: [OpenDaylight TSC] OpenFlow Plugin and OpenFlow Java Library merge status
an.ho@huawei.com
Abhijit, would it be safe to remove OpenFlowJava Project from Nitrogen Autorelease?
Thanh, could you submit a patch to remove openflowjava and hopefully the build completes successfully.
Best Regards, An Ho
From: tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Colin Dixon
Sent: Wednesday, July 26, 2017 6:00 AM To: Abhijit Kumbhare; OpenDaylight Infrastructure; Release; openflowjava-dev; openflowplugin-dev@...; tsc@... Subject: Re: [OpenDaylight TSC] [openflowjava-dev] OpenFlow Plugin and OpenFlow Java Library merge status
Thanks for the update. It sounds like things are going pretty smoothly.
On Thu, Jul 20, 2017 at 8:26 PM Abhijit Kumbhare <abhijitkoss@...> wrote:
|
|
|
|
Re: OpenFlow Plugin and OpenFlow Java Library merge status
Colin Dixon
Thanks for the update. It sounds like things are going pretty smoothly. On Thu, Jul 20, 2017 at 8:26 PM Abhijit Kumbhare <abhijitkoss@...> wrote:
|
|
|
|
OpenFlow Plugin and OpenFlow Java Library merge status
Abhijit Kumbhare
Hi TSC, Infra, Release, OpenFlow Java Library & OpenFlow Plugin, As you probably know OpenFlow Java Library & OpenFlow Plugin projects had decided to merge in Nitrogen. Specifically the OpenFlow Java Library project codebase has been merged into the OpenFlow Plugin project - and the impacts to downstream projects have been resolved. OpenFlow Java committers also voted to archive the project. A termination proposal [5] has been created with a two week notice. More details on the OpenFlow Plugin and OpenFlow Java Library merge from Tomas Slusny & Michal Rehak: What was done: --------------------- * Discussion about merging OpenFlowJava to OpenFlowPlugin was initiated here: [0] * Weather report for merge was created here: [1] * OpenFlowJava latest HEAD ([2]) was merged to OpenFlowPlugin repository master branch (Nitrogen) in this patches: [3] * All references to OpenFlowJava in OpenFlowPlugin was replaced with consumed code, odl-openflowjava-all feature was removed, but odl-openflowjava-protocol remained same * OpenFlowJava project is not going to participate in Nitrogen release as it was consumed by OpenFlowPlugin * Vote [6] on OpenFlow Java Library mailing list to archive the project - with a two week termination notice * A termination proposal [5] for OpenFlow Java Library has been created as per archival process [4]
What needs to be done: -------------------------------- * OpenFlowJava master (Nitrogen) branch needs to be
locked/archived. Tomas will follow up with the infra for this. * Update OpenFlowJava wiki with informations about the merge * Create wiki page for OpenFlowPlugin with informations about the merge and about changes in structure to help contributors that was contributing to both OpenFlowPlugin and OpenFlowJava Please let us know if you need more info. - Abhijit [0] https://lists.opendaylight. [1] https://wiki.opendaylight.org/ [4] https://wiki.opendaylight.org/view/Archive_Proposals
[5] https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Termination_Proposal On Wed, Jun 28, 2017 at 9:14 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
|
|
|
|
Re: What is the syntax for experimenter extension match-field and action in JSON file
Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES@Cisco) <mirehak@...>
Added openflowplugin-dev.
Regards, Michal
From: openflowjava-dev-bounces@... <openflowjava-dev-bounces@...> on behalf of junming <junming_gao@...>
Sent: Friday, July 7, 2017 17:12 To: openflowjava-dev@... Subject: [openflowjava-dev] What is the syntax for experimenter extension match-field and action in JSON file Hi,
I am trying to add some experimenter extension match-fields and actions for openflow protocol. The test method I use is to write JSON file for table addition with curl command for ODL. But I am not sure the syntax for experimenter extension in JSON file.
For example, I have the following standard match fields. And I want to an experimenter match-field named traffic-class. How should I write it in this JSON file?
"match": {
"ethernet-match": {
"ethernet-type": { "type": "2048" },
"ethernet-destination": { "address": "00:01:02:03:04:05" },
"ethernet-source": { "address": "00:00:00:00:00:00" }
},
"vlan-match": {
"vlan-id": {
"vlan-id": "10",
"vlan-id-present": "true"
}
}
BR,
Junming
|
|
|
|
What is the syntax for experimenter extension match-field and action in JSON file
junming
Hi, I am trying to add some experimenter extension match-fields and actions for openflow protocol. The test method I use is to write JSON file for table addition with curl command for ODL. But I am not sure the syntax for experimenter extension in JSON file. For example, I have the following standard match fields. And I want to an experimenter match-field named traffic-class. How should I write it in this JSON file? "match": { "ethernet-match": { "ethernet-type": { "type": "2048" }, "ethernet-destination": { "address": "00:01:02:03:04:05" }, "ethernet-source": { "address": "00:00:00:00:00:00" } }, "vlan-match": { "vlan-id": { "vlan-id": "10", "vlan-id-present": "true" } } BR, Junming
|
|
|
|
Re: [OpenDaylight TSC] termination proposal - openflowjava
Colin Dixon
Thank you for sending this. I'll add it to the agenda for two weeks from today. As an aside, I suspect that openflowjava will have the same problem as tcpmd5 did where the project can't be formally archived until we EoL Carbon which will happen sometime after Oxygen is released. We will need to be able to merge patches into the stable/carbon branch until then. --Colin On Thu, Jun 29, 2017 at 10:36 AM, Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco) <mirehak@...> wrote:
|
|
|
|
termination proposal - openflowjava
Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES@Cisco) <mirehak@...>
Hi all, here is the termination proposal wiki for openflowjava project [1].
Regards, Michal
[1]
https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Termination_Proposal |
|
|
|
Re: [openflowplugin-dev] [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen
Sam Hague
In NetVirt when we pulled in VPN service we did what Robert mentioned. Andy copied the whole vpnservice branch into NetVirt and kept all the history. There were a specific order of commands to use to get it right. From there we adjusted the artifact ids. On Jun 27, 2017 1:44 PM, "Tomáš Slušný" <tomas.slusny@...> wrote:
|
|
|