Comment 11 for bug 1883321

Revision history for this message
Erik Panter (epanter) wrote :

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?