Re: [Ryu-devel] Facing error while connecting to multiple switches with different OF versions
Hi, > 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the > functionality of the switch? (i have tried OFPportstatus request, and it seems > to work) Hmmm... I think it is depending on the switch implementation. The OpenFlow Spec 1.3.5 says the recipient of OFPT_HELLO message should (must?) terminate the connection when the version is not acceptable, but I don't know how switches are handling them on its internal implementation. See "6.3.3 Connection Setup" of the OpenFlow Spec 1.3.5. > 2)What other things i would be required to handle if i were to manage DP's > with OF version 1.3 and 1.5 concurrently on Ryu 4.xx version Are you trying to migrate from Ryu 3.27 to 4.xx? Well, the APIs of "ryu.ofproto" module should keep the backward compatibility, not so much differences as far as such usage, I guess. IIRC, for the main difference of 3.xx and 4.xx, 4.xx drops Python 2.6 support. > 3)Also if possible i would like to know which fix related to this issue was made onto ryu 3.xx version that is making it not fail in 4.16 version The following two patches are the candidates; https://github.com/osrg/ryu/commit/7b5d6bd24a59f3482c6303400049042a54335ac2 https://github.com/osrg/ryu/commit/6792d6df2a28aac436eb9e2afb1fe07bd30a1831 Thanks, Iwase On 2018年02月14日 02:09, rahul b wrote: Hi, I am using RYU version 3.27 to manage ovs and lagopus. ovs i need to connect on OF 1.5(For support in some specific feature in groups) while lagopus only supports OF 1.3 so, i am declaring my ofp versions as follows OFP_VERSIONS = [ ofproto_v1_3.OFP_VERSION, ofproto_v1_5.OFP_VERSION, ] OVS successfully connects on OF version 1.5, However lagopus is facing some issue while connecting on 1.3 connected socket: address:('192.168.1.4', 44517) hello ev object at 0xb642490c> move onto config mode EVENT ofp_event->Controller EventOFPErrorMsg Error in the datapath None from ('192.168.1.4', 44517) EVENT ofp_event->dpset EventOFPStateChange EVENT ofp_event->Controller EventOFPStateChange EVENT ofp_event->ofctl_service EventOFPStateChange hub: uncaught exception: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ryu/lib/hub.py", line 52, in _launch func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 327, in datapath_connection_factory datapath.serve() File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 247, in serve self._recv_loop() File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 103, in deactivate method(self) File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 189, in _recv_loop handler(ev) File "/usr/lib/python2.7/site-packages/ryu/controller/ofp_handler.py", line 254, in error_msg_handler (version, msg_type, msg_len, xid) = ofproto_parser.header(msg.data) File "/usr/lib/python2.7/site-packages/ryu/ofproto/ofproto_parser.py", line 39, in header assert len(buf) >= ofproto_common.OFP_HEADER_SIZE AssertionError dumping some more info for the above error. DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 length 12 bufsize DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 0x00 0x00 0x00 0x00 EVENT ofp_event->Controller EventOFPErrorMsg version=0x4, msg_type=0x1, msg_len=0xc, xid=0x6ec6a2f2 length 0 bufsize DUMPING BUFF IN HEADER : OFPErrorMsg received: type=0x00 code=0x00 message= Error in the datapath None from ('192.168.1.4', 59995) However in ryu version 4.16 this is what happens.I get a OFPET_HELL_FAILED but i am able to get port info etc after lagopus is connected. connected socket: address:('127.0.0.1', 55388) hello ev move onto config mode EVENT ofp_event->Controller EventOFPErrorMsg EventOFPErrorMsg received. version=0x4, msg_type=0x1, msg_len=0xc, xid=0xfea3027 `-- msg_type: OFPT_ERROR(1) OFPErrorMsg(type=0x0, code=0x0, data=b'') |-- type: OFPET_HELLO_FAILED(0) |-- code: OFPHFC_INCOMPATIBLE(0) `-- data: EVENT ofp_event->dpset EventOFPSwitchFeatures EVENT ofp_event->Controller EventOFPSwitchFeatures EVENT ofp_event->ofctl_service EventOFPSwitchFeatures switch features ev version=0x4,msg_type=0x6,msg_len=0x20,xid=0xfea3028,OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=65535,n_tables=255) OFPErrorMsg received: type=0x00 code=0x00 message= switch feature handle called succefully add dpid 1 datapath new_info old_info None move onto main mode EVENT ofp_event->dpset EventOFPStateChange EVENT ofp_event->Controller EventOFPStateChange DPSET: register datapath register datapath: 0001 **lagopus dp connected It would be really helpful , if you could tell me 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the functionality of the switch? (i have tried OFPportstatus request, and it seems to work) 2)What other things i would be required to handle if i were to manage DP's with OF version 1.3 and
Re: [Ryu-devel] Facing error while connecting to multiple switches with different OF versions
Hi , Thanks for the reply. Yes , i am trying to port from 3.2x to 4.xx version. The patches you pointed are working. Regards, Rahul On Thu, Feb 15, 2018 at 6:31 AM, Iwase Yusukewrote: > Hi, > > > > 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on > the > > functionality of the switch? (i have tried OFPportstatus request, and it > seems > > to work) > > Hmmm... I think it is depending on the switch implementation. > The OpenFlow Spec 1.3.5 says the recipient of OFPT_HELLO message should > (must?) > terminate the connection when the version is not acceptable, but I don't > know > how switches are handling them on its internal implementation. > See "6.3.3 Connection Setup" of the OpenFlow Spec 1.3.5. > > > > 2)What other things i would be required to handle if i were to manage > DP's > > with OF version 1.3 and 1.5 concurrently on Ryu 4.xx version > > Are you trying to migrate from Ryu 3.27 to 4.xx? > Well, the APIs of "ryu.ofproto" module should keep the backward > compatibility, > not so much differences as far as such usage, I guess. > > IIRC, for the main difference of 3.xx and 4.xx, 4.xx drops Python 2.6 > support. > > > > 3)Also if possible i would like to know which fix related to this issue > was > made onto ryu 3.xx version that is making it not fail in 4.16 version > > The following two patches are the candidates; > https://github.com/osrg/ryu/commit/7b5d6bd24a59f3482c6303400 > 049042a54335ac2 > https://github.com/osrg/ryu/commit/6792d6df2a28aac436eb9e2af > b1fe07bd30a1831 > > > Thanks, > Iwase > > > On 2018年02月14日 02:09, rahul b wrote: > >> Hi, >> >> I am using RYU version 3.27 to manage ovs and lagopus. >> >> ovs i need to connect on OF 1.5(For support in some specific feature in >> groups) while lagopus only supports OF 1.3 >> >> so, i am declaring my ofp versions as follows >> >> OFP_VERSIONS = [ >> ofproto_v1_3.OFP_VERSION, >> ofproto_v1_5.OFP_VERSION, >> ] >> >> OVS successfully connects on OF version 1.5, However lagopus is facing >> some issue while connecting on 1.3 >> >> connected socket:> 0xb642644c> address:('192.168.1.4', 44517) hello ev >> move onto >> config mode EVENT ofp_event->Controller EventOFPErrorMsg Error in the >> datapath None from ('192.168.1.4', 44517) EVENT ofp_event->dpset >> EventOFPStateChange EVENT ofp_event->Controller EventOFPStateChange EVENT >> ofp_event->ofctl_service EventOFPStateChange hub: uncaught exception: >> Traceback (most recent call last): File >> "/usr/lib/python2.7/site-packages/ryu/lib/hub.py", >> line 52, in _launch func(*args, **kwargs) File >> "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line >> 327, in datapath_connection_factory datapath.serve() File >> "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line >> 247, in serve self._recv_loop() File "/usr/lib/python2.7/site-packa >> ges/ryu/controller/controller.py", line 103, in deactivate method(self) >> File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", >> line 189, in _recv_loop handler(ev) File "/usr/lib/python2.7/site-packa >> ges/ryu/controller/ofp_handler.py", line 254, in error_msg_handler >> (version, msg_type, msg_len, xid) = ofproto_parser.header(msg.data) File >> "/usr/lib/python2.7/site-packages/ryu/ofproto/ofproto_parser.py", line >> 39, in header assert len(buf) >= ofproto_common.OFP_HEADER_SIZE >> AssertionError >> >> dumping some more info for the above error. >> >> DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 >> length 12 bufsize >> DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 0x00 >> 0x00 0x00 0x00 >> EVENT ofp_event->Controller EventOFPErrorMsg >> version=0x4, msg_type=0x1, msg_len=0xc, xid=0x6ec6a2f2 >> length 0 bufsize >> DUMPING BUFF IN HEADER : >> OFPErrorMsg received: type=0x00 code=0x00 message= >> Error in the datapath None from ('192.168.1.4', 59995) >> >> >> >> However in ryu version 4.16 this is what happens.I get a >> OFPET_HELL_FAILED but i am able to get port info etc after lagopus is >> connected. >> >> connected socket:> 0x7f7a7a865a10> address:('127.0.0.1', 55388) >> hello ev > 0x7f7a7a7fe390> >> move onto config mode >> EVENT ofp_event->Controller EventOFPErrorMsg >> EventOFPErrorMsg received. >> version=0x4, msg_type=0x1, msg_len=0xc, xid=0xfea3027 >> `-- msg_type: OFPT_ERROR(1) >> OFPErrorMsg(type=0x0, code=0x0, data=b'') >> |-- type: OFPET_HELLO_FAILED(0) >> |-- code: OFPHFC_INCOMPATIBLE(0) >> `-- data: >> EVENT ofp_event->dpset EventOFPSwitchFeatures >> EVENT ofp_event->Controller EventOFPSwitchFeatures >> EVENT ofp_event->ofctl_service EventOFPSwitchFeatures >> switch features ev version=0x4,msg_type=0x6,msg_l >> en=0x20,xid=0xfea3028,OFPSwitchFeatures(auxiliary_id=0, >> capabilities=79,datapath_id=1,n_buffers=65535,n_tables=255) >> OFPErrorMsg received: type=0x00 code=0x00 message= >> switch feature handle called succefully >> add dpid 1 datapath > 0x7f7a7a865c90>
[Ryu-devel] Facing error while trying to get the Flow Statistics using the OFPFlowStatsRequest API
Hi, Working on: RYU version:3.27 Ovs version: 27.2 OpenFlow version:1.5. I tried getting the statistics of each flow using the following API: match = ofp_parser .OFPMatch(in_port=1) req = ofp_parser .OFPFlowStatsRequest(datapath,0,1,ofp.OFPP_ANY ,ofp.OFPG_ANY,0,0,match) And i see the following error: EVENT ofp_event->Controller EventOFPErrorMsg EVENT ofp_event->ofctl_service EventOFPErrorMsg EventOFPErrorMsg received. version=0x6, msg_type=0x1, msg_len=0x4c, xid=0x6659cf `-- msg_type: OFPT_ERROR(1) OFPErrorMsg(type=0x1, code=0x2, data=b'\x06\x12\x00\x40\x00\x66\x59\xcf\x00\x11\ x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\ x00\x0c\x80\x00\x00\x04\x00\x00\x00\xc1\x00\x00\x00\x00\x06\x13\x10\xb0\x00\x66\x59\xd0') |-- type: OFPET_BAD_REQUEST(1) |-- code: OFPBRC_BAD_MULTIPART(2) `-- data: version=0x6, msg_type=0x12, msg_len=0x40, xid=0x6659cf `-- msg_type: OFPT_MULTIPART_REQUEST(18) EVENT ofp_event->Controller EventOFPPortStatsReply OFPErrorMsg received: type=0x01 code=0x02 message=0x06 0x12 0x00 0x40 0x00 0x660x59 0xcf 0x00 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x0c 0x80 0x000x00 0x04 0x00 0x00 0x00 0xc1 0x00 0x00 0x00 0x00 0x06 0x13 0x10 0xb0 0x00 0x66 0x59 0xd0 unknown error xid 6707663 i dint see this issue when i was using OpenFlow v1.3. Please let me know if i am missing something, and what can be done to fix this. Thanks, Shivani Dommeti. need to get the statistics (i.e packet_count, byte_count) for each flow. -- 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
Re: [Ryu-devel] How to detect congestion in a network
Hi Reza, How about getting the PortStats periodically? This message contains "rx_dropped", "rx_errors" and so on. http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsReply Thanks, Iwase On 2018年02月09日 18:42, Moh'd Reza Abbasi wrote: I would like to know how can I infer if link or links are congested in a network using Ryu controller? Thank you Reza -- 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 -- 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
Re: [Ryu-devel] ryu freeze when ryu picks up segment packet
Fujimoto-san Sorry for my late reply. > I send the script which we use to debug Ryu packet library. > Could you try this script? If this causes errors, there is something > wrong with Ryu in your environment. > $ python display_pcap.py ryu-ovs-loopback.pcap => I tried this script and confirmed that there is no errors. > * Could you tell me which version of Ryu you are using? => I used ryu 4.20. > * Could you confirm that any traceback was logged by Ryu? => Sorry, I didn’t know what I should check. When ryu picks up segment packet and hung up, no log message is displayed on the terminal. Could you tell me if there are checkpoints concerning ryu behavior? Thank you, hirasawa -- Takayoshi Hirasawa NTT NS Lab. Tel: 0422-59-7294 / Fax: 0422-59-4656 Email: hirasawa.takayo...@lab.ntt.co.jp : takayoshi.hirasawa...@hco.ntt.co.jp -^-^-- > -Original Message- > From: Fujimoto Satoshi [mailto:satoshi.fujimo...@gmail.com] > Sent: Monday, December 04, 2017 4:19 PM > To: cmdcr...@gmail.com; ryu-devel@lists.sourceforge.net > Subject: Re: [Ryu-devel] ryu freeze when ryu picks up segment packet > > Hi, Hirasawa-san > > I've found that it's hard to reproduce your situation. > In my environment, Packet-in including segmented packets did not cause > any problem. > > I send the script which we use to debug Ryu packet library. > Could you try this script? If this causes errors, there is something > wrong with Ryu in your environment. > $ python display_pcap.py ryu-ovs-loopback.pcap > > And... > * Could you tell me which version of Ryu you are using? > * Could you confirm that any traceback was logged by Ryu? > > > Thanks, > Fujimoto > > > On 2017年11月30日 13:49, Takayoshi Hirasawa wrote: > > > Hi, Fujimoto-san > > Thank you for your reply. > > I attached three capture data, interface of VM which onos is running > on, loopback interface of VM which ryu & ryu-ovs is runnning on and > interface of VM which onos-ovs is running on. > > we could confirm onos's request "OFPT_MULTIPART_REQUEST" to onos-ovs > (onos-vm-interface:No.50, ryu-ovs-loopback:No.137, > onosovs-vm-interface:No.61,) but we could not confirm onos-ovs's reply > "OFPT_MULTIPART_REPLY" at onos VM > interface(onosovs-vm-interface:No.62-64, > ryu-ovs-loopback:No.142,143,145,146,148.) Reply-packet seems to be > picked up to ryu as packet-in operation, but ryu seems not to release it. > > this behavior is always observed when ryu pick up the segmented > packet. when i changed mtu of ryu VM's interface, this > behavior was observed too by the other smaller packet than the above > big packet which onos-ovs output. > > (i'm sorry if an environment figure was broken which i wrote in the > previous message. ryu controller is connected to ryu-ovs.) > > Thanks > hirasawa > > > 2017-11-30 8:54 GMT+09:00 Fujimoto Satoshi >>: > > > Hi, Hirasawa-san > > Thanks for your reporting! > > I want to confirm and inspect the problem in my environment, > so could you send me the packets that causes the problem? > > Thanks > Fujimoto > > > On 2017年11月29日 18:20, Takayoshi Hirasawa wrote: > > > Hello > > We are worried about ryu hanging up when certain packets are > packet-in to ryu. > > I am considering an architecture that controls openflow channel > with ryu and OVS. > ryu-ovs picks up all packets to ryu by packet-in operation, and > re-releases it from ryu-ovs after looking up the destination at ryu. > > Specifically, it has the following structure. > (this time, we control openflow channel between ovs and ONOS > controller by ryu) > > > |ryu| > > || > > || ryu-OFchannel > > || > |ONOS| > <===|ryu-ovs|> |ONOS-OVS| > ONOS-OFchannel > ONOS-OFchannel > > > When connecting ONOS-OVS, we confirmed the connection of > ONOS-OFchannel at first. > However, when packets exceeding the MTU of ryu-ovs came from > ONOS-OVS, they segmented in the TCP layer and packeted in to ryu, the > ryu freezed. > In addition, the CPU & memory usage rate of ryu-manager is close to > 100%. > ONOS-OFchannel, ryu-OFchannel and subsequent connection became > disconnected. > > As a result of checking with packet capture, the segmented packet > correctly packet-in from ryu-ovs to ryu, but it seems that ryu does > not respond from the moment when the segmented packet packet-in. > > How
Re: [Ryu-devel] Facing error while connecting to multiple switches with different OF versions
Hi, > 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the > functionality of the switch? (i have tried OFPportstatus request, and it seems > to work) Hmmm... I think it is depending on the switch implementation. The OpenFlow Spec 1.3.5 says the recipient of OFPT_HELLO message should (must?) terminate the connection when the version is not acceptable, but I don't know how switches are handling them on its internal implementation. See "6.3.3 Connection Setup" of the OpenFlow Spec 1.3.5. > 2)What other things i would be required to handle if i were to manage DP's > with OF version 1.3 and 1.5 concurrently on Ryu 4.xx version Are you trying to migrate from Ryu 3.27 to 4.xx? Well, the APIs of "ryu.ofproto" module should keep the backward compatibility, not so much differences as far as such usage, I guess. IIRC, for the main difference of 3.xx and 4.xx, 4.xx drops Python 2.6 support. > 3)Also if possible i would like to know which fix related to this issue was made onto ryu 3.xx version that is making it not fail in 4.16 version The following two patches are the candidates; https://github.com/osrg/ryu/commit/7b5d6bd24a59f3482c6303400049042a54335ac2 https://github.com/osrg/ryu/commit/6792d6df2a28aac436eb9e2afb1fe07bd30a1831 Thanks, Iwase On 2018年02月14日 02:09, rahul b wrote: Hi, I am using RYU version 3.27 to manage ovs and lagopus. ovs i need to connect on OF 1.5(For support in some specific feature in groups) while lagopus only supports OF 1.3 so, i am declaring my ofp versions as follows OFP_VERSIONS = [ ofproto_v1_3.OFP_VERSION, ofproto_v1_5.OFP_VERSION, ] OVS successfully connects on OF version 1.5, However lagopus is facing some issue while connecting on 1.3 connected socket: address:('192.168.1.4', 44517) hello ev object at 0xb642490c> move onto config mode EVENT ofp_event->Controller EventOFPErrorMsg Error in the datapath None from ('192.168.1.4', 44517) EVENT ofp_event->dpset EventOFPStateChange EVENT ofp_event->Controller EventOFPStateChange EVENT ofp_event->ofctl_service EventOFPStateChange hub: uncaught exception: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ryu/lib/hub.py", line 52, in _launch func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 327, in datapath_connection_factory datapath.serve() File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 247, in serve self._recv_loop() File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 103, in deactivate method(self) File "/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 189, in _recv_loop handler(ev) File "/usr/lib/python2.7/site-packages/ryu/controller/ofp_handler.py", line 254, in error_msg_handler (version, msg_type, msg_len, xid) = ofproto_parser.header(msg.data) File "/usr/lib/python2.7/site-packages/ryu/ofproto/ofproto_parser.py", line 39, in header assert len(buf) >= ofproto_common.OFP_HEADER_SIZE AssertionError dumping some more info for the above error. DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 length 12 bufsize DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 0x00 0x00 0x00 0x00 EVENT ofp_event->Controller EventOFPErrorMsg version=0x4, msg_type=0x1, msg_len=0xc, xid=0x6ec6a2f2 length 0 bufsize DUMPING BUFF IN HEADER : OFPErrorMsg received: type=0x00 code=0x00 message= Error in the datapath None from ('192.168.1.4', 59995) However in ryu version 4.16 this is what happens.I get a OFPET_HELL_FAILED but i am able to get port info etc after lagopus is connected. connected socket: address:('127.0.0.1', 55388) hello ev move onto config mode EVENT ofp_event->Controller EventOFPErrorMsg EventOFPErrorMsg received. version=0x4, msg_type=0x1, msg_len=0xc, xid=0xfea3027 `-- msg_type: OFPT_ERROR(1) OFPErrorMsg(type=0x0, code=0x0, data=b'') |-- type: OFPET_HELLO_FAILED(0) |-- code: OFPHFC_INCOMPATIBLE(0) `-- data: EVENT ofp_event->dpset EventOFPSwitchFeatures EVENT ofp_event->Controller EventOFPSwitchFeatures EVENT ofp_event->ofctl_service EventOFPSwitchFeatures switch features ev version=0x4,msg_type=0x6,msg_len=0x20,xid=0xfea3028,OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=65535,n_tables=255) OFPErrorMsg received: type=0x00 code=0x00 message= switch feature handle called succefully add dpid 1 datapath new_info old_info None move onto main mode EVENT ofp_event->dpset EventOFPStateChange EVENT ofp_event->Controller EventOFPStateChange DPSET: register datapath register datapath: 0001 **lagopus dp connected It would be really helpful , if you could tell me 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the functionality of the switch? (i have tried OFPportstatus request, and it seems to work) 2)What other things i would be required to handle if i were to manage DP's with OF version 1.3 and
[Ryu-devel] OpenStack Key Decision Maker's
Hi, My Name is Laura Collins. Hope you are doing well! Would you be occupied with below clients list for your email promoting effort. The List Include: Openstack Salesforce CRM Oracle ERP Cloud Verizon Microsoft Azure Hubspot CRM Infor ERP AT AWS Lambda Zoho CRM QAD ERP Talkdesk Linode SAP CRM SAP ERP CloudCall DigitalOcean Prophet CRM Epicor ERP VoIP Rackspace NetSuite CRM NetSuite ERP Mitel CloudStack SugarCRM Munis ERP Juniper Networks We provide 16 Business field like Name, title, Company, Website, Phone Number, Fax Number, Mailing address, SIC, NAIC, Employee size etc. in an Excel sheet. Job Functions: - CFO, CEO, CMO, COO, CIO, CTO, CAO, CSO, Vice Presidents, Presidents, Directors, Heads, Managers, Executives, Analysts, Coordinators, etc. You can also let me know if you have a different target audience. Let me know your thought so that I can provide you more information with a sample file. Look forward to hear from you. Best Regards, Laura Collins Digital Consultant Database Research: North America, EMEA, APAC and LATAM If you do not wish to receive future emails from us, please reply as 'leave out' -- 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