Hi, all: recently we meet a problem that when use ovs group with selection method dp_hash, same tcp session selects different ovs group bucket when tcp packet retransmit. if we fill different snat gw in group buckets, that will make tcp session reset after packet retranmition.
we can reproduce this problem in a simple enviroment: Node1: (debian 9.8 with kernel version 4.9.65 and ovs version 2.10.1) act as a httpserver ovs-vsctl add-br br-int ovs-vsctl set bridge br-int protocols="OpenFlow10","OpenFlow11","OpenFlow12","OpenFlow13","OpenFlow14","OpenFlow15" ovs-vsctl add-port br-int tap111 -- set interface tap111 type=internal ovs-vsctl add-port br-int vxlan111 -- set interface vxlan111 type=vxlan options:in_key=flow options:local_ip="10.185.2.46" options:out_key=flow options:remote_ip=flow ip link set dev tap111 netns ns111 ip netns exec ns111 ip link set dev tap111 up ip netns exec ns111 ip link set dev tap111 mtu 1450 ip netns exec ns111 ip address add 10.1.1.1/24 dev tap111 //only an emulation, just set different nw_ttl in different bucket, we can simply watch the problem by capture packets ovs-ofctl add-group br-int -O openflow15 \ "group_id=2233,type=select,selection_method=dp_hash,bucket=bucket_id=1,actions=mod_nw_ttl:10,output:vxlan111,bucket=bucket_id=2,actions=mod_nw_ttl:20,output:vxlan111" ovs-ofctl add-flow br-int -O openflow15 "priority=100,in_port=tap111,ip,actions=set_field:1122->tun_id,set_field:10.185.2.47->tun_dst,group:2233" ovs-ofctl add-flow br-int -O openflow15 "priority=100,in_port=tap111,arp,actions=set_field:1122->tun_id,set_field:10.185.2.47->tun_dst,output:vxlan111" ovs-ofctl add-flow br-int -O openflow15 "priority=100,in_port=vxlan111,tun_id=1122,actions=output:tap111" //use tc netem to emulate tcp retransmition ip netns exec ns111 tc qdisc add dev tap111 root netem loss 1% Node2: (debian 9.1 with kernel version 4.9.0 and ovs version 2.8.2) act as a httpclient ovs-vsctl add-br br-int ovs-vsctl set bridge br-int protocols="OpenFlow10","OpenFlow11","OpenFlow12","OpenFlow13","OpenFlow14","OpenFlow15" ovs-vsctl add-port br-int tap111 -- set interface tap111 type=internal ovs-vsctl add-port br-int vxlan111 -- set interface vxlan111 type=vxlan options:in_key=flow options:local_ip="10.185.2.47" options:out_key=flow options:remote_ip=flow ip link set dev tap111 netns ns111 ip netns exec ns111 ip link set dev tap111 up ip netns exec ns111 ip link set dev tap111 mtu 1450 ip netns exec ns111 ip address add 10.1.1.8/24 dev tap111 ovs-ofctl add-flow br-int -O openflow15 "priority=100,in_port=tap111,actions=set_field:1122->tun_id,set_field:10.185.2.46->tun_dst,output:vxlan111" ovs-ofctl add-flow br-int -O openflow15 "priority=100,in_port=vxlan111,tun_id=1122,actions=output:tap111" In such enviroment, when we try to get a large file from Node1(httpserver), we can found that after tcp retransmition, not only the outer header of vxlan udp source port changed, but also inner IP header TTL changed. I think maybe sk_rethink_txhash() makes skb->hash changed when tcp retransmit, and any function who calls skb_get_hash() will be affected, like execute_hash() and udp_flow_src_port(). _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev