[Openstack-operators] [neutron] multiple external networks on the same host NIC
mspreitz at us.ibm.com
Mon Apr 27 14:59:42 UTC 2015
Uwe Sauter <uwe.sauter.de at gmail.com> wrote on 04/27/2015 10:54:15 AM:
> Am 27.04.2015 um 16:36 schrieb Mike Spreitzer:
> > Uwe Sauter <uwe.sauter.de at gmail.com> wrote on 04/25/2015 04:17:35 PM:
> >> 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.
> > Now that I have found my bridge_mappings configuration statement,
> I can return to thinking about what you said. It sounds very
> > similar to what George said --- it is just that you suggest an OVS
> switch in place of George's br-join (which I had assumed was
> > also an OVS switch, since it is named like the others). Do I have
> this right?
> > Thanks,
> > Mike
> if I understood Georges answer correctly he suggested one bridge
> (br-join, either OVS or linux bridge) to connect other bridges
> via patch links, one for each external network you'd like to create.
> These second level bridges are then used for the Neutron
> br-ext1 -> Neutron
> ethX –br-join
> br-ext2 -> Neutron
> I suggested to use an OVS bridge because there it'd be possible to
> stay away from the performance-wise worse patch-links and Linux
> bridges and use "internal" interfaces to connect to Neutron directly
> – which on second thought won't work if Neutron expects a
> bridge in that place.
> What I suggested later on is that you probably don't need any second
> level bridge at all. Just create a second/third external
> network with appropriate CIDR. As long as those networks are
> externally connected to your interface (and thus the bridge) you
> should be good to go.
To be precise, are you suggesting that I have just one br-ex, connected to
the host NIC as usual, and in my bridge_mappings configuration statement,
map all the external network names to br-ex?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators