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

Reply via email to