[Openstack-operators] [neutron] multiple external networks on the same host NIC
mspreitz at us.ibm.com
Sat Apr 25 20:54:38 UTC 2015
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
> 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.
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
# (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
# (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
# (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
# (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
# (ListOpt) Comma-separated list of <vni_min>:<vni_max> tuples enumerating
# ranges of VXLAN VNI IDs that are available for tenant network
# (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 = 188.8.131.52
# 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
# requires that ipset is installed on L2 agent node.
enable_ipset = True
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators