[ovs-discuss] same tcp session selects different ovs group bucket when tcp retransmit

ychen ychen103103 at 163.com
Wed Jan 27 12:02:34 UTC 2021


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().




   
   
 




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20210127/ec853601/attachment.html>


More information about the discuss mailing list