yahoo-eng-team team mailing list archive

[Hong Hui Xiao <honghui_xiao@xxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
     Assignee: Hong Hui Xiao (xiaohhui)
         Status: New

** Changed in: neutron
     Assignee: (unassigned) => Hong Hui Xiao (xiaohhui)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1767811

Title:
  [DVR] br-int in compute node will send unknown unicast to sg-xxx

Status in neutron:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1767811/+subscriptions