Uwe Sauter <uwe.sauter...@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...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators