Matching the MAC of the tap interface on the hypervisor
to the MAC that the VM will actually use to send traffic
through the tap causes the following error messages:
brq9e974900-cd: received packet on tapa8a6ce4a-e8 with
own address as source address
This is triggering a warning because there are now two
forwarding entries on the bridge, a static one from the
tap device, and a learned one from the packets received.
Due to the presence of a static MAC entry, this will break
things like allowed_address_pair use cases that allow a MAC
to be used by multiple ports.
This patch removes all of the logic to set the MAC
address on the TAP device because it didn't serve any
other purpose than easy to correlate output from
ip link show commands and neutron port MAC addresses.
TAP devices will now just get whatever MAC address the kernel
selects for them.
Objects must use project_id and not tenant_id. The object framework
ensures that tenant_id is added as an extra field for backward
This patch reverts the workaround implemented in change
I4ec9340094bc51cd8aa6e5112bf8114aa26c2982 and implements a proper fix
by explicitly updating the objects.
Co-Authored-By: Artur Korzeniewski <firstname.lastname@example.org>
Co-Authored-By: Darek Smigiel <email@example.com>
This adds the module responsible for creating/deleting
VLAN sub-interfaces when passed a trunk object. It handles
parsing of ip link output to find existing VLAN children and
the calls to ip_lib to create/destroy sub-interfaces.
This includes unit tests as well as functional tests.
Partially-Implements: blueprint vlan-aware-vms
This change moves from linuxbridge agent to bridge_lib bridge only
related features and adds functional tests.
Currently get_bridge_for_tap_device iterates over all neutron bridges
and their interfaces.
This change proposes to deduce interface bridge from:
which is a symlink to bridge interface path to improve performance.
Currently interface_exists_on_bridge lists all files in a folder and
searchs for the file associated to the interface.
This change proposes to look for the file existence directly.
The function gets a list of all the devices that exists on the machine,
and then iterates on them one at a time in order to find the correct
device which holds the ip specified. However, if one of the devices was
in the mean time deleted, the code will raise an Exception. In the ovs
agent's case, this will cause it to not run at all (requiring a
Also, changes to a few tests of LinuxBridge were made because
linuxbridge doesn't check that cfg.CONF.VXLAN.local_ip is not empty
before using it (a bug, surely). Since it's out of scope of this patch
to fix this, workarounds were implemented to make sure the tests ignore
the option instead.
In some deployment scenario, it is not allowed to remove system
ethernet configuration from physical interface to newly-created
physical bridge by neutron due to some IT regulations.
End-users require to take advantage of the pre-existed(user-defined)
physical bridge to connect tap devices for neutron.
Implements: blueprint phy-net-bridge-mapping
Verify that the interfaces actually exist that are defined in
interface_mappings on Linux bridge startup. If they do not, exit
immediately similar to how OVS handles incorrect bridge_mappings.
This prevents an unfriendly exception in the rpc setup routine.