Hello,
I have gotten the application to successfully function as a client. I've
attached a patch with a couple of small changes I made to your branch,
Iwase. Also, here is a link to my fork of the repo with those changes. One
of the changes is to not allow Ryu to run as client and server
simultaneously. I am not sure if this is desirable or not so please advise.
https://github.com/MMoskowitz9/ryu/tree/controller-Support_proactive_connection
Thanks,
Matt
On Mon, Oct 9, 2017 at 9:58 AM, Matthew Moskowitz <m...@bestateless.com>
wrote:
> Fortunately I have an update on the issue from above. The class
> OFPFeaturesRequest(MsgBase): appears to be missing the @_register_parser
> decorator. I can push a patch for this but I will continue testing the code
> today.
>
> On Sun, Oct 8, 2017 at 3:50 PM, Matthew Moskowitz <m...@bestateless.com>
> wrote:
>
>> Hi Iwase,
>>
>> I am currently trying to figure out an issue in the new code. When I use
>> the --ofp-switch-address-list flag, it goes into the ofproto_v1_5_parser.py
>> file shortly after launch. The msg_parser function receives a message with
>> msg_type of 5, however as you can see below message type 5 is not loaded
>> into the contents of the _MSG_PARSERS dictionary (contents of dict printed
>> below). I am not sure if this is an issue with my environment or the new
>> code.
>>
>>
>>
>> {0: <bound method OFPHello.parser of <class 'ryu.ofproto.ofproto_v1_5_pars
>> er.OFPHello'>>,
>> 1: <bound method OFPErrorMsg.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPErrorMsg'>>,
>> 2: <bound method OFPEchoRequest.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPEchoRequest'>>,
>> 3: <bound method OFPEchoReply.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPEchoReply'>>,
>> 4: <bound method OFPExperimenter.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPExperimenter'>>,
>> 6: <bound method OFPSwitchFeatures.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPSwitchFeatures'>>,
>> 8: <bound method OFPGetConfigReply.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPGetConfigReply'>>,
>> 10: <bound method OFPPacketIn.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPPacketIn'>>,
>> 11: <bound method OFPFlowRemoved.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPFlowRemoved'>>,
>> 12: <bound method OFPPortStatus.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPPortStatus'>>,
>> 14: <bound method OFPFlowMod.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPFlowMod'>>,
>> 15: <bound method OFPGroupMod.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPGroupMod'>>,
>> 19: <bound method OFPMultipartReply.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPMultipartReply'>>,
>> 21: <bound method MsgBase.parser of <class 'ryu.ofproto.ofproto_v1_5_pars
>> er.OFPBarrierReply'>>,
>> 25: <bound method OFPRoleReply.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPRoleReply'>>,
>> 27: <bound method OFPGetAsyncReply.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPGetAsyncReply'>>,
>> 29: <bound method OFPMeterMod.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPMeterMod'>>,
>> 30: <bound method OFPRoleStatus.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPRoleStatus'>>,
>> 31: <bound method OFPTableStatus.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPTableStatus'>>,
>> 32: <bound method OFPRequestForward.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPRequestForward'>>,
>> 33: <bound method OFPBundleCtrlMsg.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPBundleCtrlMsg'>>,
>> 35: <bound method OFPControllerStatus.parser of <class
>> 'ryu.ofproto.ofproto_v1_5_parser.OFPControllerStatus'>>}
>>
>>
>> On Fri, Oct 6, 2017 at 9:32 AM, Matthew Moskowitz <m...@bestateless.com>
>> wrote:
>>
>>> Hi Iwase,
>>>
>>> Great, I will test this out today.
>>>
>>> On Thu, Oct 5, 2017 at 7:43 PM, Iwase Yusuke <iwase.yusu...@gmail.com>
>>> wrote:
>>>
>>>> Hi Matt,
>>>>
>>>> I've posted patches to support this feature. Could you try it?
>>>> [Ryu-devel] [PATCH 1/3] controller: Support proactive connection
>>>>
>>>> Note: Currently, Ryu does not aware of whether connections is reactive
>>>> or proactive,
>>>> so it is not recommended to use them simultaneously against the same
>>>> switch.
>>>> The connection might be duplicated.
>>>>
>>>> Thanks,
>>>> Iwase
>>>>
>>>>
>>>> On 2017年10月06日 07:24, Matthew Moskowitz wrote:
>>>>
>>>>> Awesome! I look forward to trying it out.
>>>>>
>>>>> On Thu, Oct 5, 2017 at 12:34 AM, Iwase Yusuke <iwase.yusu...@gmail.com
>>>>> <mailto:iwase.yusu...@gmail.com>> wrote:
>>>>>
>>>>> Hi Matt,
>>>>>
>>>>> Currently, I'm testing this feature on my branch.
>>>>> (Still this have some buggy behaviors though...)
>>>>> https://github.com/iwaseyusuke/ryu/tree/controller-Support_p
>>>>> roactive_connection
>>>>> <https://github.com/iwaseyusuke/ryu/tree/controller-Support_
>>>>> proactive_connection>
>>>>>
>>>>> But, the amount of task should not differ so much from this
>>>>> branch, I guess.
>>>>>
>>>>> Thanks,
>>>>> Iwase
>>>>>
>>>>>
>>>>> On 2017年10月05日 15:16, Matthew Moskowitz wrote:
>>>>>
>>>>> Thank you for the advice on the failover Iwase.
>>>>>
>>>>> As far as having Ryu behave as the client, do you have any
>>>>> insight into how large of a task
>>>>> this would be?
>>>>>
>>>>> Matt
>>>>>
>>>>> On Tue, Oct 3, 2017 at 8:58 PM, Iwase Yusuke <
>>>>> iwase.yusu...@gmail.com
>>>>> <mailto:iwase.yusu...@gmail.com> <mailto:
>>>>> iwase.yusu...@gmail.com
>>>>> <mailto:iwase.yusu...@gmail.com>>> wrote:
>>>>>
>>>>> Hi Matt,
>>>>>
>>>>> Thank you for sharing use-cases.
>>>>>
>>>>> For the latter case, I guess it should take some lags to
>>>>> change controllers addresses
>>>>> on switches
>>>>> to do efficiently failover.
>>>>> Might have still some lags, but how about using virtual
>>>>> IPs on controller side (like
>>>>> clustering
>>>>> controller)?
>>>>> I should be smaller lags than changing addresses on
>>>>> switch side.
>>>>>
>>>>> Thanks,
>>>>> Iwase
>>>>>
>>>>>
>>>>> On 2017年10月04日 10:56, Matthew Moskowitz wrote:
>>>>>
>>>>> Thanks Iwase and Carlos for your thoughts,
>>>>>
>>>>> 2 cases that this feature is interesting to me for
>>>>> would be:
>>>>>
>>>>> Integrating Ryu with other software that is already
>>>>> running a different
>>>>> webserver/asynchronous library. Nicer in this case
>>>>> not to have to deal with 2 different
>>>>> webservers/coroutine types.
>>>>>
>>>>> Efficient failover if one Ryu application should fail
>>>>> for any reason, the new one can
>>>>> instantly connect to the switch. Your suggestion to
>>>>> use the ovsdb library could
>>>>> help with
>>>>> this one.
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>>> On Tue, Oct 3, 2017 at 7:20 PM, Iwase Yusuke <
>>>>> iwase.yusu...@gmail.com
>>>>> <mailto:iwase.yusu...@gmail.com>
>>>>> <mailto:iwase.yusu...@gmail.com <mailto:
>>>>> iwase.yusu...@gmail.com>>
>>>>> <mailto:iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.co
>>>>> m>
>>>>>
>>>>> <mailto:iwase.yusu...@gmail.com <mailto:
>>>>> iwase.yusu...@gmail.com>>>> wrote:
>>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> Thank you for your reply!
>>>>>
>>>>> As you said, the OpenFlow Spec does not restrict
>>>>> Switches must initiate
>>>>> connection to
>>>>> Controllers.
>>>>> But initiating connection by Controllers seems
>>>>> to be the "optional" feature.
>>>>> ===
>>>>> Quote: OpenFlow Spec 1.3.5 "6.3.3 Connection
>>>>> Setup"
>>>>> ===
>>>>> Optionally, the switch may allow the controller
>>>>> to initiate the connection. In
>>>>> this
>>>>> case, the
>>>>> switch should
>>>>> accept incoming standard TLS or TCP connections
>>>>> from the controller, using
>>>>> either a
>>>>> user-specified
>>>>> transport port or the default OpenFlow transport
>>>>> port 6653. Connections
>>>>> initiated by
>>>>> the switch and
>>>>> the controller behave the same once the
>>>>> transport connection is established.
>>>>> ===
>>>>>
>>>>> If OVS does not know on where Ryu is listening
>>>>> when OVS starting up, how about
>>>>> using
>>>>> OVSDB library
>>>>> to tell controller's IP:Port to OVS?
>>>>> If OVS listening on OVSDB connection,
>>>>> "set-controller" API can tell its own
>>>>> address to OVS.
>>>>> https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc76
>>>>> ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128
>>>>> <https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc7
>>>>> 6ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128>
>>>>> <https://github.com/osrg/ryu/b
>>>>> lob/6e69e9b8a6ebd2bb06aa864cc76ef0b79d1ac9c3/ryu/lib/ovs/bri
>>>>> dge.py#L128
>>>>> <https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc7
>>>>> 6ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128>>
>>>>> <https://github.com/osrg/ryu/b
>>>>> lob/6e69e9b8a6ebd2bb06aa864cc76ef0b79d1ac9c3/ryu/lib/ovs/bri
>>>>> dge.py#L128
>>>>> <https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc7
>>>>> 6ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128>
>>>>> <https://github.com/osrg/ryu/b
>>>>> lob/6e69e9b8a6ebd2bb06aa864cc76ef0b79d1ac9c3/ryu/lib/ovs/bri
>>>>> dge.py#L128
>>>>> <https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc7
>>>>> 6ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128>>>
>>>>>
>>>>> And apart from that, initiating connection by
>>>>> Controllers looks interesting
>>>>> feature for me.
>>>>>
>>>>> Thanks,
>>>>> Iwase
>>>>>
>>>>>
>>>>>
>>>>> On 2017年10月04日 08:57, Carlos Ferreira wrote:
>>>>>
>>>>> This is just a question, not a critic.
>>>>> Doesn't the OpenFlow standard stipulates
>>>>> that it is the Switch that
>>>>> must connect to a Controller, and not the
>>>>> other way around?
>>>>>
>>>>> Carlos Ferreira
>>>>>
>>>>> On 4 October 2017 at 00:42, Iwase Yusuke <
>>>>> iwase.yusu...@gmail.com
>>>>> <mailto:iwase.yusu...@gmail.com>
>>>>> <mailto:iwase.yusu...@gmail.com <mailto:
>>>>> iwase.yusu...@gmail.com>>
>>>>> <mailto:iwase.yusu...@gmail.com <mailto:
>>>>> iwase.yusu...@gmail.com>
>>>>> <mailto:iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.co
>>>>> m>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Matt,
>>>>>
>>>>> As far as I know, Ryu does not provide
>>>>> such feature (only do wait incoming
>>>>> connection
>>>>> like server).
>>>>> Would you share us if you have any
>>>>> use-case or situation where Ryu
>>>>> must act as
>>>>> a client?
>>>>> If there are useful use-cases, better to
>>>>> implement it, I guess!
>>>>>
>>>>> Thanks,
>>>>> Iwase
>>>>>
>>>>>
>>>>>
>>>>> On 2017年10月04日 07:16, Matthew Moskowitz
>>>>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> By default when a Ryu application is
>>>>> started, it is listening for
>>>>> a connection
>>>>> request that comes from the switch.
>>>>> (For instance, using ovs, you
>>>>> would run
>>>>> ovs-vsctl set-controller to tell it
>>>>> where to talk to the Ryu
>>>>> application).
>>>>> However,
>>>>> OpenvSwitch can also behave like a
>>>>> server and wait for a request
>>>>> from an
>>>>> openflow
>>>>> controller.
>>>>>
>>>>> Is there an existing setting that
>>>>> allows a Ryu application act as
>>>>> a client
>>>>> such that
>>>>> the Ryu app will make the initial
>>>>> request to connect with the
>>>>> openflow switch?
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>>>
>>>>> -----------------------------
>>>>> -------------------------------------------------
>>>>> Check out the vibrant tech community
>>>>> on one of the world's most
>>>>> engaging tech sites, Slashdot.org!
>>>>> http://sdm.link/slashdot
>>>>>
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.source
>>>>> forge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>>
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>>
>>>>>
>>>>>
>>>>> -----------------------------
>>>>> -------------------------------------------------
>>>>> Check out the vibrant tech community on
>>>>> one of the world's most
>>>>> engaging tech sites, Slashdot.org!
>>>>> http://sdm.link/slashdot
>>>>> ______________________________
>>>>> _________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.source
>>>>> forge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>>
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> ------------------------------------------------
>>>>> Check out the vibrant tech community on one
>>>>> of the world's most
>>>>> engaging tech sites, Slashdot.org!
>>>>> http://sdm.link/slashdot
>>>>> ______________________________
>>>>> _________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.source
>>>>> forge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>>
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> ------------------------------------------------
>>>>> Check out the vibrant tech community on one of the
>>>>> world's most
>>>>> engaging tech sites, Slashdot.org!
>>>>> http://sdm.link/slashdot
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.source
>>>>> forge.net>
>>>>> <mailto:Ryu-devel@lists.sourceforge.net <mailto:
>>>>> Ryu-devel@lists.sourceforge.net>>
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>> <https://lists.sourceforge.net
>>>>> /lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.source
>>>>> forge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/ryu-devel>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>>
>>>>>
>>>
>>
>
From 902362a55b65dd5ae23ee27a89e9ddc45d4da0f8 Mon Sep 17 00:00:00 2001
From: Matt Moskowitz <m...@bestateless.com>
Date: Mon, 9 Oct 2017 17:06:14 -0600
Subject: [PATCH 5/5] add decorator, don't run as client and server together
Signed-off-by: Matt Moskowitz <m...@bestateless.com>
---
ryu/controller/controller.py | 3 +++
ryu/ofproto/ofproto_v1_5_parser.py | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/ryu/controller/controller.py b/ryu/controller/controller.py
index 2de14a75..14e45ee8 100644
--- a/ryu/controller/controller.py
+++ b/ryu/controller/controller.py
@@ -146,6 +146,9 @@ class OpenFlowController(object):
addr = tuple(_split_addr(address))
self.spawn_client_loop(addr)
+ # Don't spawn a server loop is Ryu has been run as a client
+ if self._clients != {}:
+ return
self.server_loop(self.ofp_tcp_listen_port,
self.ofp_ssl_listen_port)
diff --git a/ryu/ofproto/ofproto_v1_5_parser.py b/ryu/ofproto/ofproto_v1_5_parser.py
index b61e6fef..eaa8519c 100644
--- a/ryu/ofproto/ofproto_v1_5_parser.py
+++ b/ryu/ofproto/ofproto_v1_5_parser.py
@@ -361,7 +361,7 @@ class OFPEchoReply(MsgBase):
assert self.data is not None
self.buf += self.data
-
+@_register_parser
@_set_msg_type(ofproto.OFPT_FEATURES_REQUEST)
class OFPFeaturesRequest(MsgBase):
"""
--
2.11.0
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
