Open Stack

Bridge mappings is an agent configuration value, it's not in the neutron
server config.

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.
On Apr 25, 2015 1:55 PM, "Mike Spreitzer" <mspreitz at us.ibm.com> wrote:

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