Finally found the root cause, for some reason the dpdk device has the same
mac address with the device has the tunnel ip.
1(dpdk0): addr:90:e2:ba:d8:c9:88
config: 0
state: LIVE
current:10GB-FD
speed: 1 Mbps now, 0 Mbps max
LOCAL(br-prv): addr:90:e2:ba:d8:c9:88
config: 0
state: LIVE
current:10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
On Sun, Dec 24, 2017 at 9:55 AM, Hui Xiang wrote:
> My other question is does ovs/ovn support pre-population of tunnel's info
> in the fdb/arp table.
>
> On Sat, Dec 23, 2017 at 11:20 AM, Hui Xiang wrote:
>
>> Hi folks,
>>
>>
>> I have a problem on vms spawned between twp physical hosts within same
>> subnet.
>> they are connected with Geneve tunnel based on dpdk.
>>
>> With tracing and debugging, find that the remote tnl arp request will
>> be dropped by the host having the initailed ping vm.
>>
>> This problem can be fixed by restarted ovs-vswitchd.
>>
>>
>> two geneve tunnels: 168.254.100.13 168.254.100.14
>> two vms: 192.168.10.3192.168.10.2
>>
>> I have compared the logs with datapath flow:
>>
>> [Works]
>> 2017-12-22T06:23:54.767Z|00263|dpif_netdev(pmd12)|DBG|ovs-netdev: miss
>> upcall:
>> skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(
>> 0),ct_label(0),recirc_id(0),dp_hash(0),in_port(2),packet_
>> type(ns=0,id=0),eth(src=3e:65:7c:f5:3e:4a,dst=e2:a6:0b:28:
>> b9:43),eth_type(0x0806),arp(sip=168.254.100.13,tip=168.
>> 254.100.14,op=1,sha=3e:65:7c:f5:3e:4a,tha=00:00:00:00:00:00)
>> arp,vlan_tci=0x,dl_src=3e:65:7c:f5:3e:4a,dl_dst=e2:a6:0b
>> :28:b9:43,arp_spa=168.254.100.13,arp_tpa=168.254.100.14,arp_
>> op=1,arp_sha=3e:65:7c:f5:3e:4a,arp_tha=00:00:00:00:00:00
>> 2017-12-22T06:23:54.767Z|00264|dpif(pmd12)|DBG|netdev@ovs-netdev:
>> get_stats success
>> 2017-12-22T06:23:54.767Z|00265|dpif_netdev(pmd12)|DBG|flow_add:
>> ufid:4ef92ea7-67b0-4bc3-8a0c-a4e379f2fe83 recirc_id(0),in_port(2),packet
>> _type(ns=0,id=0),eth(src=3e:65:7c:f5:3e:4a,dst=e2:a6:0b:
>> 28:b9:43),eth_type(0x0806),arp(op=1/0xff), actions:1
>>
>> [Bad]
>> 5990 2017-12-22T03:28:28.386Z|00290|dpif_netdev(pmd84)|DBG|flow_add:
>> ufid:7d555719-c5dc-4e1b-bfff-1851f88aabe7 recirc_id(0),in_port(3),packet
>> _type(ns=0,id=0),eth(src=90:e2:ba:dd:fa:60,dst=
>> ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=168.254.100.13,tip=168.254.100.14,op=1/0xff),
>> actions:drop
>>
>> My question is which openflow has translated into above datapath action
>> drop for bad case, and is there any way to check which function/file
>> translate it or responsible of the geneve tunnel arp processing? The only
>> thing I can use is to adding logs to code and rerun so far. Thank you very
>> much for your help.
>>
>> Hui.
>>
>>
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
