Hi,
I noticed the same issue you mentioned in #2 with openvswitch 2.12.0 and OpenStack train
This datapath flow (on compute1 in your case) causes all tunneled traffic to be forwarded to the first VM's tap interface:
recirc_id(0),tunnel(...),in_port(vxlan_sys_*),eth(src=<dvr-mac>),eth_type(0x0800),ipv4(frag=no),actions:set(eth(src=fa:16:3e:5b:19:10)),tap*
it is missing the destination mac address, even though the OpenFlow flows actually match the instance's mac address in table 1 and 60 when tracing incoming traffic on br-int:
-------------------- Router DVR MAC: fa:16:3f:d8:de:ca
VMa MAC: fa:16:3e:e4:f2:f2 VMb MAC: fa:16:3e:0d:a5:98
VMa tap: tap34269161-f2 VMb tap: tap83b8d780-fb -------------------
$ ovs-appctl ofproto/trace br-tun in_port=vxlan-0a221012,tun_id=0x1,dl_src=fa:16:3f:d8:de:ca,dl_dst=fa:16:3e:0d:a5:98 Flow: tun_id=0x1,in_port=2,vlan_tci=0x0000,dl_src=fa:16:3f:d8:de:ca,dl_dst=fa:16:3e:0d:a5:98,dl_type=0x0000
bridge("br-tun") ---------------- 0. in_port=2, priority 1, cookie 0xb1a5a3f5821cab3e goto_table:4 4. tun_id=0x1, priority 1, cookie 0xb1a5a3f5821cab3e push_vlan:0x8100 set_field:4098->vlan_vid goto_table:9 9. dl_src=fa:16:3f:d8:de:ca, priority 1, cookie 0xb1a5a3f5821cab3e output:1
bridge("br-int") ---------------- 0. in_port=3,dl_src=fa:16:3f:d8:de:ca, priority 2, cookie 0xb0d51fe3de606c9 goto_table:1 1. dl_vlan=2,dl_dst=fa:16:3e:0d:a5:98, priority 20, cookie 0xb0d51fe3de606c9 set_field:fa:16:3e:0d:8c:ea->eth_src goto_table:60 60. dl_vlan=2,dl_dst=fa:16:3e:0d:a5:98, priority 20, cookie 0xb0d51fe3de606c9 pop_vlan output:665
Final flow: tun_id=0x1,in_port=2,dl_vlan=2,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=fa:16:3f:d8:de:ca,dl_dst=fa:16:3e:0d:a5:98,dl_type=0x0000 Megaflow: recirc_id=0,eth,tun_id=0x1,in_port=2,vlan_tci=0x0000/0x1fff,dl_src=fa:16:3f:d8:de:ca,dl_dst=fa:16:3e:0d:a5:98,dl_type=0x0000 Datapath actions: set(eth(src=fa:16:3e:0d:8c:ea,dst=fa:16:3e:0d:a5:98)),13
After I downgraded to openvswitch 2.11.4 and recreated the setup, the datapath flows seem correct and the two pings work simultaneously:
$ovs-appctl dpctl/dump-flows --names | grep 'fa:16:3f:d8:de:ca'
recirc_id(0),tunnel(...),in_port(vxlan_sys_4789),eth(src=fa:16:3f:d8:de:ca,dst=fa:16:3e:0d:a5:98),eth_type(0x0800),ipv4(frag=no), ... actions:set(eth(src=fa:16:3e:0d:8c:ea,dst=fa:16:3e:0d:a5:98)),tap83b8d780-fb
recirc_id(0),tunnel(...),in_port(vxlan_sys_4789),eth(src=fa:16:3f:d8:de:ca,dst=fa:16:3e:e4:f2:f2),eth_type(0x0800),ipv4(frag=no), ... actions:set(eth(src=fa:16:3e:0d:8c:ea,dst=fa:16:3e:e4:f2:f2)),tap34269161-f2
could this be an issue in openvswitch?
Hi,
I noticed the same issue you mentioned in #2 with openvswitch 2.12.0 and OpenStack train
This datapath flow (on compute1 in your case) causes all tunneled traffic to be forwarded to the first VM's tap interface:
recirc_ id(0),tunnel( ...),in_ port(vxlan_ sys_*), eth(src= <dvr-mac> ),eth_type( 0x0800) ,ipv4(frag= no),actions: set(eth( src=fa: 16:3e:5b: 19:10)) ,tap*
it is missing the destination mac address, even though the OpenFlow flows actually match the instance's mac address in table 1 and 60 when tracing incoming traffic on br-int:
------- ------- ------
Router DVR MAC: fa:16:3f:d8:de:ca
VMa MAC: fa:16:3e:e4:f2:f2
VMb MAC: fa:16:3e:0d:a5:98
VMa tap: tap34269161-f2
VMb tap: tap83b8d780-fb
-------------------
$ ovs-appctl ofproto/trace br-tun in_port= vxlan-0a221012, tun_id= 0x1,dl_ src=fa: 16:3f:d8: de:ca,dl_ dst=fa: 16:3e:0d: a5:98 0x1,in_ port=2, vlan_tci= 0x0000, dl_src= fa:16:3f: d8:de:ca, dl_dst= fa:16:3e: 0d:a5:98, dl_type= 0x0000
Flow: tun_id=
bridge("br-tun") vlan:0x8100 field:4098- >vlan_vid fa:16:3f: d8:de:ca, priority 1, cookie 0xb1a5a3f5821cab3e
----------------
0. in_port=2, priority 1, cookie 0xb1a5a3f5821cab3e
goto_table:4
4. tun_id=0x1, priority 1, cookie 0xb1a5a3f5821cab3e
push_
set_
goto_table:9
9. dl_src=
output:1
bridge("br-int") 3,dl_src= fa:16:3f: d8:de:ca, priority 2, cookie 0xb0d51fe3de606c9 2,dl_dst= fa:16:3e: 0d:a5:98, priority 20, cookie 0xb0d51fe3de606c9 field:fa: 16:3e:0d: 8c:ea-> eth_src 2,dl_dst= fa:16:3e: 0d:a5:98, priority 20, cookie 0xb0d51fe3de606c9
----------------
0. in_port=
goto_table:1
1. dl_vlan=
set_
goto_table:60
60. dl_vlan=
pop_vlan
output:665
Final flow: tun_id= 0x1,in_ port=2, dl_vlan= 2,dl_vlan_ pcp=0,vlan_ tci1=0x0000, dl_src= fa:16:3f: d8:de:ca, dl_dst= fa:16:3e: 0d:a5:98, dl_type= 0x0000 id=0,eth, tun_id= 0x1,in_ port=2, vlan_tci= 0x0000/ 0x1fff, dl_src= fa:16:3f: d8:de:ca, dl_dst= fa:16:3e: 0d:a5:98, dl_type= 0x0000 src=fa: 16:3e:0d: 8c:ea,dst= fa:16:3e: 0d:a5:98) ),13
Megaflow: recirc_
Datapath actions: set(eth(
After I downgraded to openvswitch 2.11.4 and recreated the setup, the datapath flows seem correct and the two pings work simultaneously:
$ovs-appctl dpctl/dump-flows --names | grep 'fa:16:3f:d8:de:ca'
recirc_ id(0),tunnel( ...),in_ port(vxlan_ sys_4789) ,eth(src= fa:16:3f: d8:de:ca, dst=fa: 16:3e:0d: a5:98), eth_type( 0x0800) ,ipv4(frag= no), ... actions: set(eth( src=fa: 16:3e:0d: 8c:ea,dst= fa:16:3e: 0d:a5:98) ),tap83b8d780- fb
recirc_ id(0),tunnel( ...),in_ port(vxlan_ sys_4789) ,eth(src= fa:16:3f: d8:de:ca, dst=fa: 16:3e:e4: f2:f2), eth_type( 0x0800) ,ipv4(frag= no), ... actions: set(eth( src=fa: 16:3e:0d: 8c:ea,dst= fa:16:3e: e4:f2:f2) ),tap34269161- f2
could this be an issue in openvswitch?