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

Mike Spreitzer mspreitz at us.ibm.com
Mon Apr 27 15:40:38 UTC 2015


"gustavo panizzo (gfa)" <gfa at zumbi.com.ar> wrote on 04/27/2015 11:23:13 
AM:

> On 2015-04-27 22:59, Mike Spreitzer wrote:
> > Uwe Sauter <uwe.sauter.de at gmail.com> wrote on 04/27/2015 10:54:15 AM:
> >>
> >> 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?
> 
> you can only have one flat network per bridge.
> 
> i don't know what's your usercase but one i had the need to map 2
> different public ip address to each vm vnic, i was going to do the
> double bridge thing but i resolved it using allowed pairs extension. it
> may work for you

My use case is that I have two behaviorally different external subnets --- 
they are treated differently by stuff outside of OpenStack, with 
consequences that are meaningful to tenants.  Thus, I have two categories 
of floating IP addresses, depending on which external subnet holds the 
floating IP address.  The difference is meaningful to tenants.  So I need 
to enable a tenant to request a floating IP address of a specific 
category.  Since Neutron equates floating IP address allocation pool with 
network, I need two external networks.

Both of these external subnets are present on the same actual external 
LAN, thus both are reached through the same host NIC.

It looks to me like the allowed mac/IP address pair feature will not solve 
this problem.

Thanks,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150427/988fb9eb/attachment.html>


More information about the OpenStack-operators mailing list