non-NATed cloud network to provider network

asked 2013-02-21 16:24:09 -0500

wei-wen-chen gravatar image

At present, quantum will always NAT cloud networks in private domain to external networks attached. Is there a way to disable NAT setup and let cloud networks routed directly to provider network, assuming no overlapping IP is configured? This setup seems much simple and could be deployed quickly for some customers.

edit retag flag offensive close merge delete

12 answers

Sort by ยป oldest newest most voted
0

answered 2013-03-13 22:32:28 -0500

salvatore-orlando gravatar image

Joshua,

at the moment the only 'default gateway' solution that is allowed by Quantum uses NAT. There's a blueprint in progress on this aspect: https://blueprints.launchpad.net/quantum/+spec/l3-ext-gw-modes/ (https://blueprints.launchpad.net/quan...)

However, this is not going to be part of the upcoming release. If your instances have publicly routable addresses, you can probably leverage the solution Bob prosed in answer #3 in this thread.

Otherwise, if your instances have private addresses and the happens somewhere else in the nw infrastructure outside of openstack, I think Quantum at the moment does not provide a full solution that might address your needs.

edit flag offensive delete link more
0

answered 2013-03-13 22:20:23 -0500

jmurphy-s gravatar image

I to would love to be able to turn off NAT per tenant. I have a client who would like to launch cpanel/whm servers in my environment but they dont support a nat setup.

edit flag offensive delete link more
0

answered 2013-03-01 13:34:04 -0500

digitalwonk gravatar image

Robert: Do you happen to know of any instructions or could provide the configurations needed for a quantum deployment without l3 as you described? I would be interested in that configuration. Thanks!

edit flag offensive delete link more
0

answered 2013-02-22 16:45:03 -0500

wei-wen-chen gravatar image

Cool. I will follow up on your plan.

Thanks

edit flag offensive delete link more
0

answered 2013-02-22 16:32:23 -0500

salvatore-orlando gravatar image

The bug was initially proposed as a NVP-specific feature. However, it emerged that it is a problem of interest for the whole community. Unfortunately there was not enough time to squeeze this feature into G-3.

I am currently working on a blueprint spec for Havana-1 (with support for this capability in the OVS plugin)

edit flag offensive delete link more
0

answered 2013-02-22 15:59:55 -0500

wei-wen-chen gravatar image

Hi Sumit,

Thanks for pointing to this. Is this NVP specific extension or general Quantum solution? From the discussion I could not tell directly. If yes, I like the solution.

Thanks

edit flag offensive delete link more
0

answered 2013-02-21 22:12:46 -0500

I believe there is some discussion related to this here: https://bugs.launchpad.net/quantum/+bug/1121129 (https://bugs.launchpad.net/quantum/+b...)

edit flag offensive delete link more
0

answered 2013-02-21 21:31:20 -0500

rkukura gravatar image

Understood. A shared flat external network might be sufficient in some cases, possibly even combined with private networks and appropriate security group rules. I agree routing to an external network without using NAT would also be a good feature. How about filing a bug requesting this?

edit flag offensive delete link more
0

answered 2013-02-21 20:54:26 -0500

wei-wen-chen gravatar image

What you just described is flat network case that will not support tenant-based network provisioning. For sure it is the simplest solution, but kind of too simple to support multiple tenants.

Right, I believe NAT should not be a native part of L3 agent, and we like to disable it somehow.

edit flag offensive delete link more
0

answered 2013-02-21 20:37:22 -0500

rkukura gravatar image

You should be able to set up a quantum provider network that has routed (non-NAT) external connectivity (i.e. via a physical router), and create a quantum subnet on that network with a pool of IPs that quantum's DHCP service will allocate to ports. You would deploy quantum-dhcp-agent for this network, but not deploy quantum-l3-agent, and VMs using this network would have direct external connectivity. This approach basically eliminates the private network, putting the VMs right on the public network.

It sounds like you'd like to use the quantum-l3-agent, but with NAT turned off for the external network. I'm not sure if this is possible right now, but the above suggestion might work for you if you don't need the quantum-l3-agent for other purposes.

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

2 followers

Stats

Asked: 2013-02-21 16:24:09 -0500

Seen: 204 times

Last updated: Mar 13 '13