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
