# Multiple subnets in an external network for inbound and outbound access

We would like to handle both outbound and inbound access for our tenants on an Icehouse system via a single external VLAN provider network.

The idea is to have a network per project with two subnets, one of which will allow outbound access via PAT rules on the external network (which consists of separate hardware) and the second will allow inbound access by allocating floating IPs from a small pool of internet addresses, again relying on rules created in the external hardware.

Hence, we could have 10.1.42.0/25 for the first case and 10.1.42.128/25 for the second case.

Does that make sense?

The alternative is to have two networks per project, but we have a limited number of VLANs we can support on the external network hardware, so we'd prefer to avoid that if possible.

Update to clarify the question in light of the proposed answer

I think your first use case is quite near to what we're after. We have a /27 currently, with the promise of a larger allocation if needed.

You're suggesting that we create a single VLAN covering that pool, then allocate a small number of addresses to Neutron routers and the rest as floating IPs.

• For those instances that don't need or want external access, they stick to their tenant network.
• For those instances that need only outbound external access, they use a different tenant network that has this external network as a gateway.
• For those instances that need inbound external access, they use one of the small number of floating IPs on this external network. We don't expect a large demand for this, so (for the moment) the fact that not many instances will be able to support inbound access is fine.

Does that sound right?

edit retag close merge delete

Yes, it does. But please also bare in mind that "external" in this context means "external to the cloud environment" and not "external to our network". So you may find you'll need to go for the hybrid network later on.

( 2015-07-21 03:42:06 -0500 )edit

That's a good point. It's fine if we need to change this later. For now, we just need basic external connectivity.

( 2015-07-21 03:49:55 -0500 )edit

Sort by » oldest newest most voted

Hi there,

I am a bit confused as to your use case. Could you clarify?

The first network, which you have designated as "outbound", seems redundant, and your "inbound" seems to have an unnecessary PAT.

Let me demonstrate a few architectures that I think at one of demonstrates your needs as I understand them, and the best way to achieve them.

You have a pool of external addresses, a /24, that you would like to allocate to your cloud with the address203.0.113.0/24. This is a static allocation that you are either announcing yourself, or your ISP is providing you redundant connections for this. This /24 is completely unused and is a part of a bigger allocation you have otherwise sub netted (e.g you have a /23 and are currently using the other half). This is by far the simplist deployment you can do, just route the entire 203.0.113.0/24 to the VLAN you are giving to OpenStack and consume it via floating IPs in OpenStack. Obviously you will need to reserve a few IPs, e.g. 203.0.113.1 for your router VIP, so you take the first 10 to be safe.

This is in fact the similar to the example given by the OpenStack Documentation: neutron subnet-create ext-net --name ext-subnet --allocation-pool start=203.0.113.11,end=203.0.113.254 --disable-dhcp --gateway 203.0.113.1 203.0.113.0/24

Outbound only traffic will be handled by the router IP addresses which have their gateway addresses. For machines who need only Internet access they will be exposed to the Internet via these means. Any inbound traffic will be handled by specifically assigned Floating IPs, or for smaller projects, machines placed directly on the external network.

Similar to above, but for some reason you don't have your own public range (or your public range can change). An example would be your primary and secondary internet connections do not support BGP, so you cannot BYO addresses, and you rely on DNS with a low TTL for fail-over (kids, if this is your setup, run away...).

A more realistic example would be if you have a network announcement that when given a /23 announce the whole subnet because he "didn't want to lose any addresses to further subnetting". You might even be so Address skint that you actually can't afford to lose any addresses to subnetting. (In this case I would recommend moving to IPv6).

In either case, you have an internal network, say in the 10.0.10.0/24 range from 10.0.10.101 to 10.0.10.200.

In this case, the same logic as above applies, only there is an extra layer of PAT above the network. So you would create a net like this:

neutron subnet-create ext-net --name ext-subnet --allocation-pool start=10.0.10.101,end=10.0.10.200 --disable-dhcp --gateway ...

more

I've tried to clarify the use case by editing the original question

( 2015-07-20 07:53:32 -0500 )edit