Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150425/3ee9baf5/attachment.html>