On 8/17/22 11:32, ychen wrote:
> hi,
> when we send 2 packets with different dest mac in 10s(fast datapath flow
> aging time), with the same userspace flow action, but the second packet act
> incorrectly.
>
> 1. problem phenomenon:
> userspace flow:
> in_port=1,table=0,cookie=0x123,priority=500,tun_id=0x3562,actions=set_field:fe:ff:ff:ff:ff:ff->eth_src,set_field:fa:16:3e:c0:ee:8c->eth_dst,output:tap111
> packet caputured:
> 13:51:02.097914 fe:ff:ff:ff:ff:ff > fa:16:3e:c0:ee:8c , ethertype IPv4
> (0x0800), length 115: 10.194.50.240.53 > 10.199.16.44.48651: 35479 1/0/1 A
> 66.102.251.24 (73) //first packet, corrrect change its mac
> 13:51:04.213568 fe:ff:ff:ff:ff:ff > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 115: 10.194.50.240.53 > 10.199.16.44.48651: 35479 1/0/1 A
> 66.102.251.24 (73) //second packet, dest mac stay as unchanged
>
>
> 2. enviroment
> ovs 2.12, can only reproduce in kernel mode
>
>
> 3. reproduce step
> client node--> server node
>
>
> 3.1 client node configuration:
> $ sudo ovs-vsctl show
> 77f97d1d-e34f-4e4c-b4f1-1d2299a4411a
> Bridge br-test
> fail_mode: secure
> Port "vxlan11"
> Interface "vxlan11"
> type: vxlan
> options: {in_key=flow, local_ip="10.185.2.87", out_key=flow,
> remote_ip=flow}
> Port br-test
> Interface br-test
> type: internal
> Port "tap11"
> Interface "tap11"
> type: internal
> ovs_version: "2.12.0"
>
> sudo ovs-ofctl dump-flows br-test -O openflow13
> cookie=0x0, duration=223377.958s, table=0, n_packets=7512, n_bytes=1755097,
> reset_counts in_port=tap11
> actions=set_field:0x3562->tun_id,load:0xab90251->NXM_NX_TUN_IPV4_DST[],output:vxlan11
>
> 3.2 server node configuration:
> # ovs-vsctl show
> f39fb127-019b-41c3-86b7-a420a3b4d7f2
> Bridge br-int
> fail_mode: secure
> Port "vf-10.185.2.81"
> Interface "vf-10.185.2.81"
> type: vxlan
> options: {csum="true", df_default="false", in_key=flow,
> local_ip="10.185.2.81", out_key=flow, remote_ip=flow}
> Port br-int
> Interface br-int
> type: internal
> Port "tap111"
> Interface "tap111"
> type: internal
> ovs_version: "2.12.0"
>
> ovs-ofctl add-flow br-int -O openflow13
> "in_port=1,table=0,cookie=0x123,priority=500,tun_id=0x3562,actions=set_field:fe:ff:ff:ff:ff:ff->eth_src,set_field:c6:3a:16:ec:e0:d9->eth_dst,output:tap111"
>
>
> 3.3 sending packets
> packet payload:
> dst mac:c6:3a:16:ec:e0:d9
> src mac: 02:00:00:00:00:00
> src ip: 10.194.50.241
> dst ip: 10.100.100.212
> proto: udp
> l4port: 45678
> # ovs-ofctl packet-out br-test 1 "table=0"
> "c63a16ece0d902000000000008004500001c0000400040118de60ac232f10a6464d48000b26e00082084000000000000000000000000000000000000"
> sleep 1s, send the second packet:
> # ovs-ofctl packet-out br-test 1 "table=0"
> "11111111111102000000000008004500001c0000400040118de60ac232f10a6464d48000b26e00082084000000000000000000000000000000000000"
>
> 3.4 server node packet capture
> 10:49:59.725865 fe:ff:ff:ff:ff:ff > c6:3a:16:ec:e0:d9, ethertype
> IPv4 (0x0800), length 60: 10.194.50.241.32768 > 10.100.100.212.45678: UDP,
> length 0
> 10:50:00.881564 fe:ff:ff:ff:ff:ff > 11:11:11:11:11:11, ethertype
> IPv4 (0x0800), length 60: 10.194.50.241.32768 > 10.100.100.212.45678: UDP,
> length 0 //it is wrong, dest mac should be c6:3a:16:ec:e0:d9
>
> 3.5 fast datapath flow in server node
>
> recirc_id(0),tunnel(tun_id=0x3562,src=10.185.2.87,dst=10.185.2.81,flags(-df-csum+key)),in_port(1),eth(src=02:00:00:00:00:00),eth_type(0x0800),ipv4(frag=no),
> packets:1, bytes:60, used:2.176s, actions:,set(eth(src=fe:ff:ff:ff:ff:ff)),3
>
>
> correct datapath flow:
>
> recirc_id(0),tunnel(tun_id=0x3562,src=10.185.2.87,dst=10.185.2.81,flags(-df-csum+key)),in_port(1),eth(src=02:00:00:00:00:00,dst=11:11:11:11:11:11),eth_type(0x0800),ipv4(frag=no),
> packets:0, bytes:0, used:never,
> actions:set(eth(src=fe:ff:ff:ff:ff:ff,dst=c6:3a:16:ec:e0:d9)),3
>
> compare with the correct datapath flow, dest mac is disappeared in match
> and action.
Hi. The issue you described look very much like the issue fixed in the
following patch:
https://patchwork.ozlabs.org/project/openvswitch/patch/20200729091341.471853-1-i.maxim...@ovn.org/
But you're using very old version of OVS. 2.12 is not supported anymore.
And you seem to use 2.12.0, while the issue supposed to be fixed in 2.12.1.
The last release on the branch 2.12 was v2.12.4.
So, please, try a newer version. Ideally, upgrade to 2.17, which is our
current LTS series.
Best regards, Ilya Maximets.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
