[Openstack-operators] [neutron] multiple external networks on the same host NIC

Uwe Sauter uwe.sauter.de at gmail.com
Sat Apr 25 21:06:40 UTC 2015


Am 25.04.2015 um 22:54 schrieb Mike Spreitzer:
> 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
> 

Mike,

what version of OpenStack are you using? I only have experience with Juno and the install manual shows additional sections
compared to your file: http://docs.openstack.org/juno/install-guide/install/yum/content/neutron-network-node.html

After flying over the manual again, I'd say that you don't need the extra stuff we were talking about but only need to add more
external networks. Get your configuration with bridge_mappings straight, than add the networks. But that's just a wild guess…

Regards,

	Uwe



More information about the OpenStack-operators mailing list