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" <[email protected]> wrote: > Uwe Sauter <[email protected]> wrote on 04/25/2015 04:42:06 PM: > > > Am 25.04.2015 um 22:28 schrieb Mike Spreitzer: > > >> From: Uwe Sauter <[email protected]> > > >> > > >> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
