Open Stack

I don’t have the exact steps offhand, but you should be able to create a veth pair manually, attach one end to your existing bridge, and specify the other end in the bridge_mappings section. Make sure you set both ends up using ‘ip link set <dev> up’ prior to this. The veth pair will end up linking the bridges together.

Nova/Neutron should still handle putting the tap interface of the instance in the bridge, even if bridge_mappings is wrong or not working. The port’s device owner is compute:nova, which likely explains the message you saw in the log.

Hope that helps!

James


From: Paul Dekkers <paul.dekkers at surfnet.nl>
Date: Tuesday, August 16, 2016 at 12:18 PM
To: George Paraskevas <paraskgeor at gmail.com>, openstack-operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] neutron flat network on existing bridge fails

Hi,

Thanks for your suggestion - I don't think that's it, because that gives me:

Unable to add br224 to brqf709c220-fd! Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: device br224 is a bridge device itself; can't enslave a bridge device to a bridge device.

and

Skip adding device tapf99013c6-6b to brqf709c220-fd. It is owned by compute:nova and thus added elsewhere. _add_tap_interface /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:473

while this tapf99013c6-6b now actually is enslaved to brqf709c220-fd, even with the wrong physical_interface_mappings setting. So I guess it's ignored because of the error, or some other code built that bridge (nova? as it's owned by compute:nova ? I had no idea a bridge/interface could have an owner...)

Regards,
Paul


On 16-08-16 17:39, George Paraskevas wrote:

Hello,
With Linux bridge, I believe you should use physical _interface_mappings =provider:br224
Beat regards
George

On Tue, 16 Aug 2016, 16:48 Paul Dekkers, <paul.dekkers at surfnet.nl<mailto:paul.dekkers at surfnet.nl>> wrote:
Hi,

I'm using Ubuntu 16.04.1 with it's Mitaka release, and neutron flat
networking with linuxbridge+ml2:

I'd like to attach my flat neutron network to an existing linuxbridge on
my system. This fails with an error like:

2016-08-16 15:07:00.711 7982 DEBUG
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent
[req-720266dc-fe8d-47c4-a7df-19fee7a8d679 - - - - -] Skip adding device
tapf99013c6-6b to br224. It is owned by compute:nova and thus added
elsewhere. _add_tap_interface
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:473

with the result that the tap interface is added to a newly created
bridge instead of the existing (br224) bridge.

I've set
bridge_mappings = provider:br224
in /etc/neutron/plugins/ml2/linuxbridge_agent.ini

(because if I use
physical_interface_mappings = provider:vlan224
the vlan224 interface is actually detached from the original bridge)

I've created the bridge via /etc/network/interfaces:

auto br224
iface br224 inet manual
        bridge_ports vlan224

auto vlan224
iface vlan224 inet manual
        vlan_raw_device eno1

Reason for doing this is that I'd like to attach an lxc container to
this bridge (and only when neutron needs it the "brqf709c220-fd" (with
for me an unpredictable name) is setup, so I can't use that), and/or
like to have the machine itself use an interface on this network. (This
is also my reason for using flat networking, and not vlan.)

I've created the neutron networks with

neutron net-create default --shared --provider:physical_network provider
--provider:network_type flat

(I would repeat this with a different physical_network name if I need
more VLANs, instead of using the --provider:segmentation_id.)

Instance networking works when I let nova/neutron create the bridge
interfaces.

Any idea why neutron refuses to use the bridge_mappings and why it
creates a new interface?

Regards,
Paul

P.S. To me it feels like this is what people would need when setting up
a small single-network setup (both for instances and OpenStack), but
most examples use multiple networks anyway.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160817/bc9f1eae/attachment.html>