<#secure method=pgpmime mode=encrypt>
On Sat, Apr 28, 2018 at 07:27:33AM +0000, Lifan Su wrote:
> Hello,
> 
> I am attempting to make an example using RYU and Openvswitch following
>   http://ryu.readthedocs.io/en/latest/writing_ryu_app.html
> In this example, all packets are flooded to all other ports,
> which makes the switch working as a hub.
> 
> I installed Openvswitch on a linux virtual machine with 6 NICs, which are
> named as eth{0..5}. eth0 is used for out-of-band controlling,
> eth{1..5} is used to connect to 5 other virtual machines by using
> the socket network provided by QEMU.
> The other virtual machines have IP address of 10.1.1.{1..5}
> 
> I used following command to setup the switch:
>   ovs-vsctl add-br br0 \
>     -- set bridge br0 other-config:datapath-id=0000000000000001 \
>     -- add-port br0 eth1 -- set interface eth1 ofport_request=1 \
>     -- add-port br0 eth2 -- set interface eth2 ofport_request=2 \
>     -- add-port br0 eth3 -- set interface eth3 ofport_request=3 \
>     -- add-port br0 eth4 -- set interface eth4 ofport_request=4 \
>     -- add-port br0 eth5 -- set interface eth5 ofport_request=5 \
>     -- set-controller br0 tcp:192.168.2.201:6653 \
>     -- set controller br0 connection-mode=out-of-band \
>     -- set bridge br0 fail-mode=secure
> 
> The RYU controller is setup via following command, run on 192.168.2.201:
>   ryu-manager ./flood.py --ofp-tcp-listen-port 6653
> 
> When I ping 10.1.1.2 from 1.1.1.1, since the switch floods all packets,
> the ping is expected to be responsed. But I always got
>   'From 10.1.1.1 icmp_seq=1 Destination Host Unreachable'
> I reviewed the log of openvswitch and found following message:
>   2018-04-29T06:49:29.448Z|00016|poll_loop(handler5)|DBG|wakeup due to
> [POLLIN] on fd 21 (unknown anon_inode:[eventpoll]) at
> lib/dpif-netlink.c:2769
>   2018-04-29T06:49:29.448Z|00017|netlink_socket(handler5)|DBG|nl_sock_recv__
> (Success): nl(len:186, type=24(ovs_packet), flags=0, seq=0,
> pid=0,genl(cmd=2,version=1)
>   2018-04-29T06:49:29.449Z|00018|dpif(handler5)|DBG|system@ovs-system:
> action upcall:
>   
> recirc_id(0),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(0),eth(src=52:54:00:4a:59:8f,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.1.1.1,tip=10.1.1.2,op=1,sha=52:54:00:4a:59:8f,tha=00:00:00:00:00:00)
> 
> arp,vlan_tci=0x0000,dl_src=52:54:00:4a:59:8f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.1.1.1,arp_tpa=10.1.1.2,arp_op=1,arp_sha=52:54:00:4a:59:8f,arp_tha=00:00:00:00:00:00
>   2018-04-29T06:49:29.449Z|00019|poll_loop(handler5)|DBG|wakeup due to
> 0-ms timeout at ofproto/ofproto-dpif-upcall.c:747
>   2018-04-29T06:49:29.449Z|00767|poll_loop|DBG|wakeup due to [POLLIN]
> on fd 39 (FIFO pipe:[4003]) at vswitchd/bridge.c:385 (0% CPU usage)
>   2018-04-29T06:49:29.449Z|00768|vconn|DBG|tcp:192.168.2.201:6653:
> sent (Success): OFPT_PACKET_IN (xid=0x0): total_len=42 in_port=1 (via
> no_match) data_len=42 (unbuffered)
>   
> arp,vlan_tci=0x0000,dl_src=52:54:00:4a:59:8f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.1.1.1,arp_tpa=10.1.1.2,arp_op=1,arp_sha=52:54:00:4a:59:8f,arp_tha=00:00:00:00:00:00
>   2018-04-29T06:49:29.450Z|00769|poll_loop|DBG|wakeup due to [POLLIN]
> on fd 36 (192.168.2.101:48530<->192.168.2.201:6653) at
> lib/stream-fd.c:157 (0% CPU usage)
>   2018-04-29T06:49:29.451Z|00770|vconn|DBG|tcp:192.168.2.201:6653:
> received: OFPT_PACKET_OUT (xid=0xf2daa020): in_port=1 actions=FLOOD
> data_len=0
>   
> 2018-04-29T06:49:29.451Z|00771|netlink_socket|DBG|nl_sock_transact_multiple__
> (Success): nl(len:100, type=24(ovs_packet), flags=1[REQUEST], seq=f3,
> pid=2562,genl(cmd=3,version=1)
>   2018-04-29T06:49:29.451Z|00772|netlink_socket|DBG|nl_sock_recv__
> (Success): nl(len:120, type=2(error), flags=0, seq=f3, pid=2562
> error(-34(Numerical result out of range), in-reply-to(nl(len:100,
> type=24(ovs_packet), flags=1[REQUEST], seq=f3, pid=2562))
>   2018-04-29T06:49:29.451Z|00773|netlink_socket|DBG|received NAK
> error=0 (Numerical result out of range)
>   2018-04-29T06:49:29.451Z|00774|dpif|WARN|system@ovs-system: execute
> 6,2,1,3,5 failed (Numerical result out of range) on packet
> vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
>                                                         with metadata
> skb_priority(0),skb_mark(0),in_port(4) mtu 0
> 
> The module is provided by linux kernel 4.9.76 and the openvswitch software
> is 2.8.2.
> 
> So what am I doing wrong?

ERANGE is quite an unusual error message.  Only a few of the kernel code
paths can yield that error.  Is there anything in the kernel log?
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to