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&ryu-ovs 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
<satoshi.fujimo...@gmail.com <mailto:satoshi.fujimo...@gmail.com>>:
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-ovs.)
|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 can we solve this?
I will attach a python script (rebuilt version of
simple_switch_13) that I am running on ryu.
Thank you.
------------------------------------------------------------------------------
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.sourceforge.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
#!/usr/bin/env python
import argparse
import six
import json
from ryu.utils import binary_str
from ryu.lib import pcaplib
from ryu.lib.packet import packet
from ryu.lib.packet import tcp
from ryu.ofproto import ofproto_parser
from ryu.ofproto import ofproto_protocol
parser = argparse.ArgumentParser(
description='Display packets contained in pcap file.')
parser.add_argument('file', metavar='FILE', type=str,
help='pcap file to display')
args = parser.parse_args()
def print_openflow(buf):
(version, msg_type, msg_len, xid) = ofproto_parser.header(buf)
msg = ofproto_parser.msg(
ofproto_protocol.ProtocolDesc(version),
version, msg_type, msg_len, xid, buf)
print('\n\n***\n%s\n\n' % msg)
print(json.dumps(msg.to_jsondict(), sort_keys=True, indent=3))
#try:
# msg = ofproto_parser.msg(
# ofproto_protocol.ProtocolDesc(version),
# version, msg_type, msg_len, xid, buf)
# print('\n\n***\n%s\n\n' % msg)
# print(json.dumps(msg.to_jsondict(), sort_keys=True, indent=3))
#except:
# print('version=%s, msg_type=%s, msg_len=%s, xid=%s' %
# (version, msg_type, msg_len, xid))
def main():
cnt = 0
for ts, buf in pcaplib.Reader(open(args.file, 'rb')):
cnt += 1
pkt = packet.Packet(buf)
#try:
# pkt = packet.Packet(buf)
#except Exception as e:
# print(e)
# print('===\n%s\n===' % binary_str(buf))
# continue
print("\n*** %d, %f\n" % (cnt, ts))
for p in pkt.protocols:
if isinstance(p, six.binary_type):
pkt_tcp = pkt.get_protocol(tcp.tcp)
if pkt_tcp:
assert isinstance(pkt_tcp, tcp.tcp)
if pkt_tcp.src_port == 6654 or pkt_tcp.dst_port == 6654:
print_openflow(p)
else:
print(binary_str(p))
pass
else:
pass
print(p)
print("\n")
if __name__ == '__main__':
main()
------------------------------------------------------------------------------
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
