Flat network type seems broken on un-containerized compute nodes
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack-Ansible |
Fix Released
|
Low
|
Matt Kassawara | ||
| Juno |
Fix Released
|
Low
|
Kevin Carter | ||
| Trunk |
Fix Released
|
Low
|
Matt Kassawara | ||
Bug Description
Opened by cloudnull on 2014-09-08 03:18:55+00:00 at https:/
-------
When using a flat network type the linux-bridge-agent bombs due to the linux-bridge-agent attempting to bridge the already bridged network.
Error:
2014-09-08 02:51:13.332 19696 INFO neutron.
None, u'physical_
2014-09-08 02:51:14.604 19696 ERROR neutron.
Command: ['sudo', '/usr/local/
Exit code: 1
Stdout: ''
Stderr: "device br-vlan is a bridge device itself; can't enslave a bridge device to a bridge device.\n"
While this issue needs verification, to fix this we'd need to rework the ml2.ini plugin to move the binding for flat network types to an unbridged interface.
Tags: bug, doc, prio:3, regression
=======
Comment created by elextro on 2014-09-08 16:44:03+00:00
I ran into this last week and moved br-vlan to an unbridged interface. I'm working through a build with a flat network right now, I'll provide more information [when,if] I encounter it again.
-Alex
-------
Comment created by Apsu on 2014-09-08 17:33:54+00:00
This is definitely a problem, I can totally see it now that it's come up. Neutron will refuse to bridge bridges, as the error message indicates, and for `is_metal` boxen (compute nodes) where we're not using containers, we're making use of the `container_bridge` key for networks instead of `container_
On network nodes, an `eth11` would be created by default inside of the neutron-agents container, but this obviously won't happen for us on compute nodes, since nova-compute is no longer containerized. Seems like the simplest solution is to change up the example interfaces file to create a veth pair with the appropriate name to emulate the containerization process.
For instance:
```
auto br-vlan
iface br-vlan inet manual
# Create veth pair, don't bomb if already exists
pre-up ip link add br-vlan-veth type veth peer name eth11 || true
# Set both ends UP
pre-up ip link set br-vlan-veth up
pre-up ip link set eth11 up
# Set bridge UP/DOWN
up ip link set $IFACE up
down ip link set $IFACE down
# Delete veth pair on DOWN
post-down ip link del br-vlan-veth || true
# Add bond1 trunk and one veth end to bridge
bridge_ports bond1 br-vlan-veth
```
Theory here being we create a veth pair with a unique name based on the bridge it's going in, and the other end is the same name it would have if it were in a container, so we just need to make sure the ml2_conf.ini mappings on compute nodes aren't doing anything different than non-compute nodes.
-------
Comment created by elextro on 2014-09-09 03:11:37+00:00
@cloudnull
Kevin, what were you doing here when this error came up? I haven't been able to reproduce. The neutron linuxbridge agent on the compute host doesn't ever try to add the br-vlan bridge to a brqXXXX bridge on my build. VM traffic is only sent through the br-vxlan interface.
-Alex
-------
Comment created by Apsu on 2014-09-09 03:55:16+00:00
@elextro This would be expected when creating a flat type neutron network, like so:
```neutron net-create --provider:
The `vlan` network name is mapped in the `ml2_conf.ini` to the `br-vlan` bridge on compute nodes, but to `eth11` in neutron-agents containers, as I mentioned in my comment above. This results in neutron trying to create a linux bridge and putting the mapped interface inside of it -- namely, the `br-vlan` bridge. This is when it fails.
In your build, it sounds like you're only creating VXLAN type networks, which will create a vxlan interface "based on" the mapped interface (where the mapping is named `vxlan` in neutron), which doesn't require bridging an interface directly -- instead it's indirectly "attached" to an interface, which can be a bridge interface, such as `br-vxlan`. Then, neutron adds this new vxlan interface to the `brqXXXX` bridge it creates, and there's no problem with it operating this way.
Likewise, with VLAN-type networks, neutron creates a VLAN-tagged interface, again, based on the mapped interface (`br-vlan`), and then the `brqXXXX` bridges this new tagged interface, and again there's no problem.
-------
Comment created by elextro on 2014-09-09 13:52:22+00:00
@Apsu
I created the flat network and implemented emulated containerization with the veth pairs as stated above, everything seems to be running as expected. Eth11 gets added to the linux bridge without throwing an error. You guys just have to make sure ml2_conf.ini is the same for compute hosts and the neutron agent containers if you decide to go this way.
-Alex
-------
Comment created by ionosphere80 on 2014-09-26 16:05:10+00:00
What happened to this issue?
| Changed in openstack-ansible: | |
| importance: | Undecided → Low |
| tags: | added: impacts-doc |
| Changed in openstack-ansible: | |
| milestone: | none → next |
| Jesse Pretorius (jesse-pretorius) wrote | #1 |
| Changed in openstack-ansible: | |
| assignee: | nobody → Matt Kassawara (ionosphere80) |
| status: | New → Confirmed |
| OpenStack Infra (hudson-openstack) wrote Related fix merged to openstack-ansible (master) | #2 |
| OpenStack Infra (hudson-openstack) wrote Related fix proposed to openstack-ansible (stable/ocata) | #3 |
| OpenStack Infra (hudson-openstack) wrote Related fix proposed to openstack-ansible (stable/newton) | #4 |
| OpenStack Infra (hudson-openstack) wrote Related fix merged to openstack-ansible (stable/ocata) | #5 |
| tags: | added: in-stable-ocata |
| OpenStack Infra (hudson-openstack) wrote Related fix merged to openstack-ansible (stable/newton) | #6 |
| tags: | added: in-stable-newton |
Patch in review - https:/