A flaw was found in Openstack Neutron. During live-migration there is a small time window where the ports of instances are untagged. Instances have a port trunked to the integration bridge and receive 802.1Q tagged private traffic from other tenants. If the port is administratively down during live migration, the port will remain in trunk mode indefinitely. Traffic is possible between ports is that are administratively down, even between tenants self-service networks. This allows end users within their own private network to receive from, and send traffic to, other private networks on the same compute node.
Created openstack-neutron tracking bugs for this issue:
Affects: openstack-rdo [bug 1594978]
*** Bug 1594825 has been marked as a duplicate of this bug. ***
Oh, the patches referenced on the bz are incorrect for this bz, also the 2nd launchpad ( https://bugs.launchpad.net/neutron/+bug/1767422 ).
Those patches, and that second launchpad address the case when an agent (dhcp/l3/etc) get's a port plugged, but then the openvswitch-agent is not able to tag the port, it remains untagged, and it's a trunk port.
But those patches *are not* addressing the instances themselves.
This needs to be addressed in nova, or os-vif by plugging the port in vlan 4095, then, when neutron is ready will re-plug to the right vlan.
I checked that and it is like Miguel wrote in last comment. This issue isn't fixed in any of OSP versions yet.
It should be fixed in os-vif module as this module is responsible for creating ports in openvswitch during booting/migrating instances.
I proposed already such patch in upstream: https://review.openstack.org/594118
Thanks Slawomir for the additional work to close the loop on this. We had included the fixes that had been provided upstream for information purposes, and as Miguel has noted in the tracker, additional patches to nova/os-vif are required to close this out fully. Can you confirm if the upstream neutron patches will also be applied? My understanding of the situation is that both this, and your additional os-vif patch are required to fully close this out.
Unfortunately my patch proposed to os-vif will have to be modified and it will also require other patch in Neutron probably. We can't simply set this vlan tag always in os-vif as it breaks other Neutron backends (like networking-odl or dragonfly for example).
I will work on that and propose patch to neutron and then modify this one for os-vif.
Thanks Slawomir, for the clarification, that makes sense. Thanks for your work on this.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):