<p dir="ltr">Bridge mappings is an agent configuration value, it's not in the neutron server config. </p>
<p dir="ltr">Run ps -ef and look for the neutron openvswitch agent process to see which configuration files it's referencing. The bridge mappings will be in one of those. </p>
<div class="gmail_quote">On Apr 25, 2015 1:55 PM, "Mike Spreitzer" <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><tt><font size="2">Uwe Sauter <<a href="mailto:uwe.sauter.de@gmail.com" target="_blank">uwe.sauter.de@gmail.com</a>> wrote on 04/25/2015
04:42:06 PM:<br>
<br>
> Am 25.04.2015 um 22:28 schrieb Mike Spreitzer:<br>
> >> From: Uwe Sauter <<a href="mailto:uwe.sauter.de@gmail.com" target="_blank">uwe.sauter.de@gmail.com</a>><br>
> >><br>
> >> Or instead of using Linux bridges you could use a manually
created<br>
> >> OpenVSwitch bridge. This allows you to add "internal"<br>
> >> ports that could be used by Neutron like any other interface.<br>
> >><br>
> >> - Create OVS bridge<br>
> >> - Add your external interface to OVS bridge<br>
> >> * If your external connection supports/needs VLANs,
configure<br>
> >> external interface as trunk<br>
> >> - Add any number of internal interfaces to OVS bridge<br>
> >> * Tag each interface with its VLAN ID, if needed<br>
> >> - Configure Neutron to use one internal interface for each
subnet<br>
> >> you'd like to use (no VLAN configuration required as<br>
> >> this happenes outside of Neutron)<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> Uwe<br>
> >><br>
> >> Am 25.04.2015 um 21:41 schrieb George Shuklin:<br>
> >> > Can you put them to different vlans? After that it would
be <br>
> very easy task.<br>
> >> ><br>
> >> > If not, AFAIK, neutron does not allow this.<br>
> >> ><br>
> >> > Or you can trick it thinking it is (are) separate networks.<br>
> >> ><br>
> >> > Create brige (br-join), plug eth to it.<br>
> >> > Create to fake external bridges (br-ex1, br-ex2). Join
them<br>
> >> together to br-join by patch links<br>
> >> > (</font></tt><a href="http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-" target="_blank"><tt><font size="2">http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-</font></tt></a><tt><font size="2"><br>
> >> patch-ports/)<br>
> >> ><br>
> >> > Instruct neutron like there is two external networks:
one on br-<br>
> >> ex1, second on br-ex2.<br>
> >> ><br>
> >> > But be alert that this not very stable configuration,
you need to<br>
> >> maintain it by yourself.<br>
> >> ><br>
> >> > On 04/25/2015 10:13 PM, Mike Spreitzer wrote:<br>
> >> >> Is there a way to create multiple external networks
from<br>
> >> Neutron's point of view, where both of those networks are<br>
> >> >> accessed through the same host NIC? Obviously
those networks<br>
> >> would be using different subnets. I need this sort
of<br>
> >> >> thing because the two subnets are treated differently
by the<br>
> >> stuff outside of OpenStack, so I need a way that a tenant<br>
> >> >> can get a floating IP of the sort he wants. Since
Neutron<br>
> >> equates floating IP allocation pools with external<br>
> >> >> networks, I need two external networks.<br>
> >> >><br>
> >> >> I found, for example, </font></tt><a href="http://www.marcoberube.com/archives/248---" target="_blank"><tt><font size="2">http://www.marcoberube.com/archives/248---</font></tt></a><tt><font size="2"><br>
> >> which describes how to have multiple external<br>
> >> >> networks but uses a distinct host network interface
for each one.<br>
> >> >><br>
> >> >> Thanks,<br>
> >> >> Mike<br>
> > <br>
> > Thanks Uwe, I might try that, it sounds like the simplest thing
<br>
> that will work. I think I can not use VLAN tagging in my<br>
> > environment. I am using ML2 with OVS, and it is working
now with <br>
> a single external network. Should I expect to find a<br>
> > bridge_mappings entry in my plugin.ini? I do not find one
now. <br>
> This setup was mainly created by other people, so I am not sure<br>
> > what to expect. When using ML2 with OVS, how do I tell
Neutron <br>
> what my bridge mappings are?<br>
> > <br>
> > Thanks,<br>
> > Mike<br>
> > <br>
> <br>
> Mike,<br>
> <br>
> VLAN is optional in the setup I described. I just was pointing out
<br>
> where such a configuration could take place.<br>
> <br>
> As far as my experience with OVS and Neutron goes, Neutron will just<br>
> ignore already existing configurations. That's also the<br>
> reason why install manuals tell you to create br-int and br-ex.<br>
> <br>
> Regarding the exact configuration of ML2 and plugin.ini I'm not <br>
> quite sure if I understand your question correctly. Are you asking<br>
> how to tell Neutron which interface should be used for the different<br>
> IP subnets?<br>
> <br>
> Perhaps you could post your plugin.ini with sensitive information
<br>
> replaced with something generic.<br>
> <br>
> Regards,<br>
> <br>
> Uwe<br>
> <br>
</font></tt>
<br><tt><font size="2">Yes, I realize the VLAN tagging is just an option
in the approach you are outlining. George pointed out that VLAN tagging
could carry even more of the load here. I mentioned that I can not
use VLAN tagging as an explanation of why I have to pursue what you are
describing.</font></tt>
<br>
<br><tt><font size="2">Following in my plugin.ini. As you can see,
it is not what I would be editing. I have already added stuff to flat_networks,
in anticipation of being able to use more than one. My problem is
that there is no bridge_mappings, so I can not update it to add more external
networks!</font></tt>
<br>
<br>
<br><font size="2" face="Menlo-Regular"># This file autogenerated by Chef</font>
<br><font size="2" face="Menlo-Regular"># Do not edit, changes will be overwritten</font>
<br>
<br><font size="2" face="Menlo-Regular">[ml2]</font>
<br><font size="2" face="Menlo-Regular"># (ListOpt) List of network type
driver entrypoints to be loaded from</font>
<br><font size="2" face="Menlo-Regular"># the neutron.ml2.type_drivers namespace.</font>
<br><font size="2" face="Menlo-Regular">#</font>
<br><font size="2" face="Menlo-Regular"># type_drivers = local,flat,vlan,gre,vxlan</font>
<br><font size="2" face="Menlo-Regular"># Example: type_drivers = flat,vlan,gre,vxlan</font>
<br><font size="2" face="Menlo-Regular">type_drivers = gre,flat</font>
<br>
<br><font size="2" face="Menlo-Regular"># (ListOpt) Ordered list of network_types
to allocate as tenant</font>
<br><font size="2" face="Menlo-Regular"># networks. The default value 'local'
is useful for single-box testing</font>
<br><font size="2" face="Menlo-Regular"># but provides no connectivity between
hosts.</font>
<br><font size="2" face="Menlo-Regular">#</font>
<br><font size="2" face="Menlo-Regular"># tenant_network_types = local</font>
<br><font size="2" face="Menlo-Regular"># Example: tenant_network_types =
vlan,gre,vxlan</font>
<br><font size="2" face="Menlo-Regular">tenant_network_types = gre</font>
<br>
<br><font size="2" face="Menlo-Regular"># (ListOpt) Ordered list of networking
mechanism driver entrypoints</font>
<br><font size="2" face="Menlo-Regular"># to be loaded from the neutron.ml2.mechanism_drivers
namespace.</font>
<br><font size="2" face="Menlo-Regular"># mechanism_drivers =</font>
<br><font size="2" face="Menlo-Regular"># Example: mechanism_drivers = openvswitch,mlnx</font>
<br><font size="2" face="Menlo-Regular"># Example: mechanism_drivers = arista</font>
<br><font size="2" face="Menlo-Regular"># Example: mechanism_drivers = cisco,logger</font>
<br><font size="2" face="Menlo-Regular"># Example: mechanism_drivers = openvswitch,brocade</font>
<br><font size="2" face="Menlo-Regular"># Example: mechanism_drivers = linuxbridge,brocade</font>
<br><font size="2" face="Menlo-Regular">mechanism_drivers = openvswitch</font>
<br>
<br><font size="2" face="Menlo-Regular">[ml2_type_flat]</font>
<br><font size="2" face="Menlo-Regular"># (ListOpt) List of physical_network
names with which flat networks</font>
<br><font size="2" face="Menlo-Regular"># can be created. Use * to allow
flat networks with arbitrary</font>
<br><font size="2" face="Menlo-Regular"># physical_network names.</font>
<br><font size="2" face="Menlo-Regular">#</font>
<br><font size="2" face="Menlo-Regular"># flat_networks =</font>
<br><font size="2" face="Menlo-Regular"># Example:flat_networks = physnet1,physnet2</font>
<br><font size="2" face="Menlo-Regular"># Example:flat_networks = *</font>
<br><font size="2" face="Menlo-Regular">flat_networks = physnet1,physnet4n,physnet4p</font>
<br>
<br><font size="2" face="Menlo-Regular">[ml2_type_vlan]</font>
<br><font size="2" face="Menlo-Regular"># (ListOpt) List of <physical_network>[:<vlan_min>:<vlan_max>]
tuples</font>
<br><font size="2" face="Menlo-Regular"># specifying physical_network names
usable for VLAN provider and</font>
<br><font size="2" face="Menlo-Regular"># tenant networks, as well as ranges
of VLAN tags on each</font>
<br><font size="2" face="Menlo-Regular"># physical_network available for
allocation as tenant networks.</font>
<br><font size="2" face="Menlo-Regular">#</font>
<br><font size="2" face="Menlo-Regular"># network_vlan_ranges =</font>
<br><font size="2" face="Menlo-Regular"># Example: network_vlan_ranges =
physnet1:1000:2999,physnet2</font>
<br><font size="2" face="Menlo-Regular">network_vlan_ranges = </font>
<br>
<br><font size="2" face="Menlo-Regular">[ml2_type_gre]</font>
<br><font size="2" face="Menlo-Regular"># (ListOpt) Comma-separated list
of <tun_min>:<tun_max> tuples enumerating ranges of GRE tunnel
IDs that are available for tenant network allocation</font>
<br><font size="2" face="Menlo-Regular">tunnel_id_ranges = 1:2000</font>
<br>
<br><font size="2" face="Menlo-Regular">[ml2_type_vxlan]</font>
<br><font size="2" face="Menlo-Regular"># (ListOpt) Comma-separated list
of <vni_min>:<vni_max> tuples enumerating</font>
<br><font size="2" face="Menlo-Regular"># ranges of VXLAN VNI IDs that are
available for tenant network allocation.</font>
<br><font size="2" face="Menlo-Regular">vni_ranges = </font>
<br>
<br><font size="2" face="Menlo-Regular"># (StrOpt) Multicast group for the
VXLAN interface. When configured, will</font>
<br><font size="2" face="Menlo-Regular"># enable sending all broadcast traffic
to this multicast group. When left</font>
<br><font size="2" face="Menlo-Regular"># unconfigured, will disable multicast
VXLAN mode.</font>
<br><font size="2" face="Menlo-Regular">#</font>
<br><font size="2" face="Menlo-Regular"># vxlan_group =</font>
<br><font size="2" face="Menlo-Regular"># Example: vxlan_group = 239.1.1.1</font>
<br><font size="2" face="Menlo-Regular">vxlan_group = </font>
<br>
<br><font size="2" face="Menlo-Regular">[securitygroup]</font>
<br><font size="2" face="Menlo-Regular"># Controls if neutron security group
is enabled or not.</font>
<br><font size="2" face="Menlo-Regular"># It should be false when you use
nova security group.</font>
<br><font size="2" face="Menlo-Regular">enable_security_group = True</font>
<br>
<br><font size="2" face="Menlo-Regular"># Use ipset to speed-up the iptables
security groups. Enabling ipset support</font>
<br><font size="2" face="Menlo-Regular"># requires that ipset is installed
on L2 agent node.</font>
<br><font size="2" face="Menlo-Regular">enable_ipset = True</font>
<br>
<br>
<br><tt><font size="2">Thanks,</font></tt>
<br><tt><font size="2">Mike</font></tt>
<br>
<br><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div>