Congratulations! Thanks for sharing how you have solved this problem.
2019年8月16日(金) 7:03 Martin Mirakyan <mirakyanmar...@gmail.com>: > I was finally able to fix the issue. Apparently the switch didn't start > with the table=0 and just dropped the packet instead. So, when sending > PacketOut I explicitly specified that it needs to be resubmitted to table=0. > > This part: > > actions = [ > ofp_parser.NXActionResubmitTable(table_id=0), > ] > datapath.send_packet_out(in_port=ofp.OFPP_LOCAL, > actions=actions, > data=data) > > did the job! > > Thanks for your time and help! > Best, > Martin > > > On Thu, Aug 15, 2019 at 11:35 AM Martin Mirakyan <mirakyanmar...@gmail.com> > wrote: > >> As I was able to see a PacketOut message in Wireshark from a tcpdump and >> Ryu didn't have any errors while sending it to the switch, I tried to look >> at the logs on the ovs side. >> I've enabled the debug-level logs with: >>> >>> sudo ovs-appctl vlog/set ANY:syslog:dbg && sudo ovs-appctl vlog/set >>> ANY:file:dbg >> >> >> After which was able to see: >> >> 2019-08-15T18:04:37.183Z|09862|vconn|DBG|tcp:127.0.0.1:6633: received: >>> OFPT_PACKET_OUT (OF1.4) (xid=0x4a011755): in_port=LOCAL actions=drop >>> data_len=44 >>> >>> vlan_tci=0x0000,dl_src=fe:ee:ee:ee:ee:ef,dl_dst=08:00:06:04:00:01,dl_type=0xc0a8 >> >> >> I think the `actions=drop` causes the packet to be dropped without even >> hitting any tables. >> The packet is created with: >> >>> pkt = ethernet.ethernet(ethertype=ETH_TYPE_ARP, >>> src='fe:ee:ee:ee:ee:ef', >>> dst='ff:ff:ff:ff:ff:ff') / \ >>> arp.arp(hwtype=arp.ARP_HW_TYPE_ETHERNET, proto=ETH_TYPE_IP, >>> hlen=6, plen=4, >>> opcode=arp.ARP_REQUEST, >>> src_mac='fe:ee:ee:ee:ee:ef', src_ip='192.168.70.2', >>> dst_mac='00:00:00:00:00:00', dst_ip='192.168.70.3') >>> pkt.serialize() >> >> >> >> Do you have any suggestions on how to fix it? >> >> >> Thanks. >> Best, >> Martin >> >> On Thu, Aug 15, 2019 at 10:15 AM Martin Mirakyan < >> mirakyanmar...@gmail.com> wrote: >> >>> Thanks for the suggestions, >>> >>> I was able to see an Openflow 1.4 PacketOut message in Wireshark from >>> tcpdump and a TCP message from port 6633 to port 49020. And there were no >>> error messages in Ryu logs when verbose mode is enabled. >>> >>> But still, `n_packets=0, n_bytes=0` for all the tables out there. So the >>> packet doesn't actually hit the switch. >>> Do you have any ideas why this might be happening? >>> >>> Thanks again for your help. >>> Best, >>> Martin >>> >>> On Thu, Aug 15, 2019 at 6:19 AM Yusuke Iwase <iwase.yusu...@gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> First, please verify whether the packets you sent ware forwarded or >>>> not. >>>> For example, tcpdump or wireshark are useful to check it. Also please >>>> confirm the log messages with log-level=debug. "ryu-manager --verbose" >>>> option should work to set log-level. With this option, please check >>>> whether any error message will be output or not. >>>> >>>> Regards, >>>> Iwase >>>> >>>> On 2019/08/14 13:34, Martin Mirakyan wrote: >>>> > Thanks! >>>> > >>>> > I'm trying to do as you suggested, but interestingly whenever I >>>> execute >>>> > `ovs-ofctl dump-flows gtp_br0` I see that all the tables have >>>> > `n_packets=0, n_bytes=0`. So, as far as I understand, the PacketOut >>>> is >>>> > getting called but that doesn't reach the switch. Do you have any >>>> > suggestions on what might be the problem? >>>> > >>>> > Thanks again for your time. >>>> > >>>> > Best, >>>> > Martin >>>> > >>>> > On Tue, Aug 13, 2019 at 8:58 PM Yusuke Iwase <iwase.yusu...@gmail.com >>>> > <mailto:iwase.yusu...@gmail.com>> wrote: >>>> > >>>> > Hi, >>>> > >>>> > Yes, you can send the Packet-Out messages without any Packet-In >>>> > messages, but it is required to confirm that Ryu and your switch >>>> are >>>> > connected and "datapath" instance for the target switch is given. >>>> > >>>> > If you need to send a Packet-Out message at the initialization >>>> step, >>>> > how about sending the message in "switch_features_handler"? >>>> > >>>> > >>>> https://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPSwitchFeatures >>>> > >>>> > This handler should be invoked at the initialization step for the >>>> > target switch and "datapath" instance will be given. >>>> > >>>> > Regards, >>>> > Iwase >>>> > >>>> > >>>> > 2019年8月14日(水) 3:08 Martin Mirakyan <mirakyanmar...@gmail.com >>>> > <mailto:mirakyanmar...@gmail.com>>: >>>> > >>>> > Dear Ryu developer support team, >>>> > >>>> > Is it possible to send a packet to the switch from a Ryu app >>>> > without having any kind of PacketIn events? I want to >>>> initiate a >>>> > packet-send from a Ryu app so that the trigger of the event is >>>> > the Ryu app itself not something external. >>>> > >>>> > I've tried to do (in `def start`): >>>> > >>>> > datapath.send_packet_out(in_port=ofp.OFPP_LOCAL, >>>> > actions=[], >>>> > data=pkt.data) >>>> > >>>> > >>>> > But when I print `ovs-ofctl dump-flows gtp_br0` all the tables >>>> > show n_packets=0 (they aren't 0 if I initiate traffic not >>>> from a >>>> > Ryu app). >>>> > >>>> > Is there something I might be missing? >>>> > >>>> > Thanks. >>>> > Best, >>>> > Martin >>>> > _______________________________________________ >>>> > Ryu-devel mailing list >>>> > Ryu-devel@lists.sourceforge.net >>>> > <mailto:Ryu-devel@lists.sourceforge.net> >>>> > https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>> > >>>> >>>
_______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
