>>On Thu, Mar 01, 2018 at 10:21:38AM -0800, Ben Pfaff wrote:                    
>>              
>>> On Fri, Feb 23, 2018 at 03:30:59AM +0000, Yinpeijun wrote:                  
>>>                   
>>> >                                                                           
>>> >                   
>>> > >>On Sun, Feb 11, 2018 at 07:27:34AM +0000, Yinpeijun wrote:              
>>> > >>                  
>>> > >> Hi all                                                                 
>>> > >>                   
>>> > >>                 Recently , I run a test two VM commulication           
>>> > >>                   
>>> > >>with vxlan and ovs+dpdk networking(ovs2.7.2). when I add 200            
>>> > >>                  
>>> > >>virtual device  on the physical service  of the commulicate vm then 
>>> > >>check the ping result,  there  is  loss packet statistics. Then I use 
>>> > >>vlan and ovs+dpdk networking, do the same thing , there is no loss 
>>> > >>packets statistics.
>>> > >>                 I read the source code and add some log to             
>>> > >>                   
>>> > >>confirm the  problem,  the final problem I think is unreasonable        
>>> > >>                  
>>> > >>routing refresh,  in route_table_rest function delete all items before 
>>> > >>readding, so in the middle of the interval  ovs_router_lookup  can not 
>>> > >>find the route then cause packet drop.  So I think the implementation 
>>> > >>need to optimize, Any advice on how to optimize it?
>>> >                                                                           
>>> >                   
>>> > >I don't fully understand your use case.  However, if you're not using 
>>> > >DPDK, then OVS isn't doing routing in userspace so this is probably not 
>>> > >the problem.
>>> >                                                                           
>>> >                   
>>> > Thank you for your replay, the test case just for reproduce the           
>>> >                   
>>> > problem. The actual  scene is to create or migrate virtual machines in 
>>> > openstack env. Correspondence will be created linux bridge and other 
>>> > virtual device.
>>> >                                                                           
>>> >                   
>>> > There is also have problem in netdev dataptah without dpdk.  vxlan tunnel 
>>> > need route in userspace and ovs maintain the route table as follow:
>>> > ovs-appctl ovs/route/show                                                 
>>> >                   
>>> > Route Table:                                                              
>>> >                   
>>> > Cached: x.xx.1.10/32 dev eth0 SRC x.xx.1.10                               
>>> >                   
>>> > Cached: 10.0.0.10/32 dev brcps SRC 10.0.0.10                              
>>> >                   
>>> > Cached: 127.0.0.1/32 dev lo SRC 127.0.0.1                                 
>>> >                   
>>> >                                                                           
>>> >                   
>>> > So when I create virtual device trigger ovs refresh the route then affect 
>>> > the already existing virtual machine communication.
>>>                                                                             
>>>                   
>>> This is the same datapath, really, it's just that most people use it        
>>>                   
>>> with DPDK, and so the solution would be the same.                           
>>>                   
>>>                                                                             
>>>                   
>>> I think that the problem you're talking about can be fixed by holding       
>>>                   
>>> the mutex in route_table_reset() across the entire update, instead of       
>>>                   
>>> just for each individual operation on the routing table.  Does that         
>>>                   
>>> make sense?                                                                 
>>>                   
>>                                                                              
>>                   
>>I sent a patch.  Will you test it?                                            
>>                  
>>        https://patchwork.ozlabs.org/patch/884064/                            
>>                   
>>                                                                              
>>                   
>>Thanks                                                                        
>>                  
>                                                                               
>                   
>ok, I am glad to. I will do this test as soon as possible and tell you the 
>test result later.    
   
 Hi, Ben

 Today I do the test and there is a problem with vxlan commulication,  vxlan 
packet can not be received in dst host because terminate_native_tunnel() is not 
true, the real reason 
 is tnl_port_map_lookup can not find the entry. 
 
Host1:
ovs-appctl dpctl/show
netdev@ovs-netdev:
        lookups: hit:831 missed:268 lost:0
        flows: 0
        port 0: ovs-netdev (tap)
        port 1: br-int (tap)
        port 2: br-tun (tap)
        port 3: br-eth (tap)
        port 4: eth4
        port 5: vxlan_sys_4789 (vxlan: packet_type=ptap)
        port 7: vif3
ovs-vsctl show
6b7f124f-ad74-4803-b933-d9b8f1e01cf6
    Bridge br-int
        Port br-int-tun
            Interface br-int-tun
                type: patch
                options: {peer=br-tun-int}
        Port br-int
            Interface br-int
                type: internal
        Port "vif3"
            Interface "vif3"
    Bridge br-tun
        Port br-tun-int
            Interface br-tun-int
                type: patch
                options: {peer=br-int-tun}
        Port "vxlan1"
            Interface "vxlan1"
                type: vxlan
                options: {key="123456", remote_ip="192.168.100.11"}
        Port br-tun
            Interface br-tun
                type: internal
    Bridge br-eth
        Port br-eth
            Interface br-eth
                type: internal
        Port "eth4"
            Interface "eth4"
    ovs_version: "2.9.90"

Host2:
ovs-appctl dpctl/show
netdev@ovs-netdev:
        lookups: hit:892 missed:238 lost:0
        flows: 0
        port 0: ovs-netdev (tap)
        port 1: br-int (tap)
        port 2: br-tun (tap)
        port 3: br-eth (tap)
        port 4: eth4
        port 5: vxlan_sys_4789 (vxlan: packet_type=ptap)
        port 6: vif2    
ovs-vsctl show
a957065c-33a6-4a8a-a8c9-97ed48eff22f
    Bridge br-tun
        Port "vxlan1"
            Interface "vxlan1"
                type: vxlan
                options: {key="123456", remote_ip="192.168.100.10"}
        Port br-tun
            Interface br-tun
                type: internal
        Port br-tun-int
            Interface br-tun-int
                type: patch
                options: {peer=br-int-tun}
    Bridge br-eth
        Port "eth4"
            Interface "eth4"
        Port br-eth
            Interface br-eth
                type: internal
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port br-int-tun
            Interface br-int-tun
                type: patch
                options: {peer=br-tun-int}
        Port "vif2"
            Interface "vif2"
    ovs_version: "2.9.90"

Host1 tcpdump:
tcpdump -i br-eth -nne
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-eth, link-type EN10MB (Ethernet), capture size 65535 bytes
17:37:17.921255 90:e2:ba:5f:2f:6c > 90:e2:ba:5f:33:40, ethertype IPv4 (0x0800), 
length 120: 192.168.100.11 > 192.168.100.10: ICMP 192.168.100.11 udp port 4789 
unreachable, length 86
17:37:18.921289 90:e2:ba:5f:2f:6c > 90:e2:ba:5f:33:40, ethertype IPv4 (0x0800), 
length 120: 192.168.100.11 > 192.168.100.10: ICMP 192.168.100.11 udp port 4789 
unreachable, length 86
17:37:19.921359 90:e2:ba:5f:2f:6c > 90:e2:ba:5f:33:40, ethertype IPv4 (0x0800), 
length 120: 192.168.100.11 > 192.168.100.10: ICMP 192.168.100.11 udp port 4789 
unreachable, length 86
Host1 dump-flows:
ovs-appctl dpctl/dump-flows
flow-dump from non-dpdk interfaces:
recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=00:e2:ba:00:00:13,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=194.168.100.12,tip=194.168.100.11,op=1/0xff),
 packets:2, bytes:84, used:0.212s, 
actions:1,2,clone(tnl_push(tnl_port(5),header(size=50,type=4,eth(dst=90:e2:ba:5f:2f:6c,src=90:e2:ba:5f:33:40,dl_type=0x0800),ipv4(src=192.168.100.10,dst=192.168.100.11,proto=17,tos=0,ttl=64,frag=0x4000),udp(src=0,dst=4789,csum=0x0),vxlan(flags=0x8000000,vni=0x1e240)),out_port(3)),4)
recirc_id(0),in_port(4),packet_type(ns=0,id=0),eth(src=90:e2:ba:5f:2f:6c,dst=90:e2:ba:5f:33:40),eth_type(0x0800),ipv4(frag=no),
 packets:2, bytes:240, used:0.212s, actions:3


 Please Check, Thanks.
 
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to