Re: [Ryu-devel] Facing error while connecting to multiple switches with different OF versions

2018-02-15 Thread Iwase Yusuke

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

2018-02-15 Thread rahul b
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 Yusuke 
wrote:

> 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

2018-02-15 Thread shivani dommeti
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

2018-02-15 Thread Iwase Yusuke

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

2018-02-15 Thread Takayoshi Hirasawa
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

2018-02-15 Thread Iwase Yusuke

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

2018-02-15 Thread Laura Collins


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