yahoo-eng-team team mailing list archive

[Jeremy Stanley <1866725@xxxxxxxxxxxxxxxxxx>]

I've switched this to a regular Public bug and removed our security
advisory task, but marked it with the security tag as a possible
hardening opportunity.

** Information type changed from Public Security to Public

** No longer affects: ossa

** Tags added: security

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

Title:
  DVR denial of service observed when using DVR+VLAN project networks

Status in neutron:
  Incomplete

Bug description:
  Neturon: 15.0.1
  Open vSwitch: 2.12
  Linux kernel: 5.3

  Summary: If a qr interface transmits data to another hypervisor on the
  vlan, a datapath rule is installed that will inhibit communication
  between qr and virtual machines colocated on a hypervisor. The
  problematic datapath is defined only in context of qr in_port, source
  MAC address, and output port. Consequently, traffic transmitted by qr
  interface will be disrupted. Loss of floating IPs and routing services
  is experienced until the datapath rule expires or is flushed.

  Description:

          hypervisor M1                                                hypervisor M2
  ====================================                    ====================================
             VM1                                                             VM2
         10.10.0.10                                                       10.10.0.20
             |                                                                |
       qr -- br-int -- br-vlan -- ethX -----vlan 500---- ethX -- br-vlan -- br-int -- qr
  10.10.0.1                                                                          10.10.0.1

  In this setup VM1 and VM2 are executing on hypervisors M1 and M2,
  respectively. The DVR interface is designated qr. The br-vlan provides
  access to vlan id 500 via interface ethX

  br-vlan has a rule to rewrite the qr source MAC (DVR MAC) to its
  unique local instance (LOCAL DVR MAC) before transmitting the frames
  onto the physical network. If this rule is used, a datapath rule DP1
  is installed that is structured as:

  in_port(qr),eth(src=DVR MAC),eth_type(0x0800),ipv4(frag=no) actions:
  set(eth(src=LOCAL DVR MAC)),push_vlan(vid=500,pcp=0),ethX

  Waiting a moment for any existing datapaths to expire, traffic
  originating from the qr will have its source MAC address rewritten and
  forwarded out of ethX. If this is happening on M1, this will disrupt
  communication between qr and VM1, including routing and floating ip
  access. Open vswitch will not inject a new datapath as the datapath
  matches the traffic from the qr.

  To cause this to happen, configure VM1 to communicate with VM2 by bouncing traffic off of qr.
  On VM1, configure the routing table

  ip route add 10.10.0.20/32 via 10.10.0.1

  and then ping 10.10.0.20

  On H1, the datapath DP1 will be installed and access to VM1 via
  floating IP will be lost. This is probably not the only method to get
  the datapath installed.

  When the system is properly working datapath explicitly expresses both
  source and destination MAC addresses.

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