Open Stack

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/20160816/4cbc8253/attachment.html>