Comment 0 for bug 1767811

Environment:

    Version: Ocata/Stable
    Nodes: Two nodes. One node with controller services and network services(dvr_snat), the other node with compute service and network services(dvr)

Setups to reproduce:

    1. Create networks and DVR and connect them, enable snat.
    2. Boot one VM in compute node
    3. Ping 8.8.8.8 inside the VM
    4. tcpdump the tap device of VM

Observation:

    $ sudo tcpdump -nei tap8b25d590-09
    fa:16:3e:63:0c:57 > fa:16:3e:c8:7a:67, ethertype IPv4 (0x0800), length 98: 10.0.0.6 > 8.8.8.8: ICMP echo request, id 22273, seq 343, length 64
    fa:16:3e:c8:7a:67 > fa:16:3e:ba:67:74, ethertype IPv4 (0x0800), length 98: 10.0.0.6 > 8.8.8.8: ICMP echo request, id 22273, seq 343, length 64
    fa:16:3e:ba:67:74 > fa:16:3e:63:0c:57, ethertype IPv4 (0x0800), length 98: 8.8.8.8 > 10.0.0.6: ICMP echo reply, id 22273, seq 343, length 64

Relationship between IP address and MAC address:

    VM 10.0.0.6 fa:16:3e:63:0c:57
    qr-xxx 10.0.0.1 fa:16:3e:c8:7a:67
    sg-xxx 10.0.0.8 fa:16:3e:ba:67:74

Error:

    VM should not capture "fa:16:3e:c8:7a:67 > fa:16:3e:ba:67:74", because it should be an unicast from qr-xxx to sg-xxx. It appears that in br-int, there is no fdb record for fa:16:3e:ba:67:74, so br-int will flood frames destined to "fa:16:3e:ba:67:74" to every port in the same local VLAN. So, VM can capture this unknown unicast.

    Since every device in the same local VLAN on the same br-int can capture the flooded unknown unicast, it will have impact on performance and security.

Expect:

    "qr-xxx to sg-xxx" should mainly be unicast.