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.[1]
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.
1. https://lists.linuxfoundation.org/pipermail/bridge/2004-January/003740.html
Closes-Bug: #1668209
Change-Id: I0ff46f9550a79f486063a8e2810ed3b1140a4769
Objects must use project_id and not tenant_id. The object framework
ensures that tenant_id is added as an extra field for backward
compatibility.
This patch reverts the workaround implemented in change
I4ec9340094bc51cd8aa6e5112bf8114aa26c2982 and implements a proper fix
by explicitly updating the objects.
Co-Authored-By: Artur Korzeniewski <artur.korzeniewski@intel.com>
Co-Authored-By: Darek Smigiel <smigiel.dariusz@gmail.com>
Closes-Bug: #1630748
Change-Id: Iab90bcab41655b2e210aea0e7581eb00b94ce5e5
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
Change-Id: I1e3ab69aaff7bca322fa0d738ac74c3dd0dc69b4
This change moves from linuxbridge agent[1] to bridge_lib[2] bridge only
related features and adds functional tests.
[1] neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent
[2] neutron.agent.linux.bridge_lib
Partial-Bug: #1514548
Change-Id: Ieccb8f77fc833467a166557e227023f5c2a50d1b
Currently get_bridge_for_tap_device[1] iterates over all neutron bridges
and their interfaces.
This change proposes to deduce interface bridge from:
/sys/class/net/%(interface)s/brif/bridge
which is a symlink to bridge interface path to improve performance.
[1] neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent
Closes-Bug: #1508789
Change-Id: Ia40cd81f47ff082a90d17f58514942ec50553241
Currently interface_exists_on_bridge[1] 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.
[1] neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent
Closes-Bug: #1509890
Change-Id: I23cd1edc92912b35bdc23ba0af2318b86f2cfd48
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
restart).
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.
Closes-Bug: #1506503
Change-Id: Iad285d7c763b0e8e8f877c6892aadb0043e9a186
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.
Closes-Bug: #1105488
Implements: blueprint phy-net-bridge-mapping
DocImpact
Change-Id: Ia0eaa6233d8da93da32e86404b15184b77937d0a
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.
Change-Id: I050b9b66aa0b27f148e67123eedf29fe332e6f65
Closes-Bug: #1470584
Kevin Benton