Hello, I encounter a problem of patch port and 'in_port' action: ovs-vswitchd hangs when any packet received from patch port and matches a flow with 'in_port' action. Is it a bug? Or I missing anything? My ovs version is 1.12.90, compiled with recent git source code (commit: 31d738062df326aca4), however, I've not test other versions yet.
To replicate: 1, Create a test netns and devices sudo ip netns add n1 sudo ip netns add n2 sudo ip l add type veth sudo ip l add type veth sudo ip l set dev veth0 up sudo ip l set dev veth1 up netns n1 sudo ip l set dev veth2 up sudo ip l set dev veth3 up netns n2 2, Add ip addresses and routes sudo ip netns exec n1 ip a add 10.0.1.2/24 dev veth1 brd 10.0.1.255 sudo ip netns exec n1 ip r add 10.0.0.0/8 dev veth1 sudo ip netns exec n2 ip a add 10.0.2.2/24 dev veth3 brd 10.0.2.255 sudo ip netns exec n2 ip r add 10.0.0.0/8 dev veth3 3, Create two bridges and connected with path port, and connect test devices sudo ovs-vsctl add-br br-test sudo ovs-vsctl add-br br-loop sudo ovs-vsctl add-port br-test patch_t_l -- set Interface patch_t_l type=patch options:peer=patch_l_t sudo ovs-vsctl add-port br-loop patch_l_t -- set Interface patch_l_t type=patch options:peer=patch_t_l sudo ovs-vsctl add-port br-test veth0 -- set Port veth0 tag=1 sudo ovs-vsctl add-port br-test veth2 -- set Port veth2 tag=2 4, Add flows sudo ovs-ofctl add-flow br-loop priority=3,in_port=1,arp,nw_dst=10.0.1.2,actions=mod_vlan_vid:1,in_port sudo ovs-ofctl add-flow br-loop priority=3,in_port=1,ip,nw_dst=10.0.1.2,actions=mod_vlan_vid:1,in_port sudo ovs-ofctl add-flow br-loop priority=3,in_port=1,arp,nw_dst=10.0.2.2,actions=mod_vlan_vid:2,in_port sudo ovs-ofctl add-flow br-loop priority=3,in_port=1,ip,nw_dst=10.0.2.2,actions=mod_vlan_vid:2,in_port 5, send test packets sudo ip netns exec n1 ping 10.0.2.2 Now, the ovs-vswitchd seems hang, and I strace the process, get a lot futex calls, have to restart vswitch to recovery. ... futex(0x1ddeab4, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 202 futex(0x1ddeab4, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 202 futex(0x1ddeab4, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 202 futex(0x1ddeab4, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 202 futex(0x1ddeab4, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 202 futex(0x1ddeab4, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- ... Again, I connect br-test and br-loop with veth devices, and keep other options the same, it works as expected. Regards,
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
