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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
